Data Distribution Service (DDS)
The spinal cord of modern autonomous mobile robots. DDS provides the real-time, fault-tolerant middleware connectivity that enables AGVs to share sensor data, coordinate fleet movements, and execute critical commands instantly without a central server.
_hero.png)
Core Concepts
Publish-Subscribe Pattern
Decouples data producers (sensors) from consumers (navigation algorithms). An AGV's LIDAR simply "publishes" scan data, and any system needing it "subscribes" anonymously.
Quality of Service (QoS)
Offers granular control over data delivery. You can prioritize critical emergency stop commands (Reliable) over high-frequency telemetry logs (Best Effort).
Real-Time Performance
Designed for deterministic environments. DDS minimizes latency and jitter, ensuring that control loops in fast-moving mobile robots react within milliseconds.
Data-Centricity
The middleware understands the data structure. It manages the "Global Data Space," meaning applications interact with data objects directly rather than messaging specific IP addresses.
Broker-less Architecture
Unlike MQTT, DDS is peer-to-peer. There is no single point of failure (central broker), making it ideal for robust industrial environments where Wi-Fi might be spotty.
Dynamic Discovery
Nodes automatically discover each other when they join the network. A new AGV added to the fleet is instantly recognized by the Fleet Management System without manual configuration.
How It Works: The Global Data Space
DDS creates a virtual "Global Data Space" where data availability is decoupled from the physical location of the robots. In a warehouse setting, an AGV's navigation computer, the fleet manager server, and the safety PLC all connect to this shared space.
When a robot's battery monitor publishes a status update, it doesn't need to know who is listening. The charging station, the dashboard UI, and the maintenance logger all subscribe to that specific "Topic" and receive the update instantly via UDP/IP multicasting.
This architecture allows for massive scalability. Whether you have 5 robots or 500, the communication logic remains exactly the same, with the network handling the routing efficiently.
_diagram.png)
Real-World Applications
Sensor Fusion & Perception
AGVs process gigabytes of data from cameras, LIDARs, and IMUs per second. DDS handles this high-bandwidth throughput internally within the robot (via shared memory) to build 3D maps in real-time without latency.
Swarm Coordination
In grid-based fulfillment centers, robots must avoid collisions while moving at high speeds. DDS enables peer-to-peer negotiation of right-of-way between robots without needing to query a central server for every movement.
Mission Critical Teleoperation
When a human operator needs to take over a stuck robot, video feeds and control commands are transmitted via DDS. QoS settings ensure that control commands take precedence over video quality to maintain safety.
Distributed Fleet Management
Unlike traditional monolithic servers, DDS allows fleet intelligence to be distributed. If the main Wi-Fi goes down, robots in a local area can still communicate via ad-hoc networking to maintain safety zones.
Frequently Asked Questions
What is the relationship between DDS and ROS 2?
DDS is the default connectivity middleware for ROS 2 (Robot Operating System 2). While ROS 1 used a custom TCP/UDP protocol with a central master, ROS 2 abstracts DDS to provide industry-grade reliability, security, and real-time capabilities out of the box.
How does DDS differ from MQTT?
MQTT relies on a central broker and is designed for low-bandwidth IoT over the public internet. DDS is broker-less, peer-to-peer, and data-centric, designed for high-performance, real-time LAN communication within and between robots. DDS is faster but requires more complex configuration.
Is DDS suitable for wireless (Wi-Fi/5G) networks?
Yes, but it requires tuning. Because DDS often relies on UDP multicast for discovery, which can be lossy on Wi-Fi, you may need to configure "Discovery Servers" or specific QoS profiles to handle packet loss and variable latency inherent in wireless connections.
What is the overhead of using DDS on an embedded microcontroller?
Standard DDS implementations can be heavy, but "Micro-XRCE-DDS" is specifically designed for microcontrollers (like STM32 or ESP32). It bridges resource-constrained devices to the main DDS network, allowing simple sensors to participate in the global data space.
How do I handle network security with DDS?
The DDS standard includes a security specification (DDS-Security). It supports authentication, access control, and encryption at the data level. You can configure it so that only authorized robots can publish movement commands or read sensitive map data.
What happens if two robots publish to the same topic simultaneously?
DDS handles this natively. Subscribers will receive data from both publishers. You can use keys (like RobotID) to distinguish the data streams, or ownership strength QoS to designate a primary publisher (e.g., for redundant sensors).
Why are my robots not discovering each other on the network?
This is the most common DDS issue. It usually stems from the network switch blocking Multicast traffic (IGMP snooping) or a firewall on the robot's OS blocking UDP ports. Ensure Multicast is enabled on your infrastructure or switch to Unicast discovery.
Does DDS guarantee data delivery?
Only if you tell it to. If you set the QoS to "Reliable," DDS will acknowledge packets and retransmit lost ones. If set to "Best Effort," it behaves like standard UDP (fire and forget), which is preferred for high-frequency sensor data where old data is useless.
Can DDS handle large file transfers (like map updates)?
Technically yes, but it's not optimized for it. While it can fragment and reassemble large messages, using DDS for massive file blobs can clog the network for real-time traffic. It is often better to use DDS to trigger a separate HTTP/FTP transfer for large files.
Are there open-source implementations available?
Yes. The most popular open-source implementations used in robotics are Eclipse Cyclone DDS and eProsima Fast DDS. There are also commercial options like RTI Connext which offer advanced tooling and support for safety-critical certification.
How does Shared Memory transport work in DDS?
When publishers and subscribers are on the same computer (e.g., inside one robot), smart DDS implementations bypass the network stack entirely. They copy data directly into RAM (Zero Copy), drastically reducing latency and CPU usage for heavy sensor loads.
What is the "Domain ID" in DDS?
The Domain ID is a virtual partition of the network. Robots on Domain 0 cannot talk to robots on Domain 1, even if they are on the same physical wire. This allows you to run multiple separate fleets or simulation environments on the same infrastructure without crosstalk.