ROS 2 DDS Middleware Selection for Real-Time Systems

Choosing a DDS implementation for a ROS 2 system is a question of matching latency determinism and quality-of-service enforcement to the failure mode your application cannot tolerate, not a matter of picking the fastest option off a spec sheet, because the middleware owns discovery, transport, scheduling interaction, and QoS enforcement from end to end. Get that mapping wrong, and no amount of tuning afterward fixes it.

DDS middleware selection as a QoS and latency-determinism problem, not a feature-checklist decision

Most engineering teams treat the choice of RMW implementation as a configuration detail, something you set once with an environment variable, and then move past it. ROS 2 even encourages that instinct: switching implementations takes nothing more than setting RMW_IMPLEMENTATION, and the API surface above it stays identical regardless of which DDS vendor sits underneath, a deceptive ease. It suggests the implementations are interchangeable parts, when in practice they differ sharply in how they honor, bend, or quietly break quality-of-service policies once a system is under real load. A deadline policy can hold steady on an idle test bench, but it can slip the moment the network carries ten more topics or a wireless link starts dropping packets, and the implementation you picked shapes whether that slip passes unnoticed or breaks the system.

If you separate real-time systems by failure mode rather than by speed, the stakes become clear. If a hard real-time system misses a deadline, that counts as a system failure. There is no partial credit. A soft real-time system tries to hit its deadlines, but it tolerates the occasional miss without the system falling over. A firm real-time system sits in between: it discards the late computation outright, accepting degraded performance over acting on stale data. These are not marketing tiers. They describe fundamentally different contracts between the application and the middleware, and each one calls for its own QoS and transport posture underneath.

That distinction is why the selection process has to run backward from how most teams approach it. The instinct is to survey available implementations and ask which one looks best on paper. You need to start from the failure mode and the latency budget the application needs. From there, you work out which QoS policies enforce that budget, and only then ask which RMW implementation delivers those policies reliably under the conditions the robot will actually operate in. Everything that follows in this piece builds on that order of operations.

RMW Abstraction and DDS QoS: Translating Real-Time Requirements into Wire-Level Behavior

The RMW layer does far more than translate function calls between ROS 2 and a DDS vendor's library. It is the mechanism through which quality-of-service contracts get defined, negotiated between publisher and subscriber, and enforced once data starts moving across the wire, which makes it the architectural center of gravity for any real-time ROS 2 system. A message published from application code travels through rclcpp or rclpy, down through rcl, through the rmw interface, into whichever DDS vendor implementation has been selected, and out onto the network. Each layer in that chain has a narrow and distinct job, and because of the rmw interface, you can run a single ROS 2 codebase on top of several different DDS vendor plugins without changing a line of application logic.

The quality-of-service policies that live at this layer are what actually decide whether a real-time requirement survives contact with the network. Reliability is the first axis: choosing RELIABLE buys guaranteed delivery through retransmission, but that retransmission adds overhead and jitter, while BEST_EFFORT drops the delivery guarantee in exchange for lower and more predictable latency. Durability works similarly. VOLATILE discards old samples once they are delivered, but TRANSIENT_LOCAL holds onto history so a late-joining subscriber can catch up, and that buffering competes with time-critical traffic for resources. Deadline is the policy most directly tied to hard real-time enforcement: publisher and subscriber each declare the maximum acceptable period between messages, and a violation triggers a callback, which is the primary mechanism a hard real-time loop has for catching a missed update before it causes downstream damage. Whether liveliness is automatic or manual with a configured lease duration, it governs how fast the system notices that a remote participant has gone silent. History and resource limits, typically expressed as KEEP_LAST with a bounded depth, cap how much data a callback queue can hold, and that caps the worst-case dispatch latency a subscriber will see.

These policies only make sense against a concrete scenario, and the ROS 2 real-time proposal frames two that sit at opposite ends of the spectrum. One is an STM32 embedded board running with no operating system at all, cycling at 1 kHz with a tight jitter tolerance, which is as close to textbook hard real-time as embedded robotics gets. The other is an x86 machine running the RT_PREEMPT kernel patch, and on it, sensor data gets processed in soft or firm real-time while ordinary, non-real-time processes run alongside it on the same machine. These two systems need completely different QoS profiles and transport modes, so no single default configuration can serve both well.

