Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Performance Evaluation of ROS2-DDS middleware implementations facilitating Cooperative Driving in Autonomous Vehicle

Sumit Paul, Danh Lephuoc, Manfred Hauswirth

TL;DR

The paper tackles the challenge of scaling cooperative driving communications in autonomous vehicles by evaluating how vendor-specific DDS implementations perform in ROS2 across same-domain and different-domain communications. It introduces a parameter-rich methodology using diverse hardware (e.g., Raspberry Pi, Jetson Nano, laptops), multiple data types (Binary, String, IMU), and variable publisher frequencies to measure latency via Round Trip Time with a correction for intermediate processing. The study provides the first comprehensive cross-domain benchmarking across Eclipse Cyclone DDS, eProsima Fast DDS, RTI Connext DDS, and bridging considerations, revealing that no single DDS dominates and that same-domain communication often yields lower latency, though cross-domain advantages appear for certain large payloads. These findings offer actionable guidance for robotics developers on selecting data types, mediums, and DDS implementations to optimize ROS2-based cooperative perception, while highlighting the need for cross-vendor collaboration to better meet real-time requirements in multi-domain settings.

Abstract

In the autonomous vehicle and self-driving paradigm, cooperative perception or exchanging sensor information among vehicles over wireless communication has added a new dimension. Generally, an autonomous vehicle is a special type of robot that requires real-time, highly reliable sensor inputs due to functional safety. Autonomous vehicles are equipped with a considerable number of sensors to provide different required sensor data to make the driving decision and share with other surrounding vehicles. The inclusion of Data Distribution Service(DDS) as a communication middleware in ROS2 has proved its potential capability to be a reliable real-time distributed system. DDS comes with a scoping mechanism known as domain. Whenever a ROS2 process is initiated, it creates a DDS participant. It is important to note that there is a limit to the number of participants allowed in a single domain. The efficient handling of numerous in-vehicle sensors and their messages demands the use of multiple ROS2 nodes in a single vehicle. Additionally, in the cooperative perception paradigm, a significant number of ROS2 nodes can be required when a vehicle functions as a single ROS2 node. These ROS2 nodes cannot be part of a single domain due to DDS participant limitation; thus, different domain communication is unavoidable. Moreover, there are different vendor-specific implementations of DDS, and each vendor has their configurations, which is an inevitable communication catalyst between the ROS2 nodes. The communication between vehicles or robots or ROS2 nodes depends directly on the vendor-specific configuration, data type, data size, and the DDS implementation used as middleware; in our study, we evaluate and investigate the limitations, capabilities, and prospects of the different domain communication for various vendor-specific DDS implementations for diverse sensor data type.

Performance Evaluation of ROS2-DDS middleware implementations facilitating Cooperative Driving in Autonomous Vehicle

TL;DR

The paper tackles the challenge of scaling cooperative driving communications in autonomous vehicles by evaluating how vendor-specific DDS implementations perform in ROS2 across same-domain and different-domain communications. It introduces a parameter-rich methodology using diverse hardware (e.g., Raspberry Pi, Jetson Nano, laptops), multiple data types (Binary, String, IMU), and variable publisher frequencies to measure latency via Round Trip Time with a correction for intermediate processing. The study provides the first comprehensive cross-domain benchmarking across Eclipse Cyclone DDS, eProsima Fast DDS, RTI Connext DDS, and bridging considerations, revealing that no single DDS dominates and that same-domain communication often yields lower latency, though cross-domain advantages appear for certain large payloads. These findings offer actionable guidance for robotics developers on selecting data types, mediums, and DDS implementations to optimize ROS2-based cooperative perception, while highlighting the need for cross-vendor collaboration to better meet real-time requirements in multi-domain settings.

Abstract

In the autonomous vehicle and self-driving paradigm, cooperative perception or exchanging sensor information among vehicles over wireless communication has added a new dimension. Generally, an autonomous vehicle is a special type of robot that requires real-time, highly reliable sensor inputs due to functional safety. Autonomous vehicles are equipped with a considerable number of sensors to provide different required sensor data to make the driving decision and share with other surrounding vehicles. The inclusion of Data Distribution Service(DDS) as a communication middleware in ROS2 has proved its potential capability to be a reliable real-time distributed system. DDS comes with a scoping mechanism known as domain. Whenever a ROS2 process is initiated, it creates a DDS participant. It is important to note that there is a limit to the number of participants allowed in a single domain. The efficient handling of numerous in-vehicle sensors and their messages demands the use of multiple ROS2 nodes in a single vehicle. Additionally, in the cooperative perception paradigm, a significant number of ROS2 nodes can be required when a vehicle functions as a single ROS2 node. These ROS2 nodes cannot be part of a single domain due to DDS participant limitation; thus, different domain communication is unavoidable. Moreover, there are different vendor-specific implementations of DDS, and each vendor has their configurations, which is an inevitable communication catalyst between the ROS2 nodes. The communication between vehicles or robots or ROS2 nodes depends directly on the vendor-specific configuration, data type, data size, and the DDS implementation used as middleware; in our study, we evaluate and investigate the limitations, capabilities, and prospects of the different domain communication for various vendor-specific DDS implementations for diverse sensor data type.

Paper Structure

This paper contains 10 sections, 3 equations, 6 figures, 3 tables.

Table of Contents

  1. Introduction
  2. Related Work
  3. Methodology
  4. Parameter Space
  5. Measurement Metrics
  6. Experiment Setup
  7. Evaluation
  8. Future Work
  9. Conclusion
  10. Online Resources

Figures (6)

  • Figure 1: Round Trip Time.
  • Figure 2: Experiment scenarios.
  • Figure 3: For the Different Domain or $DD$ wireless connectivity, all vendor-specific DDS implementations have sudden spikes in latency when file size increases than 145KB, but for wired connection, it shows consistent latency for Eclipse Cyclone DDS.
  • Figure 4: Eclipse Cyclone DDS same domain vs. different domain for binary data wireless connectivity Pi3 Pi4 node.
  • Figure 5: eProsima DDS same domain vs. different domain for binary data
  • ...and 1 more figures