ROS – Robot Operating System

What is ROS?

ROS in a nutshell…

As the full name of Robot Operating System suggests, ROS is an operating system for robots. In the same way as operating systems for PCs, servers or standalone devices, ROS is a full operating system for service robotics.

ROS is in fact a meta-operating system, something between an operating system and middleware. It is a set of free open source software libraries that help its users develop robotics applications.

It provides a range of features standard to an operating system:

1. Hardware abstraction
2. Contention management
3. Process management

ROS also provides high-level functionality:

1. Asynchronous calls
2. Synchronous calls
3. Centralized database of data
4. Robot configuration system

The benefit of an OS for robots

Before robot operating systems, every robot designer and robotics researcher would spend considerable amounts of time designing the embedded software within a robot, as well as the hardware itself. This required skills in mechanical engineering, electronics and embedded programming. Typically, the programs engineered in this way were more akin to embedded programming, similar to electronics, than they were to robotics in the strictest sense, such as we might encounter it nowadays in service robotics. There was considerable re-use of programs, as they were strongly linked to the underlying hardware.

The main idea of a robotics OS is to avoid continuously reinventing the wheel, and to offer standardised functionalities performing hardware abstraction, just like a conventional OS for PCs, hence the analogous name.

ROS is a robotics project facilitator. Researchers or engineers in R&D divisions that use ROS no longer spend time creating a new ecosystem for each new robotics project. This also represents a financial gain.

ROS has an positive impact on R&D by reducing costs and the “time to market”. For structures or departments which goal is launching a new prototype quickly, or who need to reduce a technological gap, it becomes quite attractive.

Another benefit of robot operating systems such as ROS is that of combining expertise from different disciplines. In fact, designing and programming a robot means:

1. Managing the hardware by writing drivers
2. Managing memory and processes
3. Managing concurrency, parallelism and data merging
4. Providing abstract reasoning algorithms, making great use of artificial intelligence.

Robotics therefore requires very different skills sets, typically beyond the range of a single individual.

ROS lowers the technical level required to work on robotics projects. This can make it easier for many companies to get started in robotics, or to design complex systems more quickly.

The history of ROS

Many robot frameworks exist, produced for a specific reason, for prototyping purposes. ROS was intended to be more general-purpose, although its designers do not believe it to be the ultimate OS able to do everything.

Before 2007, the year of ROS release, robotics engineers did not have a standard embedded software architecture. That’s why ROS is a major leap forward.

ROS is developed and maintained by a Californian company, Willow Garage, formed in 2006 by Scott Hassan, one of Google’s first employees who was involved in the development of search engine technology and who was also behind Yahoo! Groups (eGroups, in fact, which became Yahoo! Groups). The President and CEO of Willow Garage is Steeve Cousins, previously at IBM.

Willow Garage is a private company that maintains close links with Stanford University, which is not far from Willow Garage (in Palo Alto, California).

Willow Garage describes itself as a research laboratory and technology incubator for personal robotics, focused on research more than on profits (at the outset, at least).

Willow Garage develops both software with ROS and hardware with their PR2 and TurtleBot robots. Everything produced is open source (BSD licences). Their idea is that if we want to see robots reach our homes, then research needs to be accelerated by providing solid hardware and software bases that are open source.

It would appear that Willow Garage wishes to build the robotics community rather than robotics in and of itself. Interviewed by business magazine L’Expansion, Scott Hassan said that his objectives are the same as those of Irobot, but that the strategy to achieve them is different.

Programming with ROS

ROS is language-independent. At this time, three main libraries have been defined for ROS, making it possible to program ROS in Python, Lisp or C++. In addition to these three libraries, two experimental libraries are offered, making it possible to program ROS in Java or Lua.

ROS-compatible robots

The list of ROS-compatible robots grows constantly. For a full list, visit the Willow Garage website at http://www.ros.org/wiki/Robots

However, it is worth mentioning the best-known, namely NAO, Lego Mindstorms NXT, IRobot Roomba, TurtleBot and last but definitely not least, Willow Garage’s iconic PR2.

Basic notions in ROS

The basic principle of a robot operating system is to run a great number of executables in parallel that need to be able to exchange data synchronously or asynchronously. For example, a robotics OS needs to query robot sensors at a set frequency (ultrasound or infra-red distance sensor, pressure sensor, temperature sensor, gyroscope, accelerometer, cameras, microphone, etc.), retrieve this data, process it (carry out what is known as a data merge), pass it to processing algorithms (speech processing, artificial vision, SLAM – simultaneous localisation and mapping, etc.) and lastly control the motors in return. This whole process is carried out continuously and in parallel. Moreover, the robotics OS needs to manage contention to ensure efficient access to robot resources.

The concepts brought together in ROS under the name of “ROS Computation Graph”, enabling these objectives to be reached, are described below. These are concepts used by the system as it is running, whereas the ROS File System described in the previous section is a static concept.

Nodes

ROS addresses this entire issue using some simple basic notions. The first of these is the notion of the node.

In ROS, a node is an instance of an executable. A node may equate to a sensor, motor, processing or monitoring algorithm, and so on. Every node that starts running declares itself to the Master. This comes back to the microkernel architecture, whereby each resource is an independent node.

Thanks to the nodes system, basic functions can be standardized, and technological building blocks can be quickly developed and easily reused, modified, or improved.

Master

The Master is a node declaration and registration service, which makes it possible for nodes to find each other and exchange data. The Master is implemented via XMLRPC.

The Master includes a heavily-used component called the Parameter Server, also implemented in the form of XMLRPC, and which is, as the name implies, a kind of centralised database within which nodes can store data and, in so doing, share system-wide parameters.

Topics

Data is exchanged asynchronously by means of a topic and synchronously via a service.

A topic is a data transport system based on a subscribe/publish system. One or more nodes are able to publish data to a topic, and one or more nodes can read data on that topic. A topic is, in a way, an asynchronous message bus, a little like an RSS feed. This notion of an asynchronous, many-to-many bus is essential in a distributed system situation.

A topic is typed, meaning that the type of data published (the message) is always structured in the same way. Nodes send and receive messages on topics.

Messages

A message is a compound data structure. A message comprises a combination of primitive types (character strings, Booleans, integers, floating point, etc.) and messages (a message is a recursive structure). For example, a node representing a robot servo motor will certainly publish its status on a topic (depending how you programmed it) with a message containing, for instance, an integer representing the motor’s position, a floating point for its temperature, another floating point for its speed, and so on.

The message description is stored in package_name/msg/myMessageType.msg. This file describes the message structure

Services

A topic is an asynchronous communication method used for many-to-many communication. A service meets a different kind of need; that for synchronous communication between two nodes. The idea is similar to that of a remote procedure call.

The service description is stored in package_name/srv/myServiceType.srv. This file describes the data structures for requests and responses.

Bags

Bags are formats for storing and playing back message data. This mechanism makes it possible, for example, to collect data measured by sensors and subsequently play it back as many times as desired to simulate real data. It is also a very useful system for debugging a system after the event.

The rxbag tool can be used to display data saved in bag files in graphical form

URDF

ROS provides other concepts that we will be able to explore in a further article. Mention should nevertheless be made of (another) interesting contribution to robotics from ROS in the shape of URDF (Unified Robot Description Format), an XML format used to describe an entire robot in the form of a standardised file. Robots described in this way can be static or dynamic and the physical and collision properties can be added to it.

Besides the standard, ROS offers several tools used to generate, parse or check this format.

URDF is used by the Gazebo simulator, for example, to represent the robot.

Resources

1. www.ros.org