ROS 2 Lyrical Luth · Lesson 74 of 86

DDS tuning

Cyclone and Fast DDS settings, network interfaces, multicast and large data.

Estimated time · 60–90 min

Learning goals

What you will understand

Explain dds tuning in your own words
Use it in a small robotics example
Verify the result instead of assuming it worked

Understand the idea first

The mental model

Default DDS settings work on one machine but often fail on real networks. Common problems: discovery traffic flooding Wi-Fi, multicast blocked by routers, and large messages (images, point clouds) fragmenting and being dropped. DDS is configured with an XML file selected through an environment variable (CYCLONEDDS_URI or FASTRTPS_DEFAULT_PROFILES_FILE).

Typical fixes: bind to one network interface, limit discovery to known peers (or use a discovery server), increase the socket receive buffer (sysctl net.core.rmem_max), and use compressed image transport. Change one thing at a time and measure with ros2 topic hz and bw.

Guided lesson

Work through these steps

1.
Source the ROS 2 Lyrical environment in a fresh terminal.
2.
Read the dds tuning example and identify what each line does.
3.
Build only the affected package, source the workspace overlay, and run the example.
4.
Inspect the result from a second terminal with the ros2 CLI or RViz2 and compare it with the expected result.

Worked example

Read it before you run it

<CycloneDDS>
<!-- Root of the Cyclone DDS configuration. -->
  <Domain id="any">
<!-- Applies to every domain id. -->
    <General><Interfaces><NetworkInterface name="eth0"/></Interfaces><AllowMulticast>spdp</AllowMulticast></General>
<!-- Use only eth0 and multicast for discovery only. -->
    <Internal><SocketReceiveBufferSize min="10MB"/></Internal>
<!-- Ask for a 10 MB receive buffer. -->
  </Domain>
<!-- End of the domain. -->
</CycloneDDS>
<!-- End of the file. -->

What the example is doing

1.The ros2 commands query the running graph; they do not prove that a node's internal behavior is correct.
2.Build from the workspace root, then source install/setup.bash so the shell can discover the new package.
3.Use a second sourced terminal to inspect nodes and interfaces while the example runs.

Watch it run · Messages between nodes

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

Practice code

Now type it yourself

Copy the starter into your ROS 2 package, replace every TODO, then build with colcon build and run it from a sourced terminal.

export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
# TODO: point CYCLONEDDS_URI at the file ~/cyclonedds.xml
ros2 run demo_nodes_cpp talker

Expected output

The node uses Cyclone DDS with your configuration

Stuck? Show the full solution (try it yourself first)

export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
export CYCLONEDDS_URI=file://$HOME/cyclonedds.xml
ros2 run demo_nodes_cpp talker

Expected result

How you know it worked

ROS_DISTRO is lyrical in every terminal used for the exercise.
The complete package from the exercise builds and the expected graph entity appears in a second terminal.

Practical exercise

Apply the lesson

Send a 640×480 image stream between two machines over Wi-Fi, observe drops with ros2 topic hz, then bind DDS to one interface, raise the receive buffer and compare. Record each change and its effect.

Before you continue

ROS_DISTRO reports lyrical in every terminal you used
The example builds and runs without errors
You checked the result with a ros2 command, RViz2 or a test, not just by reading the code

If something goes wrong

ros2 cannot find a package or executable.

Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.

Nodes run but cannot discover each other.

Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.