Robot Operating System 2 (ROS 2) Architecture
By: Huseyin Kutluca
Tags: Ros2, Robotics, Robot Operating System, Software Architecture, Ros2 Architecture

Picture taken from Nasa news

Robot Operating System (ROS) is a set of open source algorithms, hardware driver software and tools developed to develop robot control software. Even though it has operating system in its name it is not an operating system. It is

Communication System (Publish Subscribe and Remote Method Invocation),

Framework & Tools (Build system & dependency management, Visualization, Record and Replay)

Ecosystem (Language bindings, Drivers, libraries and simulation (Gazebo)).

The first version of ROS was mostly used in academic projects. ROS 2 was developed so that it can be used in commercial projects. The biggest change that came with ROS2 was the selection of the DDS middleware for the communication layer. The DDS middleware, which has proven its worth in defense industry projects, has strengthened the communication between robot components with its decentralized publish subscribe architecture. Currently, ROS2 has been adapted 3–4 different DDS products. Since ROS2 is open source, related companies have also offered DDS libraries as open source to the sector. At the same time, ROS 2 has found a wider area of ​​use with multi-robot communication, real-time communication and different platform support. Currently, ROS 2 is used in different areas from humanoid robots to industrial robots and autonomous vehicles.

ROS includes mature open source libraries to be used for navigation, control, motion planning, vision and simulation purposes. The 3D visualization tool called RVIS is an important tool used with ROS. Similarly, the simulation tool called Gebazo is seen as an usefull tool for robot developers. Apart from this, Open CV library is a library used for detection purposes in ROS 2. In addition, we see that the QT graphic library is also used for the user interface in ROS 2 projects and is an add-on available for this purpose.

ROS 2 content (picture from Ros2 wiki)

In this article, I will not mention the capabilities of the existing libraries and tools in ROS 2, how to set up ROS 2, and the details of how to develop code with ROS 2. There are resources and trainings that explain these issues. I will try to explain to you the ROS 2 architecture, which I have not seen clearly explained.

ROS 2 Architecture

The ROS 2 has distributed real-time system architecture. Sensors in robots, motion controllers, detection algorithms, artificial intelligence algorithms, navigation algorithms, etc are all components (called as node) of this distributed architecture. The DDS middleware selected with ROS 2 for data exchange enables these components to communicate with each other in a distributed environment.

What kind of components are there in a robot control software

ROS 2 has provided its own abstraction layer (rmw) on top of DDS instead of directly using the DDS middleware. Thus, the details of the DDS middleware interface are abstracted from the user. In the current ROS 2 versions, Fast-DDS comes as the standard DDS version. Apart from that, rmw support is available in different DDS products. The user can select and use the DDS library they want, and even thanks to the network level interoperability, it is possible to use more than one DDS library in the same project.

ROS2 Client Library (picture from Ros2 wiki)

ROS 2 Client Library

ROS 2 applications access ROS 2 features through the ROS Client Library (RCL) client library. The Rcl library is written in C language and on it there are Rclcpp client libraries for C ++ language and Rclpy for Python language. There are independently written ROS 2 client libraries in other languages ​​such as Java, Go. The client library is primarily provided with the standard interface required to exchange data with Topic and Service approaches over ROS 2. In addition, the ROS2 library has capabilities to provide operating system abstraction and ready-made micro-architectural structures.

ROS 2 Graph Structure

The node, topic, message structure, and discovery form the basic distributed architecture of ROS 2. This structure is called a graph in ROS 2 terminology. Let’s get into the details of these architectural basic structures.

Ros 2 Grpah (picture from Ros2 wiki)

Node

Distributed applications are designed as units known as Nodes. In a robot system, sensors (Lidar, camera) motion controllers (motors providing motion), algorithm components (route planner) can be nodes each. ROS 2 separates the node concept from the operating system level process structure. If desired, multiple nodes can be created within a process and these nodes can communicate independently with other nodes. All nodes in the system can be run on a single computer or they can be distributed and run across multiple computers.

Topic and Service

