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 provides not only standard operating system services (hardware abstraction, contention management, process management), but also high-level functionalities (asynchronous and synchronous calls, centralised database, a robot configuration system, etc.).
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.
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:
- Managing the hardware by writing drivers
- Managing memory and processes
- Managing concurrency, parallelism and data merging
- 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.
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.
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.
Four reasons to believe that Willow Garage will succeed according to the singularityhub.com website:
- They want to provide resources to avoid reinventing the wheel, in order to speed up robotics research;
- They have the necessary funds;
- They have the attention of the research community;
- They want to encourage the roll-out of their technology free of charge, before thinking of earning money.
The general organisation of ROS
ROS’ philosophy can be summarised in the following five main principles:
- Tools-based (microkernel)
- Free and open source.
Covering each point in turn:
Peer to Peer: A sufficiently complex robot comprises several onboard computers or boards connected via Ethernet, plus sometimes offboard computers for intensive computation tasks. A peer-to-peer architecture coupled to a buffering system and a lookup system (a name service called ‘master’ in ROS), enables each component to dialogue directly with any other, synchronously or asynchronously as required.
Multi-language: ROS is language-neutral, and can be programmed in various languages. The ROS specification works at the messaging layer. Peer-to-peer connections are negotiated in XML-RPC, which exists in a great number of languages. To support a new language, either C++ classes are re-wrapped (which was done for the Octave client, for example) or classes are written enabling messages to be generated. These messages are described in IDL (Interface Definition Language).
Tools-based: Rather than a monolithic runtime environment, ROS adopted a microkernel design, which uses a large number of small tools to build and run the various ROS components. As you cover the ROS tutorials, you will learn to use several commands used to manipulate nodes and messages. Each command is in fact an executable. The advantage of this system is that a problem with one executable does not affect the others, which makes the system more robust and flexible than a system based on a centralised runtime environment.
Thin: To combat the development of algorithms that are entangled to a lesser or greater degree with the robotics OS and are therefore hard to reuse subsequently, ROS developers intend for drivers and other algorithms to be contained in standalone executables. This ensures maximum reusability and, above all, keeps its size down. This method makes ROS easy to use, the complexity being in the libraries. This arrangement also facilitates unit testing. Lastly, ROS uses code (drivers and algorithms) from other open source projects:
- Player/Stage project simulators
- Image processing and artificial vision libraries from OpenCV
- Planning algorithms from OpenRave
For a full list of the available algorithms, visit: http://www.ros.org/wiki/StackList
Free and open source: We have already explained the reasons for this choice. Note however that the architecture chosen is consistent with that choice. ROS passes data between modules using inter-process communications and, as a result, modules do not need to be linked within a single process, thereby making the use of different licences a possibility.
Other general-purpose operating systems for robots
There are a few operating systems or robot middleware worth mentioning:
- Microsoft Robotics Developer Studio: a multiplatform system, created by Microsoft. It is free and provides a simulation tool; however, it is only compatible with Windows and is programmed with a managed .NET language (preferably C#);
- NAOQi: open source robotics system produced for the NAO robot by Aldebaran Robotics, and programmed in C++ or Python;
- URBI : produced by the French company Gostai. URBI is a good multi-platform, open source and offers its own scripting language (URBIScript), although it is also programmed in C++.
There are many embedded systems specific to one particular robot, but this is taking us away from the multi-platform model.
The main principles of ROS
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.
The list of ROS-compatible robots grows constantly. For a full list, visit the Willow Garage website at http://www.ros.org/wiki/Robots
The ROS file system
ROS resources are organised into a hierarchical structure on disc. Two important concepts stand out:
- The package: the fundamental unit within ROS software organisation. A package is a directory containing nodes (nodes are explained below), external libraries, data, configuration files and one xml configuration file called manifest.xml.
- The stack: a collection of packages. It offers a set of functionalities such as navigation, positioning, etc. A stack is a directory containing package directories plus a configuration file called stack.xml.
In addition to these two very important notions, the idea of ‘a distribution’ is also worth noting, which is, as in Linux, a collection of versioned stacks.
The latest ROS distributions to date:
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.
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.
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.
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.
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
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 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
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.
Many very useful tools in ROS
As we said earlier, ROS is a collection of tools and algorithms. Some are much-used during programming, simulation or executing robot tasks. Some of the tools and algorithms that the ROS programmer might often encounter are:
- Stage: a 2D simulator
- Gazebo: a 3D simulator
- Rviz: a 3D visualisation system (unlike Gazebo, it does not include a physical motor)
- The tf package, used to manipulate coordinates and transformation (if you have already dealt with inverse kinematics or matrix manipulation, then this package is going to make your life a great deal easier).
- OpenCV: image processing
- PointCloudLibrary: 3D environment reconstruction from laser measurements
ROS’ standard APIs are available from: http://www.ros.org/wiki/APIs
To browse through the packages available (more than 2,000 of them!): http://www.ros.org/browse/list.php
Generation Robots (http://www.generationrobots.com)
All use and reproduction subject to explicit prior authorization.