DDS (Data Distribution Service)

DDS (Data Distribution Service) – definition

DDS, or Data Distribution Service, is a middleware standard for distributed real-time systems published by the Object Management Group (OMG). It defines a data-centric publish-subscribe communication model. In this model, software components publish typed data to named topics, while other components subscribe to the topics they need. Publishers and subscribers do not require direct knowledge of each other’s network address, process, or lifecycle.

In ROS 2, DDS is the default communication layer between nodes. ROS 2 uses an abstraction called the ROS Middleware interface (rmw) to support DDS implementations such as Fast DDS, Eclipse Cyclone DDS, RTI Connext DDS, and GurumDDS. DDS is therefore responsible for transporting ROS 2 messages between processes, computers, and onboard computers connected to a mobile robot network.

For UGV platforms such as Leo Rover and Raph Rover, DDS carries data between the robot base, perception sensors, navigation stack, teleoperation interface, logging tools, and external workstations. Typical DDS traffic includes LiDAR scans, wheel odometry, IMU measurements, camera streams, transforms, velocity commands, occupancy grids, and diagnostic messages.

Source: OMG DDS v1.4 specification; ROS 2 Quality of Service documentation.

How DDS works in ROS 2

ROS 2 nodes communicate through publishers, subscriptions, services, actions, and parameters. Topics are the main DDS-backed communication mechanism for continuous robot data. A ROS 2 publisher serializes a message and sends it through the selected rmw implementation. DDS discovery identifies compatible subscribers on the same network and establishes data exchange according to the configured Quality of Service policies.

ROS 2 topic names are mapped to DDS topic names. The ROS 2 design uses DDS naming conventions with prefixes such as rt/ for standard ROS topics. This mapping allows DDS implementations to distinguish ROS graph entities from other DDS entities on the same domain.

The following ROS 2 interfaces are commonly transported through DDS on a mobile UGV:

sensor_msgs/msg/LaserScan for 2D LiDAR measurements.
sensor_msgs/msg/Imu for angular velocity, acceleration, and orientation data.
nav_msgs/msg/Odometry for wheel, visual, or fused odometry.
geometry_msgs/msg/Twist for velocity commands sent to the robot base.
tf2_msgs/msg/TFMessage for coordinate frame transforms.
nav_msgs/msg/OccupancyGrid for maps generated by SLAM or navigation systems.

DDS discovery is decentralized. A ROS 2 system does not require a ROS master, unlike ROS 1, which used the ROS Master for graph registration. ROS 1 normally used TCPROS or UDPROS for topic transport. ROS 2 uses DDS through an rmw layer instead.

Source: ROS 2 topic and service name mapping; ROS 2 QoS concepts.

DDS Quality of Service policies

Quality of Service, usually called QoS, is one of the most important DDS mechanisms in mobile robotics. QoS determines how a publisher and subscriber exchange data. A connection is created only when their QoS policies are compatible.

The table below lists DDS and ROS 2 QoS policies that directly affect UGV sensor integration and navigation.

QoS policy	Purpose	UGV example
Reliability	Controls whether data delivery is best effort or reliable.	Use best effort for high-rate LiDAR or camera data when low latency is more important than retransmission.
Durability	Controls whether late-joining subscribers receive stored samples.	Use transient local durability for a static map or robot configuration topic.
History	Defines whether the middleware keeps a configured number of samples or all samples, subject to resource limits.	Use a limited queue for IMU and odometry streams to avoid processing stale data.
Depth	Defines the number of queued samples when keep-last history is used.	Select depth according to processing delay, message size, and available memory.
Deadline	Defines an expected maximum interval between messages.	Can detect a stopped sensor or inactive localization source.
Liveliness	Determines how publishers prove that they remain active.	Can help monitor command or telemetry publishers.

QoS mismatches are a common reason why a ROS 2 subscriber receives no data despite a visible topic name. For example, a reliable subscriber may not communicate with a best-effort publisher. The ros2 topic info --verbose command displays endpoint QoS settings and should be part of system diagnostics.

ros2 topic info /scan --verbose
ros2 topic echo /odom --qos-reliability best_effort
ros2 doctor --report

Source: ROS 2 QoS policy reference.

DDS on Leo Rover and Raph Rover

Leo Rover can run ROS 2 on its Raspberry Pi-based compute unit. DDS can communicate between onboard ROS 2 nodes and a development computer connected through the same network. A typical Leo Rover setup may publish wheel odometry and robot state data onboard while an external workstation runs visualization, recording, mapping, or navigation tools.

Leo Rover has a four-wheel differential drive base. Its autonomous operation requires an integrated navigation stack, sensor drivers, transforms, localization or SLAM, and correctly configured DDS communication. DDS does not provide autonomy by itself. It transports the messages required by systems such as Nav2, robot_localization, SLAM Toolbox, or custom perception nodes.

Raph Rover can use the same DDS-based ROS 2 architecture when a larger payload requires additional sensors, compute hardware, or power capacity. For example, a Raph Rover integration may distribute LiDAR, RTK GNSS, IMU, camera, and mission-control nodes across multiple computers. DDS allows these components to exchange typed ROS 2 messages without application-specific socket programming.

On both platforms, bandwidth planning is required when transmitting point clouds or image streams. Large messages, unreliable wireless links, and incompatible QoS settings can increase latency or cause dropped samples. Sensor drivers should publish only the data needed by the active perception or navigation pipeline.

Example ROS 2 QoS configuration

The following YAML fragment defines a sensor-oriented QoS profile. The depth value of 5 is an example configuration value, not a Leo Rover or Raph Rover hardware requirement. It must be validated against the sensor rate, message size, CPU load, and network conditions of a specific deployment.

scan_subscription:
  reliability: best_effort
  durability: volatile
  history: keep_last
  depth: 5

For command, map, or mission-state topics, reliable delivery may be appropriate. For high-throughput sensor topics, best-effort delivery can prevent delayed retransmitted packets from reaching downstream perception nodes after the data is no longer useful.

Standards and ROS 2 implementations

DDS is standardized by the OMG. The DDS interoperability wire protocol is DDSI-RTPS, also maintained by OMG. ROS 2 does not require one specific DDS vendor implementation. The active middleware implementation is selected through an RMW package, such as rmw_fastrtps_cpp or rmw_cyclonedds_cpp.

The relevant technical references are:

OMG DDS v1.4, published by the Object Management Group.
OMG DDSI-RTPS v2.3, defining interoperable DDS wire communication.
ROS 2 middleware interface documentation for the rmw abstraction.
REP 2000, which defines ROS 2 release and target platform policies.
ROS 2 QoS documentation, which defines the ROS-facing interpretation of DDS QoS policies.

Source: OMG DDSI-RTPS v2.3; ROS 2 middleware implementations; REP 2000.

DDS (Data Distribution Service)