Multimaster

Separate-Master approach

Rationale

We are trying to "hide" internal topics used by STDR Simulator behind a different ROS master and leave a clean environment for user code. This approach is also followed by rostest, using a different ROS master for user nodes, with the difference that no communication is required between nodes under different masters.

This approach comes to resolve several known issues regarding conflicts in tf and/or topic names. Real problems start when someone is trying to do localization and mapping, leaving as the only option to touch STDR code or modify user code. The separate-master approach comes with the downside of increased complexity for the novice user who just wants to get measurements from sensors. Finding a way to automate the whole process and make it transparent to the user is the first priority, although it is not straightforward.

Currently, multimaster use cases are supported, in ROS, by rocon and multimaster_fkie. We chose the latter, as it seemed simpler and easier to understand at the time. Multimaster_fkie is capable for full-duplex synchronization between different masters but in our use case we require only one-way synchronization as we want to expose topics from simulator to the user.

Example

Lets suppose that we have a urdf file for our robot and we want to simulate localization, mapping and navigation capabilities. Having a urdf means that we no longer need the transformations published by STDR regarding the pose of the sensors (as it can be done by robot_state_publisher) and since we are performing localization we don't need the pose of the robot itself, published also by the simulator. Finally, we have to translate the urdf file (the bare minimum of it) to a file that is acceptable by STDR and describes the robot.

Simulation side

We start by launching the simulator to a ROS master on a different port than the default, lets say 11312. This can done by running:

export ROS_MASTER_URI=http://localhost:11312
roslaunch stdr_launchers server_with_map_and_gui_plus_robot.launch

or by just running:

roslaunch stdr_launchers server_with_map_and_gui_plus_robot.launch --port 11312

In multimaster_fkie branch you will find a patched version of stdr_launchers package, where all launchers contain the appropriate changes for communication between different masters. The addition is just a single node:

<launch>
  ...
  <node pkg="master_discovery_fkie" type="master_discovery" name="master_discovery"/>
  ...
</launch>

User side

Now we want to run our code (slam and navigation) under a new ROS master using the default port. In order to so, we want to be able to get messages from topics representing the simulated sensors by stdr. We have to synchronize specific topics running on a different master. We can do that by running:

 roslaunch stdr_launchers client.launch 

This launcher spawns two more nodes, one for master discovery (as above) and one for synchronization:

<launch>

  <node pkg="master_discovery_fkie" type="master_discovery" name="master_discovery" />

  <node pkg="master_sync_fkie" type="master_sync" name="master_sync">
    <rosparam param="ignore_services">['/*replace', '/*list', '/*load_nodelet', '/*unload_nodelet']</rosparam>
    <rosparam param="sync_nodes">['/robot_manager']</rosparam>
    <rosparam param="ignore_topics">['/map*', '/tf*', '/stdr_server*']</rosparam>
  </node>

</launch>

Then we can run our code having available only the topics we want and excluding others like tf.

Problems - Concerns

• Before launching the simulator you have to specify the port manually, there isn't a way to do it automatically(?).
• Every time you want to use a command-line tool, or other simulator-related nodes, you have to export the correct ROS_MASTER_URI manually.
• The messages we are getting use frame_ids that do not exist (because we are not syncing the tf topic) and are not configurable (see below).
• Topic names for sensors are assigned automatically (in the form of robot0/laser_0) and the user does not have any control. Only the frame_id can configured externally but to make matters worse, not completely. For example, if we set the frame_id for a laser sensor to be scan we get a frame_id in the form of /robot0_scan and a topic name /robot0/scan.
• A partial solution to the above is to use a topic relay, part of the topic_tools package and rename the topic as you wish. Still the wrong frame_id issue remains.
• A more complete solution is to use another tool of the toopic_tools package, the transform to change the frame_id and the topic name. (transform only available for indigo currently)
• Any solution should be transparent to the user and not require significant configuration. Is it possible with the above mentioned solutions?

Conclusion

STDR Simulator is designed to be a simple and lightweight simulator. We have to make sure that we are not adding more layers than needed with these changes and thus making it slower and unreliable. The concept of isolating simulation from user code is a step to the right direction but we have to be careful not to sacrifice simplicity and ease of use. I believe that the user should not touch his/her code at all in order to test it with STDR and only make changes to STDR's configuration files.