Choosing a ROS 2 Middleware: Fast DDS, Cyclone DDS and Zenoh Compared

TL;DR: ROS 2 does not ship its own network transport. It delegates that job to a pluggable middleware layer called RMW (ROS Middleware Interface). The three implementations most teams encounter today are Fast DDS (eProsima), Cyclone DDS (Eclipse Foundation) and Zenoh (Eclipse Foundation, exposed through rmw_zenoh_cpp). Fast DDS is the default RMW in ROS 2 binary releases, while Zenoh was promoted to Tier 1 support in ROS 2 Kilted. Fast DDS offers the widest configuration surface. Cyclone DDS has a reputation for a simpler configuration model and lean behavior on well-behaved LANs. Zenoh is the newest option and was designed specifically to address the pain points DDS multicast discovery causes over Wi-Fi, LTE and across network boundaries. On a mobile robot like the Leo Rover, the practical difference usually shows up not in raw throughput but in how the stack behaves when the wireless link degrades or when you connect a second robot to the same subnet.

What Is an RMW, and Why Does ROS 2 Let You Swap It?

In ROS 1, the transport was fixed: a central roscore handled node registration and connection lookup, and nodes spoke TCPROS or UDPROS directly to each other. ROS 2 removed the central master and replaced it with an abstraction. Every ROS 2 node links against rcl, which calls into rmw, which in turn calls into a concrete RMW implementation loaded at runtime. That implementation handles discovery, serialization, transport, Quality of Service enforcement, and the actual bytes on the wire.

This indirection is the reason the ROS 2 middleware question exists at all. You can change the entire networking behavior of a robot without recompiling a single node, by setting one environment variable. The abstraction is not perfectly leak-free – QoS semantics, discovery timing and large-message handling differ between implementations – but the API surface your application code touches stays identical.

The original design assumption was DDS (Data Distribution Service), an OMG standard used in aerospace and industrial automation. DDS brought a mature QoS model, decentralized discovery and interoperability between vendors. It also brought assumptions that fit a switched industrial LAN far better than a rover on a 2.4 GHz link at the edge of an access point’s range. Zenoh entered the picture as a protocol that keeps the publish/subscribe model but drops the DDS wire protocol entirely.

How discovery actually works

Discovery is where most ROS 2 middleware problems originate, so it is worth being precise about it.

Classic DDS discovery (the Simple Discovery Protocol, SDP) works in two phases. First, participant discovery: each DDS participant periodically multicasts announcements on a well-known port derived from the ROS domain ID. Second, endpoint discovery: once two participants know about each other, they exchange information about publishers, subscribers, topics, types and QoS settings through DDS built-in discovery endpoints. Depending on the configuration, this traffic may use multicast, unicast, or both. The cost of endpoint discovery and matching can grow rapidly with the number of participants and endpoints in the domain, because participants commonly learn about endpoints they will never match.

On a single robot with a handful of nodes this is invisible. With a large node graph, several robots and a developer workstation all on the same domain, it becomes measurable traffic and measurable CPU. Both Fast DDS and Cyclone DDS offer mitigations: Fast DDS has a Discovery Server mode that can avoid multicast discovery through a central or redundant discovery service, and both support configuration that restricts which interfaces and peers participate.

Zenoh takes a different route. It uses a router-based or peer-to-peer scouting model where a Zenoh router can act as a rendezvous point, and resource declarations are matched by key expression rather than by exhaustive DDS endpoint exchange. In a typical rmw_zenoh_cpp deployment, nodes connect to a local or reachable Zenoh router. This makes crossing subnets or linking a robot to a cloud endpoint a configuration task, although NAT traversal still requires reachable routers and appropriate transport, firewall or port-forwarding configuration.

How Do Fast DDS, Cyclone DDS and Zenoh Compare Feature by Feature?

The table below summarizes the structural differences that matter when you are choosing a ROS 2 middleware for a field robot. It describes design characteristics and documented behavior, not benchmark results – published throughput and latency numbers vary so much with message size, QoS profile, kernel tuning and hardware that quoting a single figure would be misleading.

One note on defaults and support status. The default RMW has changed across ROS 2 releases, and Zenoh’s status has moved quickly between Iron, Jazzy, Kilted and Rolling. Treat the row above as a structural guide and confirm the exact default and the exact Tier level for your distribution in the official ROS 2 documentation before you commit a fleet to it. That is not a formality; a Tier 1 versus Tier 3 designation changes which CI jobs run against it and how quickly regressions get caught.

