In January 2010 Willow Garage released version 1.0 of ROS (Robot Operating System) under a BSD licence: a middleware that organises a robot’s software as a graph of independent processes exchanging messages. The name misleads. ROS does not replace the operating system beneath it: it runs on top of Linux and provides communication conventions, a build system and a shared package format.

Context

Until the mid-2000s every robotics lab rewrote its software base almost from scratch: sensor drivers, pose estimation, motion planning, actuator control. The code stayed stitched to the specific hardware and to a single robot’s wiring, and moving it to another platform meant, in practice, starting over.

ROS is not the first attempt to break this pattern. The Player/Stage project, distributed by the University of Southern California from 2001, exposes robot hardware behind a network interface with a client/server model, together with the 2D simulator Stage and the 3D simulator Gazebo (Gerkey, Vaughan, Howard, ICAR 2003). CARMEN, developed at Carnegie Mellon (Montemerlo, Roy, Thrun, IROS 2003), offers a modular navigation toolkit. OROCOS (Bruyninckx, ICRA 2001) works on real-time control; YARP (Metta, Fitzpatrick, Natale, 2006) was built for the humanoid robots of the iCub project. There was, then, no shortage of middleware: the trouble was that it kept proliferating, each piece incompatible with the others.

Architecture

The unit of execution in ROS is the node: a process that does one bounded thing — reading a laser scanner, fusing odometry with an IMU (Inertial Measurement Unit), computing a trajectory. A robotic system thus becomes a graph of nodes, which may run on the same machine or on different machines on the same network.

Nodes talk mostly via topics, under a publish/subscribe model. A node publishes messages on a named topic (say /scan for laser data); whoever is interested subscribes to that topic and receives them, without publisher and subscriber knowing each other. Name resolution goes through a central process, the master (roscore): publishers and subscribers register with the master, which introduces them; from there the data stream travels directly between the two nodes over TCP, with no further intermediary (Quigley et al., ICRA Workshop on Open Source Software, 2009).

Beyond topics, ROS provides services for synchronous request/response interactions, and a centralised parameter server for configuration. Messages have a type declared in .msg files: a generator produces the matching structures for C++, Python and Lisp, so a C++ node and a Python node exchange the same message with no hand-written adapters.

Hardware abstraction lives entirely in this typing convention. If two different lasers publish sensor_msgs/LaserScan on the same topic, the node that builds the map works with both without touching it; likewise a navigation node can run on physically different robots, provided they respect the expected formats.

The critical point

The choice that sets ROS apart from earlier middleware is decoupling by topic name plus message type, rather than by a shared programming interface. In Player a client talks to a driver through an API per device category; in ROS two nodes share neither code nor each other’s identity: they share only the topic string and the message schema. Coupling drops to the minimum, and that minimum you check at runtime — rostopic echo /scan shows what actually transits that channel — while any node becomes replaceable by another that honours the same contract.

The price is that the system’s structure lives in runtime names, not in a static interface policed by the compiler. A misspelt topic, or a type or unit mismatch between publisher and subscriber, does not surface at compile time: the messages simply fail to arrive, or arrive with the wrong meaning. Debugging runs through graph inspection (rosnode, rxgraph) more than through type checking.

Tools

ROS 1.0 ships rviz, a 3D viewer that draws sensor data, maps under construction, transforms between reference frames and joint state in real time. The tf library keeps the tree of geometric transforms between the robot’s frames over time: a recurring problem, and an easy one to get wrong when written by hand for every project.

To develop without physical hardware, ROS relies on Gazebo, the 3D simulator with dynamics that comes from the Player/Stage family: the same executable that would run on the real robot subscribes to the topics produced by the simulated world. The build system (rosbuild, on top of CMake) handles inter-package dependencies and message generation; the package format and manifests help redistribute code across separate groups.

Implications

The BSD licence is a deliberate choice, and anything but secondary: it lets the code be used inside closed products too, and lowers the friction towards industrial adoption compared with a copyleft term. Together with the PR2 beta programme, through which Willow Garage wants to put research robots into the hands of outside labs, it is the lever by which it tries to converge the community onto a common base rather than many incompatible ones. If the bet holds, an algorithm published as a ROS package becomes runnable by anyone with a robot that publishes the right topics, and one group’s work adds to another’s instead of restarting from scratch.

Limits

ROS 1.0 has been out only a short while, and several choices remain to be tested in the field. The model takes for granted a reliable, low-latency network between nodes: it offers no hard real-time guarantees nor native fault-tolerance mechanisms, and the central master is a single point whose loss halts name resolution (already-open connections continue, but no new ones are established). TCP transport introduces variable latency, ill-suited to the tightest control loops, which usually stay outside the ROS graph. Real portability, today, is mostly on Linux. And it is not yet clear whether the ecosystem will reach the critical mass for the promised reuse to become the rule rather than the exception: the history of earlier robotics middleware — all sound on the technical side, none of them having become a standard — is the precedent worth keeping in mind.

https://www.ros.org/news/2010/01/ros-10.html http://ai.stanford.edu/~ang/papers/icraoss09-ROS.pdf https://wiki.ros.org/ROS/Concepts https://playerstage.sourceforge.net/ https://www.noze.it/en/insights/ros-open-source/

Cover image: Willow Garage’s PR2 research robot, with a wheeled mobile base, two arms and a sensor head, on display at a public event (Maker Faire… — photo by Timothy Vollmer, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:PR2_at_Maker_Faire.jpg