Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

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

T0 review · 3 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that current ROS2 DDS vendor implementations, used for different-domain communication over wireless links, cannot meet hard real-time cooperative driving requirements, and no vendor wins in all cases.

desk verdict A useful but statistically thin benchmark of cross-domain ROS2/DDS bridging; the latency metric in Eq. (3) is not validated, so the hard-real-time conclusion is overstated. read the letter →

arxiv 2412.07485 v1 pith:GTCVKWOM submitted 2024-12-10 cs.RO

Sumit Paul , Danh Lephuoc , Manfred Hauswirth This is my paper · ORCID
classification cs.RO
keywords ROS2DDSvendor-specificimplementationsdomainparticipantsame-domaincommunicationdifferent-domaincooperativedrivinglatency
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper asks whether the middleware that connects ROS2 nodes can carry cooperative-driving data when vehicles, sensors, and robots cannot all share one DDS domain. It measures round-trip latency across same-domain and different-domain communication for three vendor DDS implementations, several data types and sizes, wired and wireless links, and five physical devices. The central finding is that same-domain communication usually outperforms different-domain communication, that no single vendor dominates every case, and that eProsima Fast-DDS is consistently the worst for cross-domain transfers. From these results the paper concludes that current vendor DDS implementations are not capable enough for hard real-time requirements over wireless cross-domain links, which matters because cooperative perception needs reliable, low-latency exchange of sensor data.

What carries the argument

The argument is carried by a ping-pong round-trip test with a relay node. A publisher in one DDS domain (e.g., domain 5) timestamps a message and sends it; a subscriber in another domain (e.g., domain 10) receives it and relays it back on a second topic; the publisher timestamps the return. One-way latency is computed as (RTT - intermediate-process time)/2, where the intermediate time is measured locally on the relay node as the gap between receiving and relaying. Every cross-domain path therefore contains a vendor-specific bridging service (Zenoh plugin, Integration Service, or Routing Service), and the latency behavior the paper reports is the behavior of those bridges plus the transport. The DDS domain is the scoping mechanism that forces the relay; the bridge is the object whose performance is under test.

What would settle it

Re-run the cross-domain ping-pong experiment on a wireless link with synchronized clocks on both nodes and measure one-way latency directly in each direction; if the directly measured values diverge from the paper's (RTT - intermediate-process time)/2 estimate, the absolute latency conclusions are biased. A second check is to repeat the 502KB file-size sweep with finer size steps to confirm whether the spike is a real fragmentation threshold.

Watch

Extended reading notes

Core claim

The central discovery is an empirical characterization of cross-domain latency in ROS2. Because DDS limits participant counts per domain, a vehicle or platoon with many nodes must bridge across domains via vendor-specific services: Zenoh for Eclipse Cyclone DDS, Integration Service for eProsima Fast-DDS, and Routing Service for RTI Connext DDS. Across a large parameter sweep, same-domain communication generally beat different-domain communication; eProsima Fast-DDS was worst at cross-domain communication for all data types, connectivities, and devices; Cyclone DDS was best for large files over wireless different domains; and RTI Connext showed the smallest gap between same-domain and different-domain performance. The paper also observed a systematic latency spike for 502KB binary files across vendors. The conclusion is that different-domain DDS over wireless is not hard-real-time capable at this moment, and the likely culprit is the bridging services.

Load-bearing premise

The load-bearing premise is that one-way latency equals half of the round-trip time minus half of the relay node's measured handling time; if the outward and return wireless paths take different amounts of time, which is common on wireless links, the reported latencies are systematically biased.

Editorial extensions

