Selecting a ROS 2 RMW for a Wi-Fi Mobile Robot Fleet

Decision and constraints

You are deploying a fleet of mobile robots on Wi-Fi, and ROS 2 nodes on different robots must find each other. The default discovery mechanism in many ROS 2 setups uses multicast, which Wi-Fi access points often filter, drop, or segment. The wrong ROS Middleware (RMW) choice can leave nodes invisible to each other with no obvious error.

Useful takeaway: For a license-free fleet on ROS 2 Jazzy Jalisco running Ubuntu 24.04, use Fast DDS (rmw-fastrtps-cpp) with a Discovery Server and static peer addresses. It removes the multicast dependency, supports shared memory between nodes on the same robot, and keeps dependencies in Debian packages. Validate with ros2 node list and a timed publisher/subscriber test before committing to hardware.

Terms used below: RMW is the ROS Middleware plug-in layer that carries messages between nodes. DDS is the Data Distribution Service protocol underneath. A Discovery Server is a Fast DDS component that introduces nodes using static addresses instead of multicast.

Constraints for this decision:

• ROS 2 Jazzy Jalisco on Ubuntu 24.04.
• Zero license cost.
• 50 Hz cmd_vel and odometry traffic.
• Intermittent Wi-Fi; robots may roam between access points.
• Debian-packaged dependencies preferred.
• Every node in the system must use the same RMW; mixing RMWs prevents discovery.

Supported RMW options

RMW package	License	Discovery method	Best fit	Main caveat
rmw-cyclonedds-cpp	BSD	Multicast (default)	Simple bench or single-subnet robots	Wi-Fi access points often block multicast
rmw-fastrtps-cpp	Apache 2.0	Discovery Server or multicast	Wi-Fi fleets needing static peers	Extra XML configuration
rmw-connextdds	Commercial (RTI)	Proprietary	Deterministic, QoS-heavy systems	License purchase; missing license can cause silent startup failures

Trade-offs

Cyclone DDS

Cyclone DDS is the default lightweight option. It is free and requires almost no configuration on a wired bench network. On Wi-Fi, multicast discovery can be flooded by access-point isolation or silently dropped, so nodes may fail to find each other after a restart.

Fast DDS

Fast DDS remains free and is tuned for ROS 2. A Discovery Server lets you replace multicast with static peer addresses, which is more predictable on segmented Wi-Fi. Shared memory reduces copies when multiple nodes run on the same onboard computer. The cost is an XML configuration file and the requirement that peers use static IPs or DNS-resolvable hostnames.

RTI Connext

Connext offers strong QoS controls and deterministic behavior, but it is commercial. A missing or invalid license file can cause silent node startup failures or restricted domain participation. Procurement and per-node cost make it a poor fit for a zero-license fleet unless you already have a site license.

Because all nodes must share one RMW, changing the RMW on one robot requires changing it on every robot and workstation in the fleet.

Implementation

Assumptions: ROS 2 Jazzy is installed, the ROS apt repository is configured, and you have root access on the onboard computer. Package names can shift between releases; verify before scripting.

1. Confirm available RMW packages

Run on the robot as a normal user:

apt-cache search ros-jazzy-rmw | grep rmw

Expected check: output includes ros-jazzy-rmw-fastrtps-cpp. If the package list changes, update the install command accordingly.

2. Install Fast DDS RMW

Run on the robot onboard computer with sudo or root:

sudo apt update && sudo apt install ros-jazzy-rmw-fastrtps-cpp

Expected check:

dpkg -l | grep ros-jazzy-rmw-fastrtps-cpp

should show an ii status. Risk: this changes system state; test on a staging robot first.

3. Set the RMW at runtime

Run in the robot shell or set in a launch file:

export RMW_IMPLEMENTATION=rmw_fastrtps_cpp

To persist across sessions, add that line to ~/.bashrc or pass it as a launch environment variable. Expected check:

echo "$RMW_IMPLEMENTATION"

returns rmw_fastrtps_cpp.

4. Configure Discovery Server (optional but recommended)

Place a Fast DDS profile file on each robot, for example ~/ros2_ws/fastdds_discovery.xml. Treat the following as a skeleton; exact tags depend on your installed Fast DDS version.

<?xml version="1.0" encoding="UTF-8" ?>
<fastdds>
  <discovery_server>
    <address>REPLACE_WITH_DISCOVERY_SERVER_IP</address>
    <port>11811</port>
  </discovery_server>
</fastdds>

Point Fast DDS to the file:

export FASTRTPS_DEFAULT_PROFILES_FILE=~/ros2_ws/fastdds_discovery.xml

Use a static IP or DNS-resolvable hostname for the Discovery Server. DHCP churn can break static discovery configurations.

5. Validate discovery on two robots

On Robot A:

ros2 run demo_nodes_cpp talker

On Robot B:

ros2 run demo_nodes_cpp listener

On either robot:

ros2 node list

Expected check: both /talker and /listener appear. Restart the talker and confirm the listener rediscovers it within the Discovery Server announcement period.

Validation

Latency comparison

Build a custom rclcpp publisher/subscriber pair. The publisher stamps each message with rclcpp::Time; the subscriber logs received - sent. Send 10,000 messages at 50 Hz and compute the p99 latency. Repeat the test with RMW_IMPLEMENTATION=rmw-cyclonedds-cpp and compare p99 values. This tells you whether Fast DDS meets your 50 Hz control-loop timing on the actual Wi-Fi link.

Rediscovery check

Restart one node while the other keeps running. Use ros2 node list to confirm the restarted node reappears without relying on multicast. Also check ros2 topic list and ros2 node info /talker to verify publishers and subscribers are matched.

Limitation: bench latency results do not replace validation in the actual RF environment. Wi-Fi multicast behavior varies by access point, so run the discovery test where the robots will operate.

Rollback

Because installation changes system state, you can revert by removing the package and restoring the previous RMW:

sudo apt remove ros-jazzy-rmw-fastrtps-cpp
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

Review apt output before confirming removal, since dependent packages may be affected. Re-run the discovery validation after switching back.

Limitations

• Exact package names and support timelines can shift between ROS releases; verify with apt-cache before provisioning.
• Discovery Server requires static IP or DNS-resolvable peers; DHCP churn can break static configurations.
• RTI Connext requires a valid license file; absence can cause silent failures.
• All nodes in a ROS 2 system must use the same RMW.
• ROS 1 Noetic is end-of-life; do not start new robot products on ROS 1.

Bottom line

Choose Fast DDS with Discovery Server for a cost-constrained Wi-Fi fleet on ROS 2 Jazzy. It avoids multicast fragility, stays license-free, and installs from Debian packages. Confirm the choice with ros2 node list and a p99 latency test on your actual network before scaling to the full fleet.