When Does the Choice of ROS 2 Middleware Actually Change Your Results?

For many desktop and simulation workflows, the choice of ROS 2 middleware is close to irrelevant. All three implementations will carry a 10 Hz odometry topic and a joint state stream without complaint. The differences surface in specific, recognizable situations.

These are the scenarios where swapping the RMW produces a visible change in behavior:

• Camera or LiDAR streams over Wi-Fi. A 1280×720 RGB stream at 30 fps is several hundred megabits per second uncompressed. UDP fragmentation plus packet loss on a wireless link produces a pathological pattern where most fragments arrive, one is lost, and the entire sample is discarded. All three middlewares can be affected by insufficient bandwidth or loss, but transport choice matters: Zenoh’s TCP-capable transport and Fast DDS’s configurable transport behavior give you levers that default settings do not.
• More than two or three robots on one network. Discovery traffic in a shared DDS domain can grow faster than linearly. If you see CPU spikes on robot startup that have nothing to do with your application nodes, discovery is the first suspect.
• Connecting a robot to a machine outside the local subnet. Multicast does not route. Without a VPN, multicast routing, a discovery service or explicit peer configuration, DDS discovery usually will not find the remote side. Zenoh’s router model supports this deployment pattern, provided the routers can reach one another.
• Intermittent links. Field robotics work on LTE or long-range Wi-Fi involves links that drop and return. How quickly discovery re-converges after a link flap differs between implementations and is worth testing against your actual radio hardware.
• Containerized deployments. Docker bridge networking can complicate DDS discovery, particularly across hosts, and multicast behavior depends on the bridge and network configuration. Teams often solve this with --network=host, which works but removes network isolation. A router-based architecture can simplify this setup when containers can reach the router.

If none of those apply to your project, the honest answer is that the default RMW for your distribution is a reasonable choice and your engineering time is better spent elsewhere.

How Do You Switch the RMW in a ROS 2 System?

Switching is deliberately simple. The RMW is selected at runtime through the RMW_IMPLEMENTATION environment variable, read when a node initializes.

Follow these steps to change the middleware on a Leo Rover or any ROS 2 host:

1. Install the RMW package. On a Debian-based system, that means sudo apt install ros-$ROS_DISTRO-rmw-cyclonedds-cpp, ros-$ROS_DISTRO-rmw-fastrtps-cpp or ros-$ROS_DISTRO-rmw-zenoh-cpp, depending on the target. Availability varies by distribution, so check the package index for your release.
2. Export the variable before launching anything. For example export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp. Put it in the shell profile, the systemd unit file or the container environment – wherever your nodes actually start.
3. Apply it consistently across every participant. Fast DDS and Cyclone DDS both speak RTPS and can interoperate in principle, but ROS 2 does not guarantee cross-vendor interoperability for every feature and configuration. Zenoh cannot interoperate directly with DDS implementations without a suitable bridge. Mixed RMWs in one system are usually a debugging trap rather than a feature.
4. Configure a Zenoh router or peer deployment if you selected Zenoh. A common local-router setup starts rmw_zenohd with ros2 run rmw_zenoh_cpp rmw_zenohd before starting nodes. You can instead configure nodes to use a reachable remote router or an appropriate peer-to-peer topology.
5. Verify with ros2 doctor --report. The report prints the active middleware. Confirm it matches on every machine before you start interpreting test results.
6. Re-test your QoS-sensitive topics. Reliable versus best-effort, history depth, and transient-local durability are implemented by each RMW separately. A latching topic that worked under one implementation can behave differently under another.

Configuration beyond the variable goes into implementation-specific files: FASTRTPS_DEFAULT_PROFILES_FILE for Fast DDS XML profiles, CYCLONEDDS_URI for Cyclone DDS, and Zenoh session or router configuration paths for Zenoh. Keep those files in version control alongside your robot’s launch configuration. A middleware tuned by hand on one machine and not documented is a reproducibility problem waiting to happen, particularly in research deployments where a result needs to hold up months later.

What Should You Measure Before Committing?

Published benchmarks for ROS 2 middleware are useful for understanding shapes of behavior, not for predicting your numbers. Message size, QoS profile, CPU architecture, kernel version, network stack tuning and even the specific Wi-Fi chipset all move the results. The practical approach is to measure on your own hardware with your own topic graph.

A minimal evaluation on a rover platform covers these measurements:

