DEV Community

vmodal_ai
vmodal_ai

Posted on

Building a High-Performance Robot Communication System with DDS

#ros2 #dds #robotics #cpp

Building a High-Performance Robot Communication System with DDS

Modern robots may have dozens of processes distributed across CPUs, edge computers, and embedded devices.

ROS 2 uses DDS (Data Distribution Service) as its underlying communication technology. Understanding DDS helps you design robot systems that remain responsive as message traffic grows.

The Communication Model

Instead of connecting every process directly:

Camera ---> Perception
LiDAR  ---> Perception
IMU    ---> Localization
                 |
                 v
             Planning
                 |
                 v
              Control
Enter fullscreen mode Exit fullscreen mode

ROS 2 nodes communicate through DDS topics and discovery.

A simplified model is:

Publisher
    |
    v
 DDS DataWriter
    |
    v
   Topic
    |
    v
 DDS DataReader
    |
    v
Subscriber
Enter fullscreen mode Exit fullscreen mode

Why DDS Is Useful for Robotics

DDS provides mechanisms for:

  • Discovery
  • Reliability
  • Durability
  • Deadline management
  • History
  • Resource limits
  • Data delivery policies

These features are important because different robot data has different requirements.

A camera stream may prioritize low latency. A configuration message may prioritize reliability.

High-Performance Design

Avoid treating every topic identically.

For example:

Data Typical Priority
Camera frames Low latency
LiDAR scans High throughput
IMU Low latency
Robot commands Reliability
Configuration Reliability + durability
Diagnostics Reliability

Reduce Copying

Large sensor messages can consume substantial CPU and memory bandwidth.

Good practices include:

  • Avoid unnecessary serialization/deserialization.
  • Reuse buffers where possible.
  • Keep image resolution appropriate for the workload.
  • Compress only when bandwidth savings justify CPU cost.
  • Separate high-rate sensor topics from low-rate metadata.

Separate Data Paths

A useful architecture is:

                 +--> Vision
Camera ----------+
                 |
LiDAR -----------+--> Perception --> Planning --> Control
                 |
IMU -------------+

Diagnostics ---------------------> Monitoring
Configuration ------------------> Lifecycle Manager
Enter fullscreen mode Exit fullscreen mode

Not all traffic needs the same QoS or processing path.

Measuring Performance

Do not optimize based on intuition alone.

Measure:

  • End-to-end latency
  • Message frequency
  • Dropped messages
  • CPU usage
  • Memory usage
  • Network bandwidth
  • Callback execution time

For a sensor pipeline, measure from timestamp at acquisition to timestamp at consumption.

Scaling Across Machines

DDS can support distributed nodes:

Robot Computer A
  Camera
  LiDAR
      |
      | DDS
      v
Robot Computer B
  Perception
  Localization
      |
      | DDS
      v
Robot Computer C
  Planning
  Control
Enter fullscreen mode Exit fullscreen mode

Network configuration becomes important when moving beyond a single machine.

Practical Optimization Strategy

Start with a correct system:

  1. Define topic ownership.
  2. Select suitable QoS.
  3. Measure traffic.
  4. Identify bottlenecks.
  5. Reduce unnecessary copies.
  6. Tune history and reliability.
  7. Test under peak sensor load.
  8. Test degraded network conditions.

High-performance robot communication is primarily an architecture problem, not simply a matter of increasing CPU or network capacity.

Useful Links

Top comments (0)