If this is right

  • Developers should keep ROS2 nodes in the same DDS domain whenever possible, since same-domain communication usually had lower latency.
  • eProsima Fast-DDS should be avoided for different-domain communication; it showed the worst performance in every tested wired and wireless scenario.
  • RTI Connext DDS is the safer default when an application needs both same-domain and cross-domain links, because it showed the smallest latency gap between the two.
  • For large binary files sent across wirelessly connected different domains, Eclipse Cyclone DDS provided better latency than the alternatives.
  • Binary frames around 502KB should be investigated or avoided: they triggered a latency spike across DDS implementations, sometimes exceeding the latency of 1MB frames.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's latency formula assumes symmetric one-way paths; on wireless links this is often false, so the absolute latency values may be biased even if the relative vendor rankings hold.
  • If hard real-time cannot be met across DDS domains, the practical route for cooperative driving may be to keep safety-critical control loops inside one domain or on a dedicated link, and use cross-domain DDS only for non-critical perception data.
  • The 502KB spike hints at a fragmentation or buffer threshold near that size; probing with sizes between 400KB and 600KB could turn the anomaly into a diagnosable implementation detail.
  • The evaluation is static in the sense of fixed QoS; combining the same setup with deadline-based QoS or 5G transport could test whether cross-domain DDS at least meets soft real-time constraints.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper evaluates three vendor-specific DDS implementations (Eclipse Cyclone DDS, eProsima Fast DDS, RTI Connext DDS) with their bridging services in ROS2 Humble for same-domain and different-domain communication over wired and wireless links. It reports latency measurements for binary, string, and IMU data types on Raspberry Pi 3/4, Jetson Nano, and laptops, and concludes that no single DDS vendor dominates, that eProsima performs worst for different-domain communication, and that ROS2 vendor-specific DDS implementations are not capable of fulfilling hard real-time requirements for cooperative driving over wireless.

Significance. If validated, the comparison of same-domain versus different-domain bridging across vendors would be a useful practical reference for ROS2 developers in cooperative driving and multi-robot systems. The paper has concrete strengths: it uses heterogeneous physical hardware, multiple data types, a real camera stream test, and it makes the experiment code available online. However, the central latency metric in Eq. (3) rests on untested symmetry assumptions, and the reported comparisons lack any statistical confidence information, so the quantitative vendor ranking and the hard-real-time conclusion are not yet established.

major comments (3)
  1. [§3.2, Eq. (3)] The latency estimator in Eq. (3) is not a valid one-way latency. The RTT includes the initiating publisher's send-side and receive-side processing, which are not captured by the relay's T4−T3 interval, and the halving assumes the two legs are symmetric in both network conditions and endpoint processing. Since the publisher and subscriber are different devices (Table 2), their per-message processing times are not equal; on Wi-Fi the forward and return paths can also differ due to contention, retries, and rate adaptation. All §4 comparisons and the §6 hard-real-time conclusion are built on this quantity. The paper should either measure one-way latency with synchronized clocks (e.g., PTP/chrony), or report RTT and intermediate-processing time separately without dividing by two, or provide a quantitative bound showing that the bias is negligible for the conclusions drawn.
  2. [§4] No trial counts, error bars, standard deviations, or raw latency distributions are reported. The text relies on visual descriptions of plots, including the unexpected result that 502 KB files often yield higher latency than 1 MB files (figures 3b and 3c), and the cross-vendor rankings. Without measures of dispersion or at least a stated number of repetitions per configuration, these differences cannot be distinguished from measurement noise. This undermines the central vendor-level claims, including the recommendations to avoid eProsima for different-domain communication and to prefer RTI Connext for mixed-domain workloads. Please report the number of repetitions, per-configuration statistics, and, where possible, confidence intervals.
  3. [§6] The claim that 'ROS2's vendor-specific DDS implementations are not capable enough to fulfill the hard real-time requirements' is not tied to any quantified deadline. Hard real-time is an application-specific property; the paper should state the assumed end-to-end latency bound (e.g., a braking or cooperative-perception deadline) and compare the measured values against that bound. Without a stated threshold, the central conclusion is not falsifiable and cannot be assessed. This is load-bearing because it motivates the entire framing of the paper as a cooperative-driving evaluation.
minor comments (5)
  1. [Contribution paragraph] The text says 'This paper presents a noble performance comparison' but should read 'novel performance comparison'.
  2. [§3.2] The word 'intermediate-processtime' appears without a space; it should be 'intermediate-process time' for consistency with the surrounding text.
  3. [§3.3 Software] The statement that Docker on the host network produces 'negligible latency overhead' is supported only by a citation to a general container/VM comparison; the manuscript should verify this for the specific DDS/UDP multicast workloads used, since even a small constant bias can affect absolute latency comparisons with real-time thresholds.
  4. [§4 figure captions] The figure captions in §4 do not fully specify axes, units, or the meaning of the plotted curves; please ensure every panel has labeled axes with latency units and a legend, and that the captions explicitly state which domain and connectivity scenario each panel represents.
  5. [References] Reference [24] is a shortened URL that may become unstable; use a stable identifier or direct URL, and check formatting consistency across the reference list.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the paper's claims rest on direct experimental measurements, and the only self-referential element is a link to the authors' own code for reproducibility.

