Robotics middleware is middleware to be used in complex robot control software systems. It is the glue software that every system developer wants to use to connect software (and hardware) components together. The composition of sub-systems into a new system is a difficult task, with currently close to no support from software tools, or from internationally accepted standards and workflows.
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, 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, runtime,…
- Coordination: the activities in components have to be coordinated by something at the system level, in order to guarantee the expected behaviour and peformance of the composed system. Coordination involves: decision making, scheduling, (de)activating subsystems and/or their interconnections,…
Composing two or more components that each belong to one of these categories is an architectural design activity. It is very 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, are 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.
See also
- RoSta: a European project reaching out to the robotics community to get clearer insights into robotics middleware and architectures.