Skip to main content

14. ROS 2 DDS

1. Introduction to DDS

DDS stands for Data Distribution Service. It is a real-time, data-centric publish/subscribe communication standard released by the Object Management Group (OMG) in 2004.

DDS was initially adopted by the U.S. Navy to address large-scale distributed system communication challenges and has since become a widely used real-time communication standard.

DDS emphasizes:

  • Data-centric communication
  • High-performance real-time transmission
  • Flexible Quality of Service (QoS) control

References


2. Communication Model

Topics, services, and actions in ROS 2 are all implemented on top of DDS. DDS acts as the communication backbone of the ROS 2 system.

Four common communication models are:

1. Peer-to-Peer Model

Each client directly connects to the server. As the number of nodes increases, the number of connections increases rapidly.

Disadvantages: - Poor scalability - Hardcoded server addresses - High maintenance cost


2. Broker Model

A central broker forwards all messages between nodes.

Disadvantages: - Performance bottleneck - Single point of failure

ROS 1 used a similar centralized architecture.


3. Broadcast Model

All nodes broadcast and receive messages on the same channel.

Disadvantages: - All nodes receive all messages - Heavy traffic and filtering overhead


4. DDS Data-Centric Model

DDS uses a DataBus where nodes only subscribe to the data they need.

Advantages: - Parallel communication paths - High scalability - Efficient filtering - No central broker


3. Application of DDS in ROS 2

DDS is the core infrastructure layer of ROS 2.

All ROS 2 communication mechanisms rely on DDS for:

  • Discovery
  • Transport
  • Reliability
  • Data synchronization

This design allows developers to focus on application logic instead of networking.


4. Quality of Service (QoS)

Domain Concept

A DDS Domain defines a logical communication space. Only nodes within the same domain can communicate.

This is controlled via:

export ROS_DOMAIN_ID=0

Core QoS Policies

Policy Description


DEADLINE Data must be transmitted within a time limit HISTORY Number of historical messages stored RELIABILITY BEST_EFFORT vs RELIABLE DURABILITY Allow late-joining nodes to receive historical data


5. Test Cases

5.1 Case 1 --- Command-Line DDS QoS Configuration

Publisher Terminal

ros2 topic pub /chatter std_msgs/msg/Int32 "data: 66" --qos-reliability best_effort

Subscriber Terminal (Mismatched QoS)

ros2 topic echo /chatter --qos-reliability reliable

⚠️ A warning will appear due to mismatched QoS.

Correct Matching QoS

ros2 topic echo /chatter --qos-reliability best_effort

✅ Data will now be received correctly.


5.2 Case 2 --- Configuring QoS in Topic Nodes

Step 1: Create Package

ros2 pkg create learning_dds --build-type ament_python --dependencies rclpy std_msgs

Publisher Node (dds_controller_pub.py)

import rclpy
from rclpy.node import Node
from std_msgs.msg import String
from rclpy.qos import QoSProfile, QoSReliabilityPolicy, QoSHistoryPolicy

class ControllerPublisher(Node):

def __init__(self, name):
super().__init__(name)

self.qos_profile = QoSProfile(
reliability=QoSReliabilityPolicy.RELIABLE,
history=QoSHistoryPolicy.KEEP_LAST,
depth=1
)

self.publisher = self.create_publisher(
String,
"/robot_cmd",
self.qos_profile
)

self.timer = self.create_timer(1.0, self.timer_callback)
self.cmd_list = ["forward", "backward", "stop"]
self.cmd_index = 0

def timer_callback(self):
current_cmd = self.cmd_list[self.cmd_index % 3]

msg = String()
msg.data = current_cmd

self.publisher.publish(msg)
self.get_logger().info(f"Command Sent: {msg.data}")

self.cmd_index += 1

def main(args=None):
rclpy.init(args=args)
node = ControllerPublisher("robot_controller_pub")
rclpy.spin(node)
node.destroy_node()
rclpy.shutdown()

if __name__ == "__main__":
main()

✅ This completes DDS-based QoS-controlled communication in ROS 2.