full rationale

The paper is an experimental performance evaluation, not a derivation from first principles. The central claim—that vendor-specific ROS2-DDS implementations over wireless different-domain communication cannot currently meet hard real-time requirements—is supported by direct latency measurements across physical devices, data types, frequencies, and connectivity modes. Equation (3) defines one-way latency as (RTT minus measured relay-processing time) divided by two. This is a measurement definition rather than a prediction derived from fitted parameters, and it is not circular: the quantity is computed from raw timestamps, and the conclusion is an empirical observation about the resulting values. The only self-referential item is the GitHub link in Appendix A, which provides the experimental source code; it is not used to justify any load-bearing assumption, uniqueness claim, or fitted result. The paper does not invoke any prior same-author theorem, does not smuggle in an ansatz via citation, and does not rename a known result. Any concern that Equation (3) assumes path symmetry or omits publisher-side overhead would be a correctness or validity critique of the measurement methodology, not a circularity critique. Under the stated rules, such methodological concerns do not constitute circularity, so the appropriate score is 0.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The paper imposes no fitted parameters and no invented entities. Its results rest on the measurement definition and several implicit modeling choices about symmetric latency, Docker overhead, relay processing additivity, and representativeness of Python nodes; these are listed as axioms.

assumptions (5)
  • domain assumption One-way latency equals half the network round-trip time (latency = (RTT - intermediate)/2).
    Equation (3) in Section 3.2 assumes symmetric outbound and return paths; wireless links can be asymmetric.
  • domain assumption Docker containers add negligible latency overhead.
    Section 3.3 Software cites reference [27] for this claim, but does not verify it in this setup.
  • domain assumption The relay node's intermediate processing time (T4-T3) can be subtracted linearly from round-trip time to isolate network latency.
    Section 3.2, Equations (2)-(3); assumes processing time is independent of message direction and does not interact with network delays.
  • domain assumption ROS2 behaves similarly for the various DDS implementations apart from the middleware itself.
    Section 3.2 Measurement Metrics states 'we assume the ROS2 system behaves similarly for the various DDS implementations'.
  • domain assumption rclpy (Python client library) is a representative way to measure ROS2 communication latency.
    Section 3.3 Software; Python adds per-message overhead that may dominate the middleware differences.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Performance Evaluation of ROS2-DDS middleware implementations facilitating Cooperative Driving in Autonomous Vehicle." pith.science (2026). https://pith.science/paper/GTCVKWOM

@misc{pith2026241207485,
  author       = {Pith},
  title        = {Pith review of: Performance Evaluation of ROS2-DDS middleware implementations facilitating Cooperative Driving in Autonomous Vehicle},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GTCVKWOM}},
  note         = {Machine review of arXiv:2412.07485}
}
read the original 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.

Figures

Figures reproduced from arXiv: 2412.07485 by the authors.

