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:
At a conceptual level, a complex robot controller has components that each serve one of the following four concerns:
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:
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:
Urbi
Urbi is an open source cross-platform software platform in C++ used to develop applications for robotics and complex systems. It is based on the UObject distributed C++ component architecture. It also includes the urbiscript orchestration language which is a parallel and event-driven script language. UObject components can be plugged into urbiscript and appear as native objects that can be scripted to specify their interactions and data exchanges. UObjects can be linked to the urbiscript interpreter, or executed as autonomous processes in "remote" mode, either in another thread, another process, a machine on the local network, or a machine on a distant network.
Wasp Actuator Sensor Protocol
[To be done]
Orca2
[To be done]