Discovery adds its own layer of complexity to this picture. DDS discovery, through the Simple Discovery Protocol, works peer to peer with no central broker coordinating the graph, so it removes the single point of failure that ROS 1's master node represented. But discovery traffic is itself a source of nondeterminism, and in a graph with many robots and many nodes, that traffic has to be bounded deliberately or it becomes a latency problem in its own right. Payload size compounds the issue: ROS 2 messages are, by default, serialized into DDS's CDR wire format before they go anywhere, and that conversion cost scales with the size of the data being sent, which makes payload size a first-order variable in any latency budget, not an afterthought to tune later. Reliability, durability, deadline, liveliness, history, discovery behavior, and serialization cost together form the checklist against which every implementation discussed later in this piece has to be measured, and the three structural dimensions of Time, Space, and State give that checklist its organizing logic.

What the three structural dimensions (Time, Space, and State) reveal about the limits every DDS implementation must navigate

Research published under the title "The Three Dimensions of ROS 2 Middleware" (arXiv:2607.01304, submitted July 2026) gives this problem a formal structure by naming three requirements that every distributed robotic system places on its middleware: Time, Space, and State. The paper's central claim is that no single RMW implementation can optimize all three at once. The trade-offs are built into the architecture of how discovery, transport, and state management work, not something a configuration flag can undo.

Time refers to temporal predictability: the requirement that a control loop receives its data within a bounded window no matter what else the system is doing at that moment. This is the dimension most directly threatened by shared dispatch queues, lock contention between threads, and any retransmission path triggered by a reliability policy.

Space refers to spatial abstraction, the ability to run the same communication graph, unmodified, across different physical topologies: a single process, a LAN, a WAN, a wireless mesh. The convenience here carries a cost. The more a middleware hides the underlying topology from the application, the harder it becomes to reason about worst-case latency on any one specific path through the network.

State refers to contextual continuity: keeping shared state consistent, through mechanisms like TRANSIENT_LOCAL history and liveliness tracking, even as nodes join, leave, and drop in and out of connectivity. Buffering and replication are what make State continuity possible, but they add computational and network overhead that competes directly with Time.

The paper's deeper point is about how these three interact under stress. Under constrained wireless conditions, the abstraction that makes Space convenient can hide network variability that would otherwise warn you your temporal guarantees are eroding. The same buffering and replication that keep State continuous also eat into the cycles and bandwidth that time-critical traffic needs. These are not edge cases: they describe the practical ceiling that every contemporary robot middleware runs into. The implication for anyone choosing an implementation is to stop asking which one is fastest in the abstract and start asking which dimension the application needs most, and which trade-off it can live with. A surgical robot needs Time above everything else. A warehouse fleet of many robots coordinating over a shared facility needs Space and State. A safety-certified autonomous vehicle needs all three at once, and it needs formal guarantees behind each one.

How Fast DDS, Cyclone DDS, RTI Connext, and Zenoh each make distinct trade-offs across the three dimensions

Four implementations dominate the ROS 2 real-time conversation, and each one sits at a different point in the Time, Space, and State trade-off space described above. Matching one to a project means knowing which dimension it sacrifices and under what conditions that sacrifice starts to bite.

Fast DDS

Fast DDS ships as the default RMW in ROS 2 and is licensed under Apache 2.0. It comes in two flavors: rmw_fastrtps_cpp, which generates type mappings at build time and carries lower runtime overhead, and rmw_fastrtps_dynamic_cpp, which uses runtime introspection instead, trading some performance for more flexibility. Its strongest position is Time on a local area network: it handles small, high-frequency messages reliably in a controlled network environment, which is exactly the profile of most single-robot control loops. Its weak point is Space combined with large payloads. Under mesh network conditions at scale, Fast DDS underperforms other RMWs once messages grow larger. That makes it a solid fit for soft real-time systems running on a single LAN, especially for teams that want the broadest community support and the path of least resistance through default configuration, but it stops being the right choice the moment the system's topology spans a wireless mesh or a WAN.

Eclipse Cyclone DDS

