Tune Zenoh for ROS 2 traffic over wireless networks
Introduction
Understand ROS 2 sensor traffic constraints over wireless links
Prepare the system and measure the baseline
Tune Zenoh on an emulated wireless link
Measure Zenoh traffic policy effects with real Wi-Fi
Select a Zenoh deployment policy for ROS 2 over Wi-Fi
Next Steps
Tune Zenoh for ROS 2 traffic over wireless networks
Who is this for?
This Learning Path is for robotics developers who want to understand how Zenoh manages ROS 2 sensor traffic over Wi-Fi.
What will you learn?
After completing this Learning Path, you'll be able to perform the following tasks:
- Measure the rate, bandwidth, and regularity of ROS 2 sensor data at a remote receiver
- Reproduce a constrained wireless link with Linux traffic control
- Configure Zenoh compression, access control, downsampling, and quality of service policies
- Validate the policies over real Wi-Fi and select a suitable deployment configuration
Prerequisites
Before starting, you'll need the following prerequisites:
- The ROS 2 simulation environment from
Build a ROS 2 and Zenoh simulation environment on an Arm server
, with the
robotandcontrolcontainers available - The distributed Zenoh configuration from
Distribute a ROS 2 robotic system across Arm devices with Zenoh
, with the
controlcontainer connected in client mode - An Arm server with the Docker Compose configuration used in Build a ROS 2 and Zenoh simulation environment on an Arm server and Distribute a ROS 2 robotic system across Arm devices with Zenoh
- A Raspberry Pi connected over Wi-Fi
- Familiarity with ROS 2 topics, Docker, and basic Linux commands
Summary
This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
You’ll measure ROS 2 sensor traffic, emulate a constrained wireless link, and tune Zenoh policies to manage ROS 2 traffic over Wi-Fi. First, you’ll record baseline rates for
/scan, /camera/image_raw, and /camera/points in a wireless emulation. Then, you’ll apply tc and netem, test compression, access control, downsampling, and quality of service (QoS), and compare the results. Finally, you’ll repeat the policy tests with a Raspberry Pi over real Wi-Fi and choose a deployment policy.Frequently asked questions
These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
From the Arm server host, run
docker compose up -d in ~/ros_zenoh, then use docker compose ps. Both services should report Up. Then, open the robot container desktop and confirm that the Zenoh router, simulation, and Navigation2 processes are running. Restart any process that stopped.Open a terminal in the
robot container desktop and run source ~/workshop_env.bash, followed by just network_limit. Apply the tc/netem limits from within the container environment used for the experiments.just network_limit prints the applied parameters, including rate, latency variation, loss, and reordering. Look for output that states the simulation is applied with values such as a 25mbit rate and nonzero latency and loss.The
/camera/image_raw and /camera/points streams dominate bandwidth, while /scan is small. Compress the streams when you need to preserve them. If you don’t need point-cloud data, use access control to block /camera/points. If you need complete point-cloud frames, use compression with the QoS block_first policy.Use downsampling when the compressed camera stream still exceeds the available link capacity. Set the forwarded image rate less than the sustained capacity of the link to trade frame rate for steadier delivery and lower jitter.