If you have started working with ROS 2 and heard people mention DDS, you are not alone in wondering what it actually does. DDS is the hidden engine that makes ROS 2 nodes find each other, share sensor data, and survive flaky Wi-Fi on a busy factory floor.
In this guide, I will walk you through what DDS in ROS 2 really means, how the middleware works under the hood, and the practical knobs you will eventually want to turn. By the end, you will understand why the ROS 2 team chose DDS, how Quality of Service (QoS) policies affect your robot, and which DDS vendor to pick for your next project.
Table of Contents
What Is DDS in ROS 2 and Why It Matters
DDS (Data Distribution Service) is the communication middleware in ROS 2 that handles discovery, message definition, serialization, and publish-subscribe transport between robot nodes. It is an open standard managed by the Object Management Group (OMG), and ROS 2 uses it as the default communication layer underneath topics, services, and parameters.
Think of DDS as the postal service for your robot. Your publishers drop letters into a mailbox, your subscribers pick up matching letters, and the postal service figures out the routes, the addresses, and the delivery guarantees. You never have to write the routing code yourself.
ROS 2 wraps DDS behind a thin layer called the ROS Middleware Interface (RMW), so most users never call DDS APIs directly. Still, the middleware shapes almost every network behavior you care about: latency, reliability, discovery speed, and how two robots on the same Wi-Fi talk to each other.
Here is the short version you can keep in your head:
- DDS provides peer-to-peer discovery with no central master node
- DDS uses a strict publish-subscribe pattern built on RTPS
- DDS exposes Quality of Service (QoS) policies for fine control
- ROS 2 supports multiple DDS vendors behind one RMW interface
Why ROS 2 Uses DDS as Its Middleware
The original ROS relied on a single central process called roscore to register every node and topic. That worked fine on a laptop, but it was fragile for production robots, multi-robot fleets, and real-time systems. The ROS 2 design team needed a replacement that was distributed, real-time friendly, and vendor neutral.
DDS fit those requirements for three concrete reasons. First, DDS is an open OMG standard, which means multiple vendors implement it and the spec is publicly auditable. Second, DDS was already deployed in aerospace, defense, and automotive systems, so its design had been battle tested for safety-critical workloads. Third, DDS supports Quality of Service policies, which give ROS 2 a real answer to questions like “what happens if a message is dropped?” or “how do I know my sensor is still alive?”
When I run ROS 2 on a multi-robot testbed, the difference is obvious. With ROS 1, I had to manually launch roscore on a master machine and pray the network stayed up. With ROS 2, I just bring up the nodes and they find each other, even if a leader robot reboots in the middle of a mission.
How the Publish-Subscribe Mechanism Works in DDS
At its core, DDS is a publish-subscribe (pub-sub) middleware. Publishers send data on named topics, subscribers receive data from those topics, and DDS handles the matching, the transport, and the wire format. There is no direct connection between a publisher and a subscriber, which is what makes the system so flexible.
Topics, Publishers, and Subscribers
A topic is a named channel that carries a specific message type. A DataWriter (the publisher) creates samples on a topic, and a DataReader (the subscriber) consumes them. The DDS implementation matches writers and readers automatically, even if a publisher and subscriber are on different machines.
In ROS 2, when you write node.create_publisher(String, 'chatter', 10), the RMW layer creates a DDS DataWriter behind the scenes. When another node creates a matching create_subscription, DDS negotiates the transport and starts streaming messages. You never see the DDS API, but the behavior you observe comes directly from DDS.
DDS Participants and RTPS
Every ROS 2 node is mapped to a DDS DomainParticipant, which is the entry point into the DDS world. Participants join a domain (identified by an integer domain ID) and discover other participants on the same domain. Discovery itself runs over the RTPS (Real-Time Publish-Subscribe) protocol, which is the wire-level sibling of DDS defined by the OMG.
RTPS runs over UDP by default, which keeps latency low and avoids the head-of-line blocking you get with TCP. DDS vendors also support TCP and shared memory transports for cases where you need reliable delivery or zero-copy local communication.
Quality of Service (QoS) Policies Explained
QoS is the part of DDS that catches most new ROS 2 users off guard, and it is also the part that makes DDS genuinely powerful. A QoS policy is a contract between a publisher and a subscriber that defines how the data is delivered. If the two sides cannot agree, DDS will not connect them, which is loud and immediate feedback.
Reliability and Durability
Reliability controls whether DDS retransmits lost packets. BEST_EFFORT drops messages on loss and is fine for high-rate sensor streams like camera frames. RELIABLE retransmits until delivery, which is the right choice for state updates and commands.
Durability controls what happens to messages sent before a subscriber appears. VOLATILE means late subscribers do not get historical data. TRANSIENT_LOCAL caches the last few samples, so a subscriber that joins late gets a quick catch-up. I use TRANSIENT_LOCAL for robot state topics so RViz can grab the current pose the moment it connects.
Deadline, Liveliness, and History
Deadline sets a maximum interval between messages. If a sensor stops publishing within its deadline window, DDS flags a missed deadline event, which is great for monitoring sensor health.
Liveliness lets the system detect when a publisher has crashed or lost network. Manual liveliness requires the publisher to actively assert it is alive, while automatic liveliness is driven by the write rate. I default to automatic liveliness in nearly every project.
History controls how many samples DDS keeps for late-joining subscribers. KEEP_LAST(N) only caches the most recent N samples, while KEEP_ALL retains everything (at higher memory cost).
DDS Discovery in ROS 2 Explained
DDS discovery is what makes ROS 2 feel magical. When you launch a node, it announces itself to the network, learns about existing participants, and starts matching publishers with subscribers without any central coordinator. This is called peer-to-peer distributed discovery.
Peer-to-Peer Discovery
Discovery in DDS happens in two phases. In the participant discovery phase, each DomainParticipant announces itself by sending SPDP (Simple Participant Discovery Protocol) messages on well-known multicast addresses. In the endpoint discovery phase, participants exchange their DataWriter and DataReader information using SEDP (Simple Endpoint Discovery Protocol).
Because the announcements use multicast and periodic unicast heartbeats, every node on the same domain eventually learns about every other node, with no single point of failure.
Domain IDs and Multi-Robot Setup
A domain ID is an integer from 0 to 232 that scopes discovery. Nodes on different domain IDs cannot see each other, which is how you isolate robots that share a Wi-Fi network. The ROS 2 default is domain ID 0.
For multi-robot setups, I usually give each robot its own domain ID (for example, fleet 1 = domain 10, fleet 2 = domain 20) and then bridge specific topics between domains when needed. Setting the domain is as simple as exporting ROS_DOMAIN_ID=10 before launching your nodes.
The RMW Abstraction Layer and Supported DDS Vendors
ROS 2 does not lock you into a single DDS implementation. Instead, it defines a thin C API called the ROS Middleware Interface (RMW), and each supported DDS vendor ships an RMW implementation that translates ROS 2 calls into vendor-specific DDS calls. This means you can swap DDS vendors by changing an environment variable, with no changes to your application code.
Fast DDS (eProsima)
Fast DDS is the default DDS vendor in most ROS 2 distributions, including Humble and Jazzy. It is open source under Apache 2.0, maintained by eProsima, and supports the full ROS 2 RMW surface. Fast DDS is a solid default for most projects and the one I recommend for new users unless you have a specific reason to switch.
Cyclone DDS (ZettaScale)
Cyclone DDS is a lightweight, open source DDS implementation maintained by ZettaScale (formerly part of ADLINK). It is known for low resource usage, fast discovery, and clean performance on constrained hardware. Many teams running ROS 2 on small embedded boards prefer Cyclone.
RTI Connext
RTI Connext is a commercial, production-grade DDS implementation from Real-Time Innovations. It is widely used in safety-critical and certified systems, offers strong tooling, and is a common choice for medical robots, autonomous vehicles, and defense platforms. RTI also provides a free Connext DDS Micro for research and evaluation.
To switch vendors, set the environment variable before launching your ROS 2 nodes:
RMW_IMPLEMENTATION=rmw_fastrtps_cppfor Fast DDSRMW_IMPLEMENTATION=rmw_cyclonedds_cppfor Cyclone DDSRMW_IMPLEMENTATION=rmw_connextddsfor RTI Connext
ROS 2 vs ROS 1 Communication: Why DDS Matters
The shift from ROS 1 to ROS 2 is largely the shift from a custom TCP-based protocol on top of roscore to a standardized DDS middleware. That change has practical consequences for everyday robot development.
In ROS 1, you had to deal with ROS_MASTER_URI, single-point-of-failure masters, and quirky XML-RPC discovery. In ROS 2, you deal with QoS profiles, domain IDs, and DDS vendor selection. The new model is more flexible, but it is also more complex, which is why many beginners feel the learning curve is steeper.
The good news: for simple nodes, you almost never touch DDS directly. The bad news: when something goes wrong on the network, you eventually have to learn the DDS knobs to fix it. That is where most of the frustration in ROS 2 forums comes from.
Getting Started with DDS in ROS 2
You do not need to learn everything about DDS to be productive in ROS 2. A few practical defaults will get you through 90 percent of projects.
Choosing a DDS Vendor
Start with Fast DDS because it is the default in Humble and Jazzy and has the widest community support. Move to Cyclone DDS if you run on small embedded boards or notice discovery taking too long. Reach for RTI Connext when you need commercial support, certification, or advanced tooling.
Configuring DDS Domains
Set ROS_DOMAIN_ID for each robot or robot group. If you are running multiple robots on the same network, give each one a unique domain ID to keep their topics isolated. Use the ROS_DOMAIN_ID environment variable or the --enclave option in ros2 run and ros2 launch.
Troubleshooting Common Issues
Three issues cause most of the “my topic is not showing up” pain. First, mismatched QoS profiles: a publisher with RELIABLE and a subscriber with BEST_EFFORT will not connect. Use ros2 topic info -v to inspect QoS on both ends. Second, domain ID mismatch: a node on domain 0 cannot see a node on domain 10. Confirm with echo $ROS_DOMAIN_ID on each host. Third, multicast blocked: some Wi-Fi networks block the multicast groups DDS uses for discovery. If nodes on the same domain cannot see each other, ask your network admin to allow DDS multicast (typically 239.255.0.1 for SPDP and several ports in the 7400 range).
For deeper debugging, the ros2 doctor tool and the DDS vendor’s own diagnostic tools (Fast DDS’s fastdds tool, Cyclone DDS’s ddsperf) will surface the exact reason two endpoints fail to match.
Frequently Asked Questions
What is DDS in ROS 2?
DDS (Data Distribution Service) is the communication middleware in ROS 2. It provides discovery, message definition, serialization, and publish-subscribe transport between nodes, replacing ROS 1’s central roscore model with a peer-to-peer distributed architecture.
What does DDS stand for in networking?
DDS stands for Data Distribution Service. It is an open standard managed by the Object Management Group (OMG) that defines a real-time, peer-to-peer publish-subscribe communication framework used in robotics, aerospace, automotive, and defense systems.
What is the DDS protocol?
The DDS protocol is built on RTPS (Real-Time Publish-Subscribe), which runs primarily over UDP. It uses multicast for participant discovery (SPDP) and unicast/multicast for endpoint discovery (SEDP), then negotiates data transport between matched DataWriters and DataReaders.
What is DDS RTI?
DDS RTI refers to RTI Connext, a commercial DDS implementation from Real-Time Innovations. It is one of several DDS vendors supported by ROS 2 through the RMW interface and is widely used in safety-critical and certified robotic systems.
Why does ROS 2 use DDS?
ROS 2 uses DDS because it is an open standard with multiple vendors, supports peer-to-peer discovery with no single point of failure, exposes Quality of Service policies for real-time control, and is already proven in production-grade safety-critical systems.
Which DDS implementation should I use with ROS 2?
For most projects, start with Fast DDS because it is the ROS 2 default and well supported. Choose Cyclone DDS for small embedded boards or fast discovery. Pick RTI Connext when you need commercial support, advanced tooling, or certification.
Is ROS 2 better than ROS 1?
ROS 2 is better suited to production and multi-robot systems because DDS removes the central roscore single point of failure, supports real-time QoS, runs natively on multiple platforms, and scales to larger fleets. ROS 1 is simpler for single-laptop experiments but is no longer recommended for new production work.
Conclusion: What Is DDS in ROS 2
DDS in ROS 2 is the standardized publish-subscribe middleware that gives the framework its real-time, distributed, multi-vendor character. It replaces ROS 1’s central roscore with peer-to-peer discovery, adds Quality of Service policies for tunable reliability, and lets you swap vendors without rewriting your application code.
If you are starting a new ROS 2 project, the practical path is simple. Use Fast DDS, pick a domain ID for your robot or fleet, and only reach for QoS tuning when you hit a real problem. The more time you spend on a real robot, the more DDS reveals itself as a quiet, reliable layer that you stop noticing. That is exactly the goal of the ROS 2 design team, and it is what makes DDS in ROS 2 worth learning.