Understand the distributed ROS 2 topology

Understand how the ROS 2 system is distributed

By completing the prerequisite Learning Path Build a ROS 2 and Zenoh simulation environment on an Arm server , you placed the complete ROS 2 system on one server. A real robot deployment is different: the operator station can be elsewhere, sensor nodes can run on separate devices, and the monitoring display can be on a laptop.

You’ll distribute the system in three stages:

1. Connect the control container to the robot over the Docker network and run RViz remotely.
2. Connect a Raspberry Pi to the Arm server over the physical network.
3. Extend the design to multiple robots using ROS namespaces and domain IDs to prevent communication conflicts.

In the first two stages, you’ll use Zenoh client mode to coordinate communication across containers and physical devices. The final stage introduces a practical approach toward preventing communication conflicts when multiple robots share the same infrastructure.

Both the server and the Pi run the same arm64 ROS 2 packages. The development machine and the deployment target share one instruction set, so there’s no cross-compilation step between them.

Understand the router and client mode

The Zenoh router has four roles:

• Configuration entry point: It reads ROUTER_CONFIG.json5 once at startup. Any configuration change requires a router restart.
• Discovery service for local peers: It introduces nodes to each other, after which they communicate directly. You saw this when you observed Zenoh router discovery behavior while completing the prerequisite Learning Path. Stopping the router didn’t interrupt an established conversation.
• Relay for client-mode nodes: A client holds a single connection to the router. Every message it sends or receives passes through that connection.
• Traffic policy enforcement point: Compression, access control, downsampling, and QoS rules all apply here. For more information, see the next Learning Path in the series Tune Zenoh for ROS 2 traffic over wireless networks .

Why cross-device nodes use client mode

Nodes inside the robot container listen on loopback only. A peer on another container or host learns their addresses through the router, tries to connect directly, and fails. In failing, the peer produces a state where ros2 topic list shows every topic but no data arrives. A client makes one outbound connection to the router and lets the router relay in both directions, which also suits NAT and firewalled networks because no inbound port is needed.

Router count

Router count follows subsystems instead of machines. A remote side running only a few nodes connects them as clients. A remote side that’s a multi-node subsystem of its own runs a router locally and links the two routers, so its internal traffic stays local and only cross-system traffic crosses the link.

For more information about the topology, see the rmw_zenoh documentation .

What you’ve learned and what’s next

You now understand how the Zenoh router coordinates communication and why nodes across containers and Arm devices use client mode.

Next, you’ll configure the control container as a Zenoh client.