The Need in Analysing the DDS Services
As I have mentioned in earlier posts, I have been working on migrating our vehicle platform components to ROS2 middleware. I just wanted to let all you know about the importance in choosing the right and perfect DDS – Data Distribution Service as a RMW middleware while creating your autonomous applications.
Time Critical Requirement
As part of my vehicle platform migration journey, one of my frameworks (external X-by-wire system) requires a real-time response in the range of few milliseconds (2 millisecond – 5 millisecond) while executing 50+ nodes with the 800 Bytes size of each message packet on a vehicle’s X-by-wire ECU.
Considering the above time critical requirement, I am supposed to consider the Realtime and deterministic response for each and every message which goes through every layer of ROS2 framework from the latency perspective.
Approach
Then I started analysing the approach which is being offered by the ROS2 OSRF to choose the right DDS middleware to address my requirement. I was able to find few materials about benchmarking the various DDS service vendors framework over ROS2 framework layers and also, I realized that there are standard results also made available by ROS2 OSRF for every release of its distribution.
Ok. Let us have look at How and on what basis I have selected the right and perfect DDS middleware for my vehicle platform ROS2 build by analysing the end-to-end latency of ROS2 data-processing pipeline with different DDS middleware.
ROS2 Supported DDS Vendors & Its Architecture of ROS Pipeline
As we all aware that the current ROS2 distribution Galactic supports the DDS services such as
1. FastRTPS,
2. Cyclone DDS,
3. Gurum DDS,
4. RTI’s Connext DDS
5. OpenSplice DDS
ROS 2 Pipeline
The below picture depicts the detailed architecture with its various components layers available in the ROS2 framework. The reason is to keep this available in the current section is showcase the layers which will be part of the latency evaluation study that we have planned here.
The Goal
The goal is to choose any one of the DDS vendors to achieve the real-time or at least near real-time responses with minimal latencies in information exchange via ROS2 framework layers.
The Benchmarking Criteria
I will try to abstract and give you the briefing of the benchmarking of various DDS services has been made over the various criteria such as node count, message size, communication protocol (TCP – ROS1/UDP – ROS2), the QoS profiles for the publisher and subscriber, memory consumption, threads per nodes (Executors – which is another critical thing to make your vehicle platform compliant with deterministic responses).
Profiling Platform
Desktop Computer with the configuration of Intel i7-8700 CPU @ 3.2 GHz x 6, 32GB RAM.
The Results – Referred
The profiling has been done for FastRTPS, Cyclone DDS and RTIs Connext with the variable parameters such as
Message Size : 100B – 500 KB
Publisher Frequency : 1Hz – 100 Hz
Number of Nodes : 3 – 23 Nodes
Basis on the results that has been received from the profiling, for a payload of 100 B, the results indicate a linear relationship between the number of nodes which are present in the X-axis and the median latency for DDS Services. In the case of RTI’s Connext, a nonlinear relationship for smaller frequencies is visible. Furthermore, Connext only yields results until 15 nodes, as for higher node numbers the Connext raises exceptions.
Conclusion and Selection of DDS Framework for Realtime Autonomous Vehicle Application
Considering the results provided above, its clearly visible that the CYCLONE DDS outperforms when compared to another DDS framework. I moved ahead with the Cyclone DDS with my ROS2 build for my X-by-wire application to make it more reliable, stable, linear and responsive.
I will refine my DDS selection for the next ROS2 distribution basis on the improvements, results that will be provided by ROS2 OSRF.
References
1. https://osrf.github.io/TSC-RMW-Reports/galactic/
2. https://discourse.ros.org/t/fast-dds-selected-as-the-ros-2-humble-default-middleware/23374
4. https://drops.dagstuhl.de/opus/volltexte/2019/10743/pdf/LIPIcs-ECRTS-2019-6.pdf
