Data Distribution Service (DDS)

Data Distribution Service

Communication protocol describing how data providers and data consumers interact
Publisher: An entity that manages DataWriters, which are responsible for sending data over the system
Subscriber: An entity that manages DataReaders, which are responsible for consuming data sent over the system
Topic: DataWriters publish to a topic and DataReaders subscribe to a topic
Domain: An entity that isolates groups of publishers and subscribers from each other. Only publishers and subscribers in the same domain can communicate
The standard describes the behavior of a system consisting of these entities
- Data-Centric-Publish-Subscribe (DCPS)

RTPS is a protocol that can be (and often is) used by DDS when the DDS entities need to communicate over a network
RTPS can be thought of as the "nuts and bolts" that are used to actually implement a DDS system
Typically implemented over UDP, TCP, or shared memory

DDS is a complicated industrial standard maintained by Object Management Group
Many companies and other entities have implemented this standard and provide code (either free or proprietary)
ROS aims to work with any of these DDS providers
ROS abstracts the DDS provider by providing ROS Middleware Libraries (rmw). These provide a standard ROS API that can then be used to implement ROS Publishers, Subscribers, Services, etc

How does data get delivered and what happens when it can't be delivered?
Similar to being able to choose between:
- TCP (which has features to ensure all packets are delivered on time)
- UDP (where packets can be transmitted quickly but there are no guarantees)
- This is just an analogy, DDS (and RTPS) can be implemented on top of TCP, UDP or something else)
Also, what happens if a publisher is publishing faster than a subscriber can read the data?
See Quality of Service for details about what options are available
ROS has some standard Profiles that are generally useful combinations of DDS settings used in robotics

By default it is "keep last" with a queue size of 10, "reliable" and "volatile"
Services are reliable and volatile
The sensor data profile drops the "reliable", under the theory that it is more important to receive timely data than complete data
Many of the settings use "System Default" which means that, depending on the DDS vendor, there may be different behavior

If both ends of the communication channel (e.g. publisher/subscriber) don't have the same QoS settings, they may be unable to communicate.

User-code can subscribe to various events that occur in the QoS system
This includes detecting if publishing deadlines are missed or if there are problems matching publishers and subscribers

The RMW_IMPLEMENTATION allows you to change the DDS provider if desired
Different DDS providers have different capabilities and are not completely compatible
The current DDS provider is eProsima FAST DDS.

Object Management Group. An Software Industry Standards group that developed DDS