What is DDS?

This is an open-standard data communications framework designed to facilitate real-time, scalable and reliable communication between distributed systems. Essentially, different systems can be running but communication easily through a shared network.

Data-centric: The data is the interface between applications (nodes). In other words, the nodes interact with a shared "data space" for a topic. So nodes don't communicate via endpoints, but they all communicate with the "data space" where the RMI (ROS Middleware Interface - DDS Wrapper) ensures the data gets to where it needs to.

How do Nodes find each other?

DDS uses a peer-to-peer discovery protocol (part of RTPS — Real-Time Publish-Subscribe, the actual wire protocol DDS implementations use). How it works:

• Participant discovery (SPDP): every DDS participant (roughly: every ROS2 node) periodically multicasts/broadcasts "I exist" announcements on well-known ports. Other participants on the network hear these and learn who's out there.
• Endpoint discovery (SEDP): once two participants know about each other, they exchange details about what topics they're publishing/subscribing to, with what QoS. If a publisher and subscriber match on topic name, type, and compatible QoS, DDS wires them up directly (usually unicast UDP after that) — no broker in the middle relays the data.

Essentially, every node maintains its own local knowledge of the whole graph of nodes. Therefore, NO CENTRAL REGISTRY.

Domain ID

Domain ID is essentially an ID for a physical network which can host the "data space" for different systems. In our case, there is no need for partitioned networks for different systems as each subsystem will need to communicate with one another (to an extent). Therefore the default ROS_DOMAIN_ID=0 is fine for our use case.

QoS Policies

QoS polices are a given to nodes, a system that essentially determines how data is trafficked. Some key notes:

• Reliability: Could be set to RELIABLE (like TCP) vs BEST_EFFORT (like UDP).
• Durability: Could be set to VOLATILE (late-joining subscribers wait until a new message arrives) vs TRANSIENT_LOCAL (late joiners get the last published message(s).
• History: how many past messages to keep buffered (KEEP_LAST with a depth or KEEP_ALL)
• Deadline/Liveliness: contracts about expected publishing rate and detecting a dead publisher.

MAIN GOTCHA WITH QoS IS WHERE A PUBLISHER AND SUBSCRIBER ARE INCOMPATIBLE AND WILL FAIL TO CONNECT (e.g., RELIABLE vs BEST_EFFORT)

Which DDS to run?

DDS is a standard, which have multiple different implementations that all speak RTPS. ROS2 lets you pick whichever one. To ROS2, it doesn't matter as the ROS2 middleware (RMW layer) wrapper works for any kind. The common ones are:

• Fast DDS: Default in most ROS2 distros
• Cyclone DDS: popular alternative, often used because its discovery behaves better on some networks

Sources

• ROS2: What is DDS