ROS 2 Lyrical Luth · Lesson 75 of 86
Distributed systems
Several computers in one ROS graph: networking, discovery server and time sync.
Estimated time · 60–90 min
Learning goals
What you will understand
- Explain distributed systems 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
A robot often has several computers (an onboard controller, a perception computer, an operator laptop). ROS 2 nodes on the same network and domain discover each other automatically, but timestamps, name clashes and discovery traffic cause trouble. Synchronize clocks with chrony or PTP, use a unique namespace per robot, and pick one domain ID per system.
The Fast DDS Discovery Server replaces multicast discovery with a central server: each node connects to it by address, so discovery works on networks without multicast and traffic drops. Set ROS_DISCOVERY_SERVER on every machine and run the server on one of them.
Guided lesson
Work through these steps
- 1.
Source the ROS 2 Lyrical environment in a fresh terminal.
- 2.
Read the distributed systems 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
fastdds discovery --server-id 0
# Start a discovery server (ID 0) on the main computer.
export ROS_DISCOVERY_SERVER=192.168.1.10:11811
# On every other machine: connect to that server.
ros2 run demo_nodes_cpp talker
# The talker announces itself via the server.
ros2 daemon stop && ros2 daemon start
# Restart the CLI daemon so it uses the same discovery settings.
chronyc tracking
# Check that this machine's clock is synchronized.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.
Demo for Distributed systems. Expected result: The listener on the second machine receives the talker's messages
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.
# On the second machine, point to the discovery server on the first
# TODO: set ROS_DISCOVERY_SERVER to 192.168.1.10:11811
ros2 run demo_nodes_cpp listenerExpected output
The listener on the second machine receives the talker's messagesStuck? Show the full solution (try it yourself first)
# On the second machine, point to the discovery server on the first
export ROS_DISCOVERY_SERVER=192.168.1.10:11811
ros2 run demo_nodes_cpp listenerExpected 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
Connect two machines using the discovery server, run a talker on one and a listener on the other, then stop the server and observe what still works. Check the clock offset with chronyc.
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
Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.
Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.