II

Simulation and Visualization in ROS

INTRODUCTION

Valuable characteristics of ROS include its simulation and visualization capabilities. When software development can be performed only on specific hardware (e.g. a particular robot), productivity plummets. A physical robot is typically a bottleneck for development, because it is a limited resource presumably shared by a team. Further, some robots, including vehicles and humanoids, require teams to run experiments. Most often, the robot and team are idling while a programmer is seeking errors in code under test.

With a suitable robot simulator, code can be developed under simulation, allowing work to proceed in parallel and without imposing on a support staff for experiments. If the simulator has high fidelity (providing a good approximation of the actual robot behavior), few or no changes may be required to run the same code on the physical system.

One of the common barriers is that code written for simulation may need to be modified significantly to run on the physical system. This is an issue addressed by ROS. Typically, code written for simulation in ROS requires no changes (not even recompilation) to run on a target physical system. Using ROS’s messaging system, nodes are indifferent to where other nodes reside in the system, as long as the message types, topic names, and server names are consistent.

A ROS-enabled robot should publish its sensory data to named topics with defined message types, and the corresponding simulator should publish the same (simulated) information on the same topics with the same message types. If this is achieved, switching a perceptual processing system from simulation to a physical system requires only that the physical system (rather than the simulator) start publishing the information.

In the other direction, one controls a robot by publications to topics (or ROS service requests or ROS action server goal requests). This interface is defined in terms of topic names, message types and server names. If the simulator responds to these publications or requests in the same manner as the physical system, the controller code that runs on the simulation would run identically using the actual robot.

Similarly, human-machine interfaces may be developed with respect to a robot (and environment) simulator, and the developed code may be used verbatim with the physical system. Although the simulator becomes unnecessary when running the physical hardware on the target system, the human interface developed under simulation can be re-used without change from simulation to hardware.

The success of developing software in simulation depends on the quality of the simulator. Fortunately, ROS has powerful simulation capabilities, both for robot dynamics and for sensor emulation in virtual worlds. These capabilities will be introduced in this section.