Components and Toolchain for Robotics
New video of SmartSoft MDSD Toolchain
New video: The butler scenario.
A new section demonstrates the creation and usage of Gateway components.
SmartSoft MDSD Toolchain 0.10.4 released. Components update released. New Videos available.
New video of our robot "Kate" cleaning up the table.
The ACE based SmartSoft version 1.8.0 is available on Sourceforge. Technical reports available.
Switch to Model Driven Software Development for all published SmartSoft components and communication objects. Many new components published. Getting-Startet-Tutorial added. Toolchain 0.10.2 released.
Description of several components and their services added.
The ACE based SmartSoft version 1.7.2 is available on Sourceforge. ACE / SmartSoft on Sourceforge
SIMPAR 2010: Tutorial on "Model-Driven Software Development in Robotics"
SmartSoft MDSD Toolchain version 0.8.0 released. SmartSoft VMWare on Sourceforge
The new VMWare Image of SmartSoft including the SmartSoft MDSD Toolchain is available for download. SmartSoft VMWare on Sourceforge
The field of service-robotics is a growing market and is thus of huge interest for many research groups around the world. This leads to the problem of many concurrent developments of robotic middlewares and frameworks focusing on particular tasks and use-cases. As a result, there are a lot of such frameworks available (most of them even open-source) and many of them contribute to service robotic not only with middleware structures, but also with components (or algorithms) build on top of these frameworks. Thus, many of them are valuable from their individual point of view.
On the other hand, as in software development in general, it is often a bad idea to reinvent the wheel over and over again and thus a common need arises to reuse existing software (resp. algorithms and components in robotics). In doing so, an obvious challenge is the interoperability problem between incompatible middlewares in robotics. In most cases it is impossible (or at least not feasible) to extract those parts of interest from one framework and integrate them into the other framework. This would result in a huge implementation effort, a parallel maintenance of sources and still would not generally solve the problem.
Another approach is to bridge between these frameworks. Although this certainly leads to some communication overhead and delay, the advantage of gained interoperability and loosely coupled components (or algorithms) in one framework from those in the other framework, overcomes the disadvantages.
If one decides to bridge between the frameworks a further question remains. Which is the right level of abstraction for communication? For example a communication bridge between two frameworks could be either implemented on the communication level (like TCP), the middleware level (like CORBA) or even on framework level (like ROS or SmartSoft).
The communication and middleware levels are in most cases not applicable, because the frameworks implement on top of these layers additional logic and protocols, which would have to be implemented in the opposing framework. One potential exception is the rosbridge interface in ROS. Although it seems to alleviate the problem on the first view, a deeper insight shows that the main problem remains, namely that the glue logic between structures and semantics from ROS must be implemented somewhere in the opposing framework.
SmartSoft and ROS communicate on a framework level and they are optimized for the robotics domain. In addition, both frameworks provide a sufficient abstraction level for communication with a reasonable granularity, that allows to define a translation mechanism between both communication types. For instance, ROS provides messages (e.g. Odom) which are similar to corresponding communication objects (e.g. BasePose) in SmartSoft. This translation mechanism is called a Gateway or respectively Gateway Component (see illustration below).
A Gateway component is the intermediate part between nodes running in ROS and components running in SmartSoft (see figure above). A gateway component provides two types of communication interfaces. As shown in the figure the left interface is only visible inside of ROS (resp. for all ROS nodes), whereas the interface on the right is only visible for SmartSoft components. Thus the gateway appears for all ROS nodes as a regular node, without spreading SmartSoft specific details over the boundaries of the gateway and vice versa. This offer the advantage that changes in one of the systems do not affect the other system (except the gateway component itself). In other words, the gateway decouples the sphere of influence between these two systems.
As a consequence the gateway component must use the infrastructure of the two frameworks at the same time. A common problem is that the two event handlers from the underlying middlewares must work in the same process without affecting each other. Fortunately, in SmartSoft, as well as in ROS the corresponding event handlers are matured enough to be executed and decoupled in separate thread spaces.
The main internal part of a gateway component is the glue logic which maps messages from one framework to the other. It consists of converting and copying data structures from one framework into corresponding structures from another framework. This can range from direct copying of values to transformations and aggregations of data. A gateway component does not restrict this process in any case. However, the glue logic is most affected to changes in one of the frameworks. Thus, a good strategy is to outsource this part into an external library, which can be linked to the gateway component and which is easier to maintain.
SmartSoft provides a stringent component model to define middleware independent components and their interfaces. Currently two implementations of the SmartSoft idea are available. The first is based on CORBA (using ACE/TAO library) and the other is based on simple massage passing (using Adaptive Communication Environment). The abstracted communication interface is based on communication patterns. A particular interface of a component (resp. a component's service) is specified by initializing communication patterns with particular communication objects as template parameters. An example for a communication object is given here. Thus, data structures that are communicated between components are fully defined by communication objects. To be able to communicate with ROS these communication objects must be converted at runtime into corresponding ROS messages (and vice versa).
The communication in ROS is mainly based on messages and services. In addition to the mapping of ROS messages onto SmartSoft's communication objects, the threading model (which is part of SmartSoft's communication patterns) must be mapped (or emulated) as well. One particular difference between ROS and SmartSoft is the way of transforming coordinate systems. In ROS the TF package is doing the work, whereas in SmartSoft the coordinate transformations are part of communication objects. This part must be transformed and emulated as well.