Please note: this article was written for SmartSoft v1-generation for use with CORBA/SmartSoft and ROS-Electric around 2011. The general principle described here still applies. This page is no longer maintained, but kept for documentation purposes.

For state-of-the-art approaches how to use ROS, see Tutorials

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.

The installation of the Gateway components consists of two parts. First, the two frameworks ROS and SmartSoft have to be installed. Second, the gateway components must be compiled. After that, the navigation scenario with Care-O-bot in Gazebo can be executed as described in User Guide.

Requirements to run the Gateway components:

• SmartSoft: see installation instructions for CORBA/SmartSoft
• ROS: see installation instructions for ROS-Electric (also works with ROS-Diamondback)
• The COB-Experimentation-Days tutorials introduce how to set-up the Care-O-bot environment.
• Optional: MDSD/SmartSoft is required to modify the component's models and the scenario deployment.

At the time of writing there are two gateway components available in SmartSoft (and one further gateway to use a Katana manipulator is under construction).

• SmartROSBaseGateway
• SmartROSLaserGateway

In order to use these gateway components the two frameworks ROS and SmartSoft must be installed first as introduced above. After that, the ROS_PACKAGE_PATH must be adjusted to introduce the Gateway components to ROS as regular ROS-nodes:

$ echo "export ROS_PACKAGE_PATH=\$ROS_PACKAGE_PATH:\
> \$SMART_ROOT/src/components:\$SMART_ROOT/src/utility" >> $HOME/.bashrc

$ bash

This enables the ROS environment to find gateway components as regular ROS components. Before building gateway components itself, the utility smartROSbridge has to be compiled:

$ roscd smartROSbridge/src
$ make ros

This utility consists of two parts. The first part is the bash script “generate_ros_dependencies.sh” which reads the dependency declaration from a “manifest.xml” file and recursively generates corresponding compiler and linker flags. These flags are then stored in the file “ros.mk”. The script is used by all gateway components and by the utility itself to resolve relevant ROS dependencies. The second part of the utility is the implementation of several conversion methods between ROS messages and communication objects of SmartSoft. The command “make ros” builds a library of these methods, which is later used (and linked against) by the gateway components.

Now the gateway components can be compiled:

$ roscd SmartROSBaseGateway/src
$ make ros

$ roscd SmartROSLaserGateway/src
$ make ros

Hint: The special make-target “ros” has to be compiled only once after a fresh checkout of a gateway component. After that, the gateway component can be normally recompiled with “make clean all”, “make all”, “make distclean all” or simply with “make”.

Next, the navigation scenario can be started.

As is shown in the Overview a reasonable way to communicate between components in ROS and SmartSoft is to use specialized Gateway components. The question is how are such components best structured and implemented? This question is answered in the first part below. The second part describes how the navigation scenario can be started.

The Whitepaper-SmartROS-GW.pdf provides a technical analysis of issues concerning the implementation of gateway components interacting between both frameworks (ROS and SmartSoft). The whitepaper further introduces a step-by-step description on how to create a new gateway component and some pitfalls to be avoided.

Before the scenario can be started the corresponding ROS-SmartSoft gateway components must be compiled as described in the installation instructions.

Now it should be possible to start all relevant components for the navigation scenario as demonstrated in the YouTube-Video.

In the first step, the Care-O-bot inside of the Gazebo simulation has to be started (this tutorial provides additional information). The bash script (below) can be used to start Gazebo and to load ipa-kitchen together with the Care-O-bot into Gazebo.

#!/bin/bash

# setup environment variables
export ROBOT=cob3-3
export ROBOT_ENV=ipa-kitchen

# start roscore manually
xterm -e roscore &
sleep 3;

# launch dashboard for Care-O-bot (in background) after 5s
xterm -e "sleep 5; roslaunch cob_experimentation_days dashboard.launch" &

# launch gazebo with Care-O-bot
roslaunch cob_experimentation_days experimentation_days_sim.launch 

echo "Script finished, BYE!";

After some load time, a Gazebo window with the Care-O-bot in the ipa-kitchen should appear:

One of the navigation components in SmartSoft is the CDL component (see below). This component considers the shape of the Care-O-bot for collision-free navigation. Currently one shape is predefined, where the tray is in the position down and the manipulator is in the position folded. In addition, further (more bulky) shapes can be defined, which allow to safely navigate e.g. with the tray in the upper position. Such shapes can be exchanged at runtime according to the current scenario.

Hint: The Gazebo simulation with Care-O-bot and the navigation components of SmartSoft can be executed either on the same or on different hosts. In the latter case the gateway components can be executed either on the host running ROS (in particular roscore) or on the host running SmartSoft (in particular the Naming-Service). In the former case, the host running ROS must be configured to find the Naming-Service of SmartSoft (see corba naming-service instructions). In the latter case, the host running SmartSoft must be configured to find the “roscore” (see ros tutorial for multiple machines). Both ways are equally possible.

Now we can start the navigation components in SmartSoft and the gateway components. The easiest way to do this is to use the predefined deployment (see figure below).

To run the deployment open a new console and type in:

$ cd $SMART_ROOT/src/deployments/DeployROSNavigationDemo/src
$ ./deployROSNavigationDemo.sh start

Hint: The deployment script starts each component in an individual xterm frame. To enable the xterm in Ubuntu to find custom libraries (like ACE+TAO) it is necessary to remove the s bit from the xterm binary. In order to do this execute: “

sudo chmod -s /usr/bin/xterm

” (and run the deployment script again).

should appear (each in a separate console frame). To be able to use the Joystick demo a Logitech Dual Action joystick is required. Otherwise the GoTo scenario can be used without any hardware requirements. The GoTo scenario activates and parametrizes all navigation components (mapper, planner and CDL). To start this scenario, select the smartRobotConsole and choose the menu item 99 (Demos). In the following submenu choose 2 (Planner-CDL GOTO). Now an x/y position (in mm division) can be entered, which is to be approached by the robot. The visualization component shows the simultaneous construction of and localization in a map (SLAM).