How ROS 2 DDS Middleware Actually Works

When you write node.create_publisher(Float64, '/velocity', 10) in ROS 2, you're not just registering a topic name. You're configuring a DDS DataWriter with QoS policies and advertising via the Simple Discovery Protocol.

What DDS Actually Is

DDS (Data Distribution Service) is an OMG standard for pub-sub middleware. The wire protocol is RTPS, which runs on UDP. No broker, no central server — matching happens via discovery.

Discovery

When a node starts, it sends SPDP announcements on a well-known multicast address. Every node on the same domain responds. This is why a new node takes 200–500ms before receiving messages.

QoS Policies

from rclpy.qos
  import QoSProfile, ReliabilityPolicy

sensor_qos =
  QoSProfile(reliability=ReliabilityPolicy.BEST_EFFORT, depth=1)
cmd_qos =
  QoSProfile(reliability=ReliabilityPolicy.RELIABLE, depth=10)

Mixing RELIABLE subscriber with BEST_EFFORT publisher causes silent subscription failures.

Deadline Policy

from
  rclpy.duration import Duration
imu_qos = QoSProfile(deadline=Duration(milliseconds=10))

Fires a callback if a message doesn't arrive in time. Cleaner than a manual watchdog timer.

Executor

Model

The default SingleThreadedExecutor processes callbacks sequentially — a slow image callback blocks everything. Use MultiThreadedExecutor with ReentrantCallbackGroup for parallel callbacks.

For our wind tunnel work, a DDS monitor logging dropped messages to InfluxDB revealed the 60Hz control loop was dropping at the Pi network interface — not in application code.