ROS 2 DDS Tuning for Multi-Robot Fleets: Step-by-Step Guide

 

DDS Tuning for Multi-Robot Fleets: Preventing Network Storms

In ROS 1, a centralized roscore acted as the traffic cop. While this created a single point of failure, it kept discovery traffic localized. ROS 2 replaces this with DDS, a decentralized peer-to-peer architecture.

By default, every ROS 2 node on a subnet aggressively shouts over UDP multicast to discover every other node: "Are you there? Do you have this topic?"

When you have one robot, this works beautifully. When you deploy a fleet of 15 robots—each streaming high-frequency LiDAR data, camera feeds, transforms (/tf), and Nav2 metrics—the default discovery mechanism triggers a massive multicast storm. Your Wi-Fi router gets flooded, CPU usage spikes, messages drop, and your robots face catastrophic "ghost tracking" failures.

To scale from one prototype to a commercial fleet, you must tune your DDS middleware.

1. Fundamentals: The Three Shields of Fleet Isolation

To optimize a multi-robot network, you must apply isolation at three different layers of the software stack:

Layer	Implementation	Purpose
Application Layer	ROS 2 Namespaces (/robot_1/cmd_vel)	Stops a control command meant for Robot A from driving Robot B.
Network Partitioning	DDS Domain IDs (ROS_DOMAIN_ID)	Segregates cross-talk between different sub-fleets or development groups.
Discovery Architecture	FastDDS Discovery Server / Zenoh	Switches the network from chaotic multicast to a structured, centralized peer lookup.

The Math: Scalability Overhead

Without tuning, the network discovery cost scales quadratically ($O(N^2)$) relative to the number of participants ($N$). By implementing a centralized Discovery Server architecture, we linearize this cost to $O(N)$, freeing up critical network bandwidth for actual state data.

2. Step-by-Step Fleet Optimization Guide

This guide walks you through setting up a production-ready, multi-robot communication pipeline using eProsima FastDDS (the default middleware for ROS 2 Humble) and Eclipse CycloneDDS.

Step 1: Implement Strict ROS 2 Namespacing

Never launch raw, top-level topics like /cmd_vel or /scan on a multi-robot network. Group every node inside a unique robot namespace during launch execution:

Python

# snippet inside your multi_robot_launch.py
from launch.actions import GroupAction
from launch_ros.actions import PushRosNamespace

robot_1_nodes = GroupAction(
    actions=[
        PushRosNamespace('robot_1'),
        # Include your nav2 and driver launch files here
    ]
)

Step 2: Isolate Environments via Domain IDs

If you have multiple test engineers running independent projects on the same office Wi-Fi, they will accidentally intercept each other's data blocks. Isolate them using the ROS_DOMAIN_ID environment variable (valid values range from 0 to 232).

Assign a distinct ID to each environment inside your system’s environment setup file (~/.bashrc):

Bash

export ROS_DOMAIN_ID=42

Step 3: Deploy a FastDDS Discovery Server (The Game Changer)

To completely stop the Wi-Fi multicast storm, we shift from simple peer-to-peer discovery to a Discovery Server model. One central machine (like an edge workstation or cloud hub) acts as a directory.

[Robot 1 Node] \                  / [Robot 2 Node]
                 --> [Discovery] <-- 
[Robot 1 Nav]  /     [ Server  ]  \ [Robot 2 Nav]

1. Spin up the central server node on your edge hub (IP: 192.168.1.100):

Bash

fastdds discovery -i 0 -p 11811

(This opens a tracking server with ID 0 listening on port 11811)

2. Point your robots to the server:

On every single robot computer in the fleet, force the RMW (ROS Middleware) to use FastDDS and point it directly to your server's static IP address by adding these environment paths:

Bash

export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
export ROS_DISCOVERY_SERVER="192.168.1.100:11811"

Now, nodes will only communicate their profiles directly to the central server, instantly slashing your wireless multicast overhead to zero.

Step 4: Tuning Async Publishing for Heavy Payloads

By default, FastDDS publishes small messages synchronously. However, large data payloads like 3D LiDAR point clouds or high-definition camera frames can block your primary processing execution loop.

Create an explicit XML configuration file named fastdds_mesh_config.xml:

XML

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLProfiles/1.0">
    <publisher profile_name="async_perf_profile" is_default_profile="true">
        <qos>
            <publishMode>
                <kind>ASYNCHRONOUS</kind>
            </publishMode>
        </qos>
    </publisher>
</profiles>

Export this configuration path to your active terminals:

Bash

export RMW_FASTRTPS_USE_QOS_FROM_XML=1
export FASTRTPS_DEFAULT_PROFILES_FILE=~/fastdds_mesh_config.xml

3. Alternative 2026 Fleet Paradigm: Eclipse Zenoh

While DDS tuning is highly effective, the robotics landscape has introduced exciting updates. Many advanced multi-robot operators are migrating to Eclipse Zenoh.

Zenoh completely bypasses standard DDS discovery headaches over lossy connections (like 5G or industrial Wi-Fi). It acts as an ultra-lightweight protocol designed specifically for the far edge, cutting networking bandwidth requirements by up to 70%.

Conclusion: The Fleet is Ready

By applying proper namespaces, constraining your Domain IDs, and routing traffic through a Discovery Server, you can expand your multi-robot fleet without fear of network degradation. Your software-defined hardware is now fully prepared for massive enterprise-scale orchestration.

ROS2 Multi-Robot Discovery Server Tutorial

This video provides a deep technical breakdown of the network packet savings achieved when transitioning a multi-robot system from standard UDP Multicast to a dedicated FastDDS Discovery Server architecture.