Robot Operating System 2 (ROS 2) Architecture
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 Gazebo is seen as a 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.
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.
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.
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.
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.
Communication Patterns (Topic, Service, Action)
Nodes communicate with each other via Topic, Service Invocation and Actions. The topic based communication has publish subscribe architecture where the data produced and published 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. Actions are an approach used for long service calls. The client requests an action with goal, the action server starts the long-running process, publishes intermediate results, and reports the final result when the goal is achieved. These service and actions are also implemented using topics over the DDS middleware.
Decentralized architecture of Topic 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] PThe 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 discovery 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 (wrapper) 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).
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.
C4 Diagrams:
https://github.com/hkutluca/yazilimmimarileri/tree/master/ROS2