• Startup-to-first-message latency for your full node graph, measured from launch to the first message on a known topic. This exposes discovery cost directly.
• End-to-end latency on your largest topic under realistic radio conditions, not on a bench with the access point one meter away.
• Message drop rate on best-effort sensor topics while the robot moves to the edge of coverage and back.
• Recovery time after a link drop, measured by physically disabling and re-enabling the wireless interface.
• Idle CPU on the robot’s compute module with the full graph running and no commanded motion. Discovery chatter can show up here.

Run each configuration several times. Single-run comparisons between middlewares are noise. If you cannot reproduce a difference across repeated runs, you do not have a difference.

How Does This Play Out on a Field Robot?

On a mobile UGV, the ROS 2 middleware question is really a question about the wireless link. A rover carrying a camera, a LiDAR and an IMU, teleoperated or supervised from a laptop, is a case where every structural weakness of multicast discovery over Wi-Fi has a chance to appear. A Leo Rover using its ROS 2 distribution’s default middleware can work out of the box in the common case, which is a single robot and a single operator on the same network. That covers most classroom, prototyping and single-unit research use.

Where teams start reconfiguring is when the deployment shape changes: a second or third rover on the same subnet, an operator station outside the local network, or a payload that pushes high-rate sensor data over the air. At that point the comparison in this article becomes a decision rather than background knowledge, and it is worth running the measurements above before standardizing a fleet on one implementation.

One architectural pattern worth knowing regardless of RMW choice: keep high-rate sensor processing on the robot and publish only the derived, low-rate results over the wireless link. A 10 Hz pose estimate crosses most adequately provisioned radio links reliably. A raw point cloud may not, particularly over a congested or lossy wireless connection. Middleware selection optimizes the margins of a system; topic architecture determines whether the system works at all.

Frequently Asked Questions

Which RMW is the default in ROS 2?

The default has changed across releases. Fast DDS is the default in ROS 2 binary releases, including Jazzy and Kilted, while Zenoh was promoted to Tier 1 support in ROS 2 Kilted. Check the release notes and support documentation for your specific distribution in the official ROS 2 documentation rather than relying on any blog post, including this one.

Can Fast DDS and Cyclone DDS nodes talk to each other?

Both implement the RTPS wire protocol, so basic interoperability is possible in principle. In practice ROS 2 does not guarantee interoperability across all vendors, type-support combinations, QoS settings and features. Use one RMW consistently across all participants in a system.

Is Zenoh a DDS implementation?

No. Zenoh is a separate protocol with its own wire format, designed around key expressions and a routing model rather than the DDS participant and endpoint model. rmw_zenoh_cpp maps the ROS middleware interface onto Zenoh, so ROS 2 application code is unchanged, but Zenoh nodes cannot speak directly to DDS nodes without an appropriate bridge.

Does switching RMW require recompiling my nodes?

No. Standard ROS 2 nodes link against the rmw abstraction and load the concrete implementation at runtime. Set RMW_IMPLEMENTATION and restart. The exception is code that calls vendor-specific APIs directly, which is uncommon and generally discouraged.

Why do my ROS 2 nodes not discover each other across subnets?

Classic DDS discovery relies on multicast by default, and multicast is not routed across subnets by default. The usual fixes are a VPN that puts both hosts on one logical L2 network, multicast routing, explicit unicast peer configuration in the RMW’s configuration, Fast DDS Discovery Server, or a reachable Zenoh router topology. Zenoh supports this deployment model directly, but routers still need network reachability.

Does the RMW choice affect ROS 2 security?

Yes. Fast DDS supports the DDS-Security specification, which is what SROS 2 builds on for authentication, access control and encryption. Cyclone DDS also has DDS-Security support, but compatibility should be verified for the specific RMW and ROS 2 distribution in use. Zenoh provides its own TLS and mTLS mechanisms plus access control lists, but its integration with the SROS 2 tooling is less established. If your project has a formal security requirement, verify the current state of SROS 2 support for your chosen implementation before you design around it.

How much does middleware choice affect latency in practice?

On a clean wired LAN with small messages, the differences between implementations are typically small relative to the latency contributed by the application itself and by the OS scheduler. The differences become significant with large messages, lossy wireless links and high endpoint counts. This is why measuring on your own hardware matters more than comparing published benchmark tables.

Where to Go From Here

Middleware selection is one layer of a working robot. If your project involves a specific payload, an unusual network topology, multi-robot coordination or an environment where the standard configuration does not hold, Fictionlab’s team works with research groups and integrators on platform adaptations that start from the rover hardware and extend into the software stack. Learn more about custom robotics development with Fictionlab.