Nodes communicate with each other via Topic and Service Invocation. The topic based communication has publish subscribe architecture where the data produced and publisged by a node is subscribed by more than one node and similarly, one topic data can be produced to more than one node. Topics defined in ROS 2 exactly match DDS topics. Service calls use a remote method invocation approach from an application developer perspective. These service calls are also implemented as request topic and response topic over the DDS middleware.

Decentrilized architecture of Top’c structure creates advantage in terms of both performance and fault tolerance. In addition, rich quality of service features provided by the DDS middleware have also been a factor that raised the ROS 2 architecture to higher levels.

Messages (Message)

The data types used in topic communication are called message (Message). These Message data structures basically match the DDS data types (Type). A sample camera message is given below:

sensor_msgs/CameraInfo

Header header

uint32 seq

time stamp

string frame_id

uint32 height

uint32 width

RegionOfInterest roi

uint32 x_offset

uint32 y_offset

uint32 height

uint32 width

float64[5] D

float64[9] K

float64[9] R

float64[12] P

The messages defined in ROS 2 are actually of great importance for interoperability. With the help of these standard messages, cameras developed by different companies can be quickly integrated into the system and can communicate with standard messages regardless of the model camera. In this case, the Node component developed for the relevant camera will convert the camera’s special communication protocol messages into standard DDS data. Preliminary studies can be performed using the camera simulator in the Gebazo simulation.

ROS 2 also effectively uses the quality of services (QOS) defined in the DDS middleware. For example, while continuously updated sensor data is sent in best effort, a command sent to the robot to do a job can be sent reliably. Matching the rich quality of service features in DDS with the topics is an important design decision. Ready-made service quality profiles that can be used according to the type of data are defined and the service quality related to newly defined topics is determined by selecting one of these profiles.

The QOS profiles defined in ROS 2 are known by service, sensor data, parameters and default. For example, the parameters use the reliable service quality value while the sensor data uses the best effort QOS value.

Discovery of applications in a distributed environment

In ROS 1, the discovry mechanism and message transmission were communicating through a service called Roscore. DDS middleware does not need a broker to distribute data. In addition, applications in the DDS middleware dynamically discover each other through special DDS topics. As a result, DDS has switched ROS 2 to a decentralized architecture by meeting the discovery, distribution and data encoding needs of ROS 2. So, in the new architecture, the Roscore service has been retired.

ROS2 Device adaptation

We mentioned that devices such as sensors and handlers in robot systems are integrated into the ROS 2 system as a node. The code required to be written for the integration of these devices is called the Adapter (wraper) in ROS terminology. This approach shows a similar structure to the approach we have seen in open architecture systems. For example, the adapter software to be developed for a motor controller will publish the data as topic (current speed and motor status) independently from the relevant motor controller interface and transmit the topic data to the motor (Speed ​​command). If requested, a service interface can be provided for camera control (engine shutdown). This adapter software will be able to get the parameters of the motor from the parameter server and start the motor with these parameters (maximum speed).

An engine adapter node architecture ( picture from roboticsbackend.com)

Parameter Server

One of the common services that can be considered as an architectural unit in ROS 2 is the parameter server. In this way, all nodes can store and retrieve the parameters they want to keep.

Recording and Playback

ROS 2 has ROS2 Bag service for recording and replaying DDS data. Recording and replay can be used effectively in such distributed real-time systems for post-mission behavior analysis and testing purposes.

ROS1-ROS2 Bridge

It is an adapter software developed for the use of nodes currently developed with ROS-1 in ROS-2 environment.

ROS 2 and Its Use in Safety-Critical Projects

In recent years, ROS2 has attracted great attention, especially by autonomous vehicle developers. These companies have started prototypes based on ROS2, which offers many infrastructures for the systems they will develop themselves. Well, if the prototype works are successful, the open source ROS2 libraries will not meet the safety requirements (ISO 26262) required by the automotive world. Of course, infrastructure companies, seeing this situation, started to adapt ROS 2 libraries to real-time operating systems. In addition, companies has started to prepare ROS2 libraries that can be used in safety critical projects together with their relevant tests and documentation.