Figure 1
Figure 1. Round Trip Time. For the binary file type, we have used a custom message type BinaryFile which includes the sensor_msgs/Image type to hold the binary image and a float64 data type to hold the publish time. While publishing a frame, a timestamp (T1) is taken and included in the message. The publisher residing in domain 5 creates the topic binary_image to publish the binary image file and also creates a subscriber of … view at source ↗
Figure 2
Figure 2. Experiment scenarios [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. For the Different Domain or 𝐷𝐷 wireless connectivity, all vendor-specific DDS implementa￾tions have sudden spikes in latency when file size increases than 145KB, but for wired connection, it shows consistent latency for Eclipse Cyclone DDS. Same Domain vs Different Domain Communication Binary Data In our experiments with ROS2 nodes using different DDS implementations, we observed various interesting patterns in late… view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Eclipse Cyclone DDS same domain vs. different domain for binary data wireless connectivity Pi3 Pi4 node. Interestingly, when we switched to wired connections, the latency characteristics changed significantly for both Pi3 and Pi4, with same domain communication showing…
Figure 5
Figure 5. Figure 5: eProsima DDS same domain vs. different domain for binary data RTI Connext DDS showed more varied behavior. For wirelessly connected Pi3 and Pi4 nodes at lower frequencies, we saw similar latency for both domains up to 87KB file size. However, for Pi3, different domain …
Figure 6
Figure 6. Figure 6: RTI Connext DDS same domain vs. different domain wireless connectivity (a)Pi3 (b)Laptop node. domain communication showed lower latency. Interestingly, wired laptop nodes displayed dif￾ferent behavior compared to their wireless counterparts, with different domain commu…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Probabilistic Latency Analysis of the Data Distribution Service in ROS 2

    cs.NI 2025-08 unverdicted novelty 6.0 of 10

    The paper claims a discrete-state probabilistic model for ROS 2 DDS retransmission latency, but the supplied body is the wrong manuscript, leaving the claim unverifiable.

Reference graph

Works this paper leans on

28 extracted references · 23 canonical work pages · cited by 1 Pith paper

  1. [1]

    M. Reke, D. Peter, J. Schulte-Tigges, S. Schiffer, A. Ferrein, T. Walter, D. Matheis, A self- driving car architecture in ros2, in: 2020 International SAUPEC/RobMech/PRASA Confer- ence, 2020, pp. 1–6. doi:10.1109/SAUPEC/RobMech/PRASA48453.2020.9041020

    work page arXiv 2020

  2. [2]

    Kim, G.-P

    S.-W. Kim, G.-P. Gwon, S.-T. Choi, S.-N. Kang, M.-O. Shin, I.-S. Yoo, E.-D. Lee, E. Frazzoli, S.- W. Seo, Multiple vehicle driving control for traffic flow efficiency, in: 2012 IEEE Intelligent Vehicles Symposium, 2012, pp. 462–468. doi:10.1109/IVS.2012.6232187

    work page arXiv 2012

  3. [3]

    van Arem, C

    B. van Arem, C. J. G. van Driel, R. Visser, The impact of cooperative adaptive cruise control on traffic-flow characteristics, IEEE Transactions on Intelligent Transportation Systems 7 (2006) 429–436. doi:10.1109/TITS.2006.884615

    work page arXiv 2006

  4. [4]

    O. S. R. F. (OSRF), ROS2, 2022. URL: https://github.com/ros2

    work page 2022

  5. [5]

    O. S. R. F. (OSRF), ROS1, 2007. URL: https://github.com/ros

    work page 2007

  6. [6]

    O. M. G. (OMG), DATA DISTRIBUTION SERVICE, 2015. URL: https://www.omg.org/spec/ DDS/1.4/PDF

    work page 2015

  7. [7]

    S.-W. Kim, B. Qin, Z. J. Chong, X. Shen, W. Liu, M. H. Ang, E. Frazzoli, D. Rus, Multivehicle cooperative driving using cooperative perception: Design and experimental validation, IEEE Transactions on Intelligent Transportation Systems 16 (2015) 663–680. doi:10.1109/ TITS.2014.2337316

    arXiv 2015

  8. [8]

    URL: https:// community.rti.com/kb/what-maximum-number-participants-domain

    RTI, What is the maximum number of participants per domain?, 2020. URL: https:// community.rti.com/kb/what-maximum-number-participants-domain

    work page 2020

Show all 28 references
  1. [9]

    Torenbeek, Maximum number of DDS Topics that may be created in a sin- gle DDS Domain, 2022

    R. Torenbeek, Maximum number of DDS Topics that may be created in a sin- gle DDS Domain, 2022. URL: https://stackoverflow.com/questions/15005702/ maximum-number-of-dds-topics-that-may-be-created-in-a-single-dds-domain

    2022

  2. [10]

    URL: https://zenoh.io/blog/2021-04-28-ros2-integration

    Eclipse, Zenoh-dds, 2021. URL: https://zenoh.io/blog/2021-04-28-ros2-integration

    2021

  3. [11]

    S.-W. Kim, Z. J. Chong, B. Qin, X. Shen, Z. Cheng, W. Liu, M. H. Ang, Cooperative perception for autonomous vehicle control on the road: Motivation and experimental results, 2013 IEEE/RSJ International Conference on Intelligent Robots and Systems (2013) 5059–5066

    2013

  4. [12]

    Maruyama, S

    Y. Maruyama, S. Kato, T. Azumi, Exploring the performance of ros2, in: Proceedings of the 13th International Conference on Embedded Software, EMSOFT ’16, Association for Computing Machinery, New York, NY, USA, 2016. URL: https://doi.org/10.1145/2968478. 2968502. doi:10.1145/29...

    2016

  5. [13]

    Kronauer, J

    T. Kronauer, J. Pohlmann, M. Matthe, T. Smejkal, G. Fettweis, Latency Analysis of ROS2 Multi-Node Systems, cs.RO 2101.02074, arXiv, 2021

    2021 arXiv

  6. [14]

    Profanter, A

    S. Profanter, A. Tekat, K. Dorofeev, M. Rickert, A. Knoll, Opc ua versus ros, dds, and mqtt: Performance evaluation of industry 4.0 protocols, in: 2019 IEEE International Conference on Industrial Technology (ICIT), 2019, pp. 955–962. doi:10.1109/ICIT.2019.8755050

    2019

  7. [15]

    Fernandez, B

    J. Fernandez, B. Allen, P. Thulasiraman, B. Bingham, Performance study of the robot oper- ating system 2 with qos and cyber security settings, in: 2020 IEEE International Systems Conference (SysCon), 2020, pp. 1–6. doi:10.1109/SysCon47679.2020.9275872

    2020

  8. [16]

    J. Kim, J. M. Smereka, C. Cheung, S. Nepal, M. Grobler, Security and performance consid- erations in ros 2: A balancing act, 2018. arXiv:1809.09566

    2018 arXiv

  9. [17]

    Y.-P. Wang, W. Tan, X.-Q. Hu, D. Manocha, S.-M. Hu, Tzc: Efficient inter-process commu- nication for robotics middleware with partial serialization, 2018

    2018

  10. [18]

    Morita, K

    R. Morita, K. Matsubara, Dynamic binding a proper dds implementation for optimizing inter-node communication in ros2, in: 2018 IEEE 24th International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA), 2018, pp. 246–

    2018

  11. [19]

    O. S. R. F. (OSRF), About Quality of Service settings, 2022. URL: https://docs.ros.org/en/ rolling/Concepts/About-Quality-of-Service-Settings.html

    2022

  12. [20]

    URL: https://developer.nvidia.com/embedded/ jetson-nano-developer-kit

    Nvidia, Jetson Nano Developer Kit, 2020. URL: https://developer.nvidia.com/embedded/ jetson-nano-developer-kit

    2020

  13. [21]

    URL: https://www.intelrealsense.com/ depth-camera-d435/

    Intel, Depth Camera D435, 2022. URL: https://www.intelrealsense.com/ depth-camera-d435/

    2022

  14. [22]

    O. S. R. Foundation, ROS Distributions, 2023. URL: https://docs.ros.org/en/foxy/Releases. html

    2023

  15. [23]

    Foundation, Ubuntu release, 2020

    L. Foundation, Ubuntu release, 2020. URL: https://releases.ubuntu.com/focal/

    2020

  16. [24]

    Foundation, Ubuntu release, 2024

    L. Foundation, Ubuntu release, 2024. URL: https://tinyurl.com/27b35v6r

    2024

  17. [25]

    URL: https://jetbot.org/master/software_ setup/sd_card.html

    Nvidia, Software setup (sd card image), 2023. URL: https://jetbot.org/master/software_ setup/sd_card.html

    2023

  18. [26]

    Robotics, Ros 2 humble hawksbill release!), 2023

    O. Robotics, Ros 2 humble hawksbill release!), 2023. URL: https://www.openrobotics.org/ blog/2022/5/24/ros-2-humble-hawksbill-release

    2023

  19. [27]

    Felter, A

    W. Felter, A. Ferreira, R. Rajamony, J. Rubio, An updated performance comparison of virtual machines and linux containers, in: 2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), 2015, pp. 171–172. doi: 10.1109/ISPASS. 2015.7095802. A. O...

    2015

  20. [247]

    doi:10.1109/RTCSA.2018.00043

    2018

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.