ROS is an open-source, meta-operating system for your robot. It provides the services you would expect from an operating system, including hardware abstraction, low-level device control, implementation of commonly-used functionality, message-passing between processes, and package management. It also provides tools and libraries for obtaining, building, writing, and running code across multiple computers. ROS is similar in some respects to “robot frameworks”, such as Player, YARP, Orocos, CARMEN, Orca, MOOS, and Microsoft Robotics Studio ^[1]. The ROS runtime “graph” is a peer-to-peer network of processes (potentially distributed across machines) that are loosely coupled using the ROS communication infrastructure. ROS implements several different styles of communication, including synchronous RPC-style communication over services, asynchronous streaming of data over topics, and storage of data on a Parameter Server. All these things would be explained a bit later.

Important! ROS is not a real-time framework, though it is possible to integrate ROS with real-time code.

Distributed Computation
Many modern robot systems rely on software that spans many different processes and runs across several different computers. For example:

• some robots carry multiple computers, each of which controls a subset of the robot’s sensors or actuators;

• even within a single computer, it’s often a good idea to divide the robot’s software into small, stand-alone parts that cooperate to achieve the overall goal. This approach is sometimes called “complexity via composition”;

• when multiple robots attempt to cooperate on a shared task, they often need to communicate with one another to coordinate their efforts;

• human users often send commands to a robot from a laptop, a desktop computer, or mobile device. We can think of this human interface as an extension of the robot’s software.

Software Reuse
The rapid progress of robotics research has resulted in a growing collection of useful algorithms for common tasks such as navigation, motion planning, mapping, and many others. Of course, the existence of these algorithms is only truly useful if there is a way to apply them in new contexts, without the need to reimplement each algorithm for each new system. ROS can help to prevent this kind of pain in at least two important ways.

• ROS’s standard packages provide stable, debugged implementations of many important robotics algorithms;
• ROS’s message passing interface is becoming a de facto standard for robot software interoperability, which means that ROS interfaces to both the latest hardware and to implementations of cutting-edge algorithms are quite often available. For example, the ROS website lists hundreds of publicly-available ROS packages. This sort of uniform interface greatly reduces the need to write “glue” code to connect existing parts.

As a result, developers that use ROS can expect — after, of course, climbing ROS’s initial learning curve — to focus more time on experimenting with new ideas, and less time reinventing wheels.

Rapid Testing
One of the reasons that software development for robots is often more challenging than other kinds of development is that testing can be time-consuming and error-prone. Physical robots may not always be available to work with, and when they are, the process is sometimes slow and finicky. Working with ROS provides two effective workarounds to this problem.

• Well-designed ROS systems separate the low-level direct control of the hardware and high-level processing and decision making into separate programs. Because of this separation, we can temporarily replace those low-level programs (and their corresponding hardware) with a simulator, to test the behaviour of the high-level part of the system.
• ROS also provides a simple way to record and playback sensor data and other kinds of messages. This facility means that we can obtain more leverage from the time we do spend operating a physical robot. By recording the robot’s sensor data, we can replay it many times to test different ways of processing that same data. In ROS parlance, these recordings are called “bags” and a tool called rosbag is used to record and replay them.

A crucial point for both of these features is that the change is seamless. Because the real robot, the simulator, and the bag playback mechanism can all provide identical (or at least very similar) interfaces, your software does not need to be modified to operate in these distinct scenarios, and indeed need not even “know” whether it is talking to a real robot or not. Of course, ROS is not the only platform that offers these capabilities. What is unique about ROS, at least in the author’s judgment, is the level of widespread support for ROS across the robotics community. This “critical mass” of support makes it reasonable to predict that ROS will continue to evolve, expand, and improve in the future.