Cyclone DDS combines network communication with intra-platform transport, using iceoryx internally to handle shared memory, and it is the RMW the Nav2 navigation stack recommends by default. That iceoryx integration is what gives Cyclone DDS its strongest position: Time for large intra-host payloads. Rather than writing a large message to N independent socket transmissions, it writes once to shared memory, which gives near-constant latency regardless of how large the payload gets, a genuine zero-copy pattern. Research on cooperative driving scenarios found a Space advantage here too: Cyclone DDS performed better than competing implementations when transferring large files among wirelessly connected devices across different domains within the same session. That combination makes it well suited to firm or soft real-time systems carrying large sensor payloads, point clouds and camera images especially, on a single host or across a LAN, and it explains why navigation and perception stacks, where payload size is the dominant latency driver, gravitate toward it.

RTI Connext DDS

RTI Connext occupies a different niche entirely: formal, certified hard real-time guarantees. Connext Drive is described as the first DDS-based communications framework to meet ISO 26262 ASIL D, and it carries a platform-independent TÜV SÜD certification, so a change to the vehicle's operating system or network interfaces does not force a full recertification cycle. That certification profile is what makes Connext appropriate for hard real-time systems that need to pass a formal safety case: automotive, medical devices, aerospace. The cost is real too: commercial licensing and the configuration expertise Connext demands are not trivial barriers, and for research labs or early prototyping, that overhead usually outweighs the benefit of certification nobody is asking for yet.

Zenoh

Zenoh started at ADLINK Technology and is now stewarded by ZettaScale Technology. The rmw_zenoh implementation is maintained as an official ROS 2 RMW, and it takes a more radical architectural approach than the other three: it replaces the RTPS wire protocol entirely while keeping the same ROS 2 publish-subscribe, service, and action APIs application code already relies on. Its discovery model departs from DDS as well. Rather than UDP multicast, rmw_zenoh relies on a lightweight router for discovery by default, with TCP as its default data transport (though Zenoh also supports UDP, QUIC, and other transports), and that combination lets it work natively across NAT boundaries, firewalls, and 5G links, conditions where DDS's UDP multicast discovery simply fails to function. That is what gives Zenoh its strongest position: Space, the dimension where DDS implementations structurally struggle once a deployment moves past a LAN. In testing under mesh network conditions, Zenoh achieved the highest message delivery success rate among the implementations evaluated. PX4, the drone autopilot project, has adopted it directly: PX4 supports Zenoh as an alternative to DDS for bridging its internal uORB topics to ROS 2, giving a fast, lightweight connection between the flight controller and a companion computer. The trade-off sits in raw LAN latency: rmw_zenoh's default use of TCP gives up some of the low-latency advantage UDP offers on a controlled local network, even though Zenoh itself supports UDP and other low-latency transports elsewhere in its design. Zenoh fits multi-robot fleets spread across a WAN, a wireless mesh, 5G, or behind NAT, and edge-to-cloud deployments, where its simple discovery model and its flexibility across networks are worth more than the last millisecond of LAN latency.

None of these four is a universal answer. Each earns its place by matching a specific failure mode and network topology, and the right choice depends entirely on which of Time, Space, or State the application can least afford to compromise.

Shared-memory transport and zero-copy for intra-host real-time paths

Many real-time ROS 2 systems never send a message off the host machine. Sensor fusion pipelines, control loops, and embedded systems often pass messages between nodes running on the same machine, and for that case, shared-memory zero-copy transport changes the entire latency model by making the size of the message irrelevant to how long delivery takes.

The standard DDS path was never built with that case as its primary target. A message gets serialized, written into a socket buffer, transmitted, and deserialized again on the receiving end, and every one of those steps adds latency that scales with the payload's size. That is the specific mechanism behind a pattern anyone benchmarking DDS traffic notices quickly: processing overhead grows sharply as data gets larger. Shared-memory zero-copy transport, following the iceoryx pattern that Cyclone DDS uses internally, sidesteps that chain. The publisher writes the message once into a shared memory region, and the subscriber reads directly from that same region, so no copy ever happens in between. Latency under this model is bounded by memory access time, not by payload size, so a large point cloud and a small status message arrive with comparable, near-constant latency.

Cyclone DDS delivers this transparently through the RMW abstraction, but genuine zero-copy behavior is not automatic. It requires application code to use the LoanedMessage API together with fixed-size message types, and it requires explicit configuration to turn shared memory on. The transport path gets picked based on whether the publisher and subscriber sit on the same host, so if a subscriber moves to a different machine, the same application can fall back to standard network transport. For any system where the real bottleneck sits inside the host rather than across the network, whether a middleware merely supports shared memory or is actually configured to use it is what decides whether the real-time budget holds.