Robotics middleware

Robotics middleware is middleware to be used in complex robot control software systems.

General concepts

As glue code, the middleware should be invisible, and introduce no overhead or extra constraints on the components. This is of course an unreachable (non-functional) design requirement, so compromises have to be made. Different middleware projects mostly differ in which compromises are made (implicitly, most often!) and in which robotics applications are being targeted. As glue software, middleware should support the coupling of subsystems, which is a fundamentally different software development skill than the decoupling design requirements that most software engineers are educated in. Indeed, decoupling is the major focus of class library development: one should make a library as independent from other libraries as possible. Middleware, on the other hand, must provide optimal support for coupling: allowing to couple multiple, decoupledly designed components together in a way that satisfies system-level requirements. The composition of sub-systems into a new system is often a difficult task: designing the architecture of the system is hard, since it requires to find the optimal trade-offs between all system requirements and to realise the optimal cooperation between all system components. There are currently close to no software tools, or internationally accepted standards and workflows, to support the job of the system designer.

Some of the problems to be solved when designing a composite system are:

• the composed system should have an interface that is not (much) more complex than the combination of all composing subsystems. Otherwise, the composite system offers no real design advantages to the human developer. In practice, this means that the composite system developer makes some design decisions that restrict the use of each of the components to only a part of its potential domain.
• the composed system should act to its users as one consistent, monolithic system in itself.
• building a system from reusable components is challenging with respect to the balance between performance (it (seems to be) easier to optimize performance if one is not restricted to using only pre-built components) and ease of reuse.

At a conceptual level, a complex robot controller has components that each serve one of the following four concerns:

• Communication: components must exchange information (data, events, commands,…), and how this exchange is done is an important property of the composite system.
• Computation: each component performs certain computations that are necessary to provide the functionality that is expected from the system.
• Configuration: components should be usable in more than one possible configuration (i.e., concrete settings for each of their variable parameters), but the amount of configuration is an important aspect of the design and the implementation of components and systems. Configuration is required at various moments in the lifetime of a software system: compile time, deployment time, run time,…
• Coordination: the activities in components have to be coordinated by something at the system level, in order to guarantee the expected behaviour and performance of the composed system. Coordination involves: decision making, scheduling, (de)activating subsystems and/or their interconnections,…

Whether these four above-mentioned primitive concepts are really minimal (i.e., one needs only these four concepts to cover all relevant system design aspects) and/or complete (i.e., these concepts cover all possible systems) is not so important in this discussion; the important thing is that, at systems level, the designer should benefit from a level of abstraction that is an appropriate trade-off between complexity (the fewer concepts are needed, the better) and flexibility (the more diverse systems can be represented by the conceptual primitives, the better). Again, the appropriate trade-off is not an absolute concept, so it will depend on many (non-functional) design requirements. As such, both the number and the nature of the primitive concepts, and the particular trade-off, are discriminating factors between different middleware projects.

Composing two or more components that each belong to one of these categories is an architectural design activity. It is often complex, in that it has to balance a large amount of functional and non-functional requirements (performance, compositionality,…). The robotics research community has not yet come up with fully satisfying software frameworks, architectures, or methodologies to deal with the composition problem, but a large number of (open source) projects exist already, and they all claim to provide good solutions to this component composition problem, at least to (implicitly described) parts of it. Anyway, many fundamental questions are still unsolved, or rather, are still unnoticed within the robotics research community. This article presents an overview of some of the relevant issues to be considered in the design and use of such middleware, and also provides an annotated list of middleware projects with an evaluation of which design constraints they took (or did not take) into account, and about how well they perform.

Composition of subsystems

How to optimally compose subsystems into a larger system is the core activity of system developers, but is remains more of an art than of a science. The major challenge is to develop subsystems that are stable on their own, while still very willing to be part of a larger system. There are four different ways of composing software components:

• linking object classes by providing explicit references to each other:
• composing object classes without them knowing about each other
• composing components
• composing software services:

A composed system is stable if it can be used without the user having to know that it is a composed system in itself. Examples of commonly used compositions that are not stable are:

• Simulink blocks in feedback controllers: one often has to introduce explicit delay blocks; one cannot predict the overall performance on the basis of the performance of the individual blocks.
• Realtime aspects at the system level: only one of the components can really have the highest priority; schedulability of the activities in all components becomes exponentially harder to analyse, let alone to guarantee, when the number of components grows; IPC deadlocks become more likely, and more difficult to trace; formal verification becomes more difficult, since jitter and latency deteriorate in less predictable ways, compromising the ideal, abstract model of states with atomic and infinitely fast transitions and condition checks.
• Adding sensor processing or control blocks to a control loop: each new sensor can bring with it a device driver that requires a different sampling frequency, that provides a different spatial resolution, …

Robotics middleware projects

Player Project

The Player Project (formerly the Player/Stage Project) is a project to create free software for research into robotics and sensor systems. Its components include the Player network server and the Stage robot platform simulators. Although accurate statistics are hard to obtain, Player is one of the most popular open-source robot interfaces in research and post-secondary education. Most of the major intelligent robotics journals and conferences regularly publish papers featuring real and simulated robot experiments using Player and Stage.

RT-middleware

RT-middleware is a common platform standards for Robots based on distributed object technology. RT-middleware supports the construction of various networked robotic systems by the integration of various network-enabled robotic elements called RT-Components. The specification standard of RT-components is discussed and defined by the Object Management Group (OMG).

Orca

Orca describes its goals as:

• to enable software reuse by defining a set of commonly-used interfaces;
• to simplify software reuse by providing libraries with a high-level convenient API; and
• to encourage software reuse by maintaining a repository of components.

They also state: "To be successful, we think that a framework with such objectives must be: general, flexible and extensible; sufficiently robust, high-performance and full-featured for use in commercial applications, yet sufficiently simple for experimentation in university research environments."

They describe their approach as:

• adopts a Component-Based Software Engineering approach without applying any additional architectural constraints
• uses a commercial open-source library for communication and interface definition
• provides tools to simplify component development but makes them strictly optional to maintain full access to the underlying communication engine and services
• uses cross-platform development tools

Orca software is released under LGPL and GPL licenses.

OpenRDK

OpenRDK is nn open-source software framework for robotics for developing loosely coupled modules. It provides transparent concurrency management, inter-process (via sockets) and intra-process (via shared memory) blackboard-based communication and a linking technique that allows for input/output data ports conceptual system design. Modules for connecting to simulators and generic robot drivers are provided.

ROS

ROS, (Robot Operating System), is a collection of software frameworks for robot software development, providing operating system-like functionality on a heterogeneous computer cluster. ROS provides standard operating system services such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management.

YARP

YARP is is an open-source software package, written in C++ for interconnecting sensors, processors, and actuators in robots.

See also

• RoSta: a European project reaching out to the robotics community to get clearer insights into robotics middleware and architectures.
• BRICs: a European project that attempts to establish best practices in robot development