Together with software-defined-architecture discussions the automotive manufacturer starting to develop those for its vehicle. In the field of robotics such an operating system is already established with ROS.
Let us have a look at the ROS(2) capabilities via three criteria groups
- Communication
- Framework& tooling
Communication model
What | How |
Data driven exchange | Publish-subscribe via topics. Base on the baseline DDS mechanism. |
Services driven exchange | Remote Methode Invocation (aka RPC) via service endpoints. For long running services the approach is called “action“. Also make use of DDS capabilities. |
Exchange payload | Reuse of DDS data types to describe the message (.msg) payloads as well as service/ action offering and invocation. Via an IDL (.idl) language helper sourcecode in the target language binding can be generated e.g., C++ (.cpp) source code. |
Exchange Quality of Service (QoS) | Also taken from DDS specification. Highly depend on DDS implementation capabilties. |
Exchange discovery | participants for topics and services are called “nodes“. Nodes have to discover other nodes. Here, besides the introduction of DDS, a mayor change between ROS1 and ROS2 happend: – ROS1: Have a central broker – ROS2: Due to DDS not have/ require a central broker |
Exchange protocols | Per definition ROS2 uses DDS as well as inter process communicaton (IPC) via shared memory (SHM). |
The communication happens between “nodes” who construct an distributed execution graph. Further reading article.
Each “node” is intended to be an
- sensor ,
- actuator or even,
- an algorithm.
The integration with specific hardware, as sensor and/or actuator, is made via an API subset called adapter.
Framework
The framework is what keeps the ecosystem vial. It is summarized via:
What | How |
Language binding | In ROS the language binding is also called a client library or short “RCL”. As of the project itself the bindings are given for C++ and Python. Independently e.g., Java, Go, etc. bindings are available. Compare this ROS wiki site here. |
Simulation | Via the tool GAZEBO |
Visualization | Via the tool RVIS |
Perception | Via libraries such as OpenCV |
Threat model | Well defined here |
Clock & time abstraction | Fully abstracted and mandatory precondition for the simulation capability. In addition it is the foundation for enabling record& replay capabilities. Compare the ROS wiki here. |