Robot Software
Which DDS Implementation Should a ROS 2 Robot Use?
The middleware under ROS 2 is swappable, and the choice changes discovery behaviour, latency and licensing. A comparison of the realistic options and when to move off the default.
Change it when discovery misbehaves or a licence demands it, not for benchmark numbers. ROS 2 abstracts the middleware behind an interface layer, so switching is an environment variable, and the practical differences show up in discovery at scale, behaviour over WiFi and support terms rather than in single-message latency, which sits in the hundreds of microseconds for all serious options on a wired link.
Why the choice exists at all
ROS 2 defines an abstraction, the middleware interface, and ships several implementations behind it. Application code targets the client library, not the middleware, so the same node can run on a different transport without a rebuild in most cases. The design article behind that decision is explicit that no single implementation would suit every deployment, from a microcontroller to a fleet across a plant network.
| Implementation | Licence model | Strength | Watch for |
|---|---|---|---|
| Fast DDS | Open source, commercial support available | Default in recent releases, broad feature coverage | Discovery traffic at scale without a discovery server |
| Cyclone DDS | Open source | Lean, predictable, popular for real-time work | Fewer enterprise features out of the box |
| Connext DDS | Commercial with an evaluation path | Tooling, certification support, large deployments | Licence cost and terms |
| Zenoh-based middleware | Open source | Designed for scale, WiFi and wide area links | Newer, ecosystem still maturing |
Discovery is the real differentiator
Default DDS discovery is peer-to-peer: every participant announces itself and learns about every other. The message count grows roughly with the square of participant count, so a system with 20 nodes across four machines is comfortable and a system with 200 nodes is not. Symptoms of strain are recognisable: startup taking tens of seconds, multicast storms on the plant network, and nodes intermittently failing to see each other.
Three fixes exist, in increasing order of change.
- Discovery server. Participants register with a known server instead of announcing to everyone, which converts quadratic traffic to linear. Available without changing implementation.
- Domain partitioning. Splitting a fleet across domain identifiers isolates traffic, at the cost of needing a bridge for cross-domain data.
- A different middleware. Implementations designed around a router model rather than pure peer-to-peer scale further and behave better over lossy links.
On latency, honestly
Benchmarks comparing implementations produce differences that are real and usually irrelevant. On a wired gigabit link, single-message round trip for small payloads sits in the region of 0.1 ms to 1 ms across serious implementations. Application-level factors dominate that by an order of magnitude: executor configuration, callback scheduling, serialisation of large messages, and whether the transport takes a shared-memory path between processes on the same machine.
The one measurement worth making yourself is large-message behaviour. Camera and lidar payloads of several megabytes stress fragmentation and flow control, and this is where implementations genuinely diverge. Test with your actual message sizes and your actual rate, not with a 32-byte ping.
A decision rule
- Stay on the default unless something specific pushes you off it. Compatibility and community support are worth more than a benchmark margin.
- Move for real-time determinism if jitter measurements on the default are unacceptable after executor tuning.
- Move for scale when participant counts pass a few dozen and a discovery server has not solved it.
- Move for wireless or wide area when robots roam or when nodes must communicate across sites.
- Move for commercial requirements when a customer demands supported software or certification evidence.
Frequently asked questions
Can I change the ROS 2 middleware without changing my code?
In most cases yes. The middleware sits behind an abstraction layer and is selected by an environment variable, so application code targeting the client library runs unchanged. Features that reach past the abstraction are the exception.
Which implementation is fastest?
The differences on a wired link are small, typically within the 0.1 ms to 1 ms band for small messages, and application factors such as executor configuration dominate. Large message handling is where implementations genuinely diverge, so test with your real payload sizes.
Why does discovery get slow with many nodes?
Because default peer-to-peer discovery has every participant announce to every other, so traffic grows roughly with the square of the participant count. Beyond about 30 to 50 participants a discovery server or a router-based middleware becomes necessary.
Does ROS 2 work well over WiFi?
Not with default settings. Multicast discovery is transmitted at the lowest data rate and is unacknowledged, so it is slow and lossy over wireless. Use a discovery server or a middleware designed for lossy links.
Is DDS security usable in practice?
Yes. DDS-Security provides authentication, encryption and access control, configured through certificates and permission files. It adds latency and a key management task, so it is a deliberate choice rather than a default.
Sources
- ROS on DDSROS 2 design article on the middleware abstraction and why it is pluggable
- DDS implementations in ROS 2Open Robotics documentation, supported implementations and how to select one
- About quality of service settingsOpen Robotics documentation, settings that interact with middleware behaviour