Zenoh (rmw_zenoh)

Zenoh (rmw_zenoh) – definition

Zenoh is a communication protocol and middleware framework designed for distributed systems that exchange data across local networks, routed networks, and constrained links. In ROS 2, rmw_zenoh_cpp is a ROS Middleware (RMW) implementation that connects the ROS 2 client library layer to the Zenoh transport and discovery system.

The term rmw_zenoh commonly refers to this ROS 2 integration, although the package name used by ROS 2 distributions is rmw_zenoh_cpp. It is an alternative to DDS-based RMW implementations such as rmw_fastrtps_cpp and rmw_cyclonedds_cpp. ROS 2 application code remains based on publishers, subscriptions, services, actions, parameters, and the ROS graph API.

For mobile robotics and UGV deployments, Zenoh is relevant when a robot must communicate beyond one multicast-friendly laboratory LAN. This includes a Leo Rover connected through Wi-Fi infrastructure, a field robot operating through a routed network, or a Raph Rover exchanging telemetry and perception data with an edge computer. It does not provide autonomy, SLAM, motor control, or sensor drivers by itself. It changes the middleware layer used to transport ROS 2 communication.

How rmw_zenoh works in ROS 2

ROS 2 defines an abstraction layer called RMW. The client libraries, including rclcpp and rclpy, use this layer instead of calling a specific transport implementation directly. An RMW implementation is selected when ROS 2 processes start.

With rmw_zenoh_cpp, ROS 2 entities are represented through Zenoh sessions and resources. Zenoh can operate in peer-to-peer configurations or use routers to forward traffic between network segments. This differs from common DDS deployments, where discovery and endpoint matching usually depend on DDS discovery traffic within a configured domain.

The operational distinction matters on UGV networks. DDS multicast may require explicit configuration on managed Wi-Fi, VLANs, VPNs, or routed subnets. A Zenoh router can provide a defined communication path when multicast is unavailable or undesirable. The robot, operator station, and compute server must still be configured according to the selected Zenoh topology.

The following command selects the Zenoh RMW implementation for a ROS 2 shell session, provided that rmw_zenoh_cpp is installed for the selected ROS 2 distribution. With the default configuration, a Zenoh router must also be running (ros2 run rmw_zenoh_cpp rmw_zenohd) so that nodes can discover each other.

source /opt/ros/jazzy/setup.bash
export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run demo_nodes_cpp talker

The RMW selection must be consistent for nodes intended to communicate directly through the same middleware deployment. A ROS 2 node using one RMW implementation does not automatically discover a node using another RMW implementation on the same host.

Zenoh topology for mobile robot deployments

Zenoh supports different deployment patterns. The appropriate option depends on network reliability, bandwidth, firewall rules, and whether the robot must remain observable outside the local wireless segment.

Topology	UGV context	Engineering consideration
Peer-to-peer	Leo Rover and a nearby development laptop on one local network.	Suitable for controlled tests. Network discovery and addressing must be verified.
Router-assisted	Robot Wi-Fi network connected to a lab server or operator network.	A Zenoh router can forward selected communication across routed segments.
Edge-to-cloud or edge-to-server	Raph Rover logging telemetry to an on-premise compute node.	Limit high-bandwidth image and point-cloud forwarding through rate control or local processing.

Zenoh transport does not remove the need to engineer data flows. A depth camera, LiDAR, and visual odometry pipeline can generate significantly more traffic than wheel odometry or battery telemetry. For example, a robot should generally process raw camera frames locally and publish reduced outputs such as detections, occupancy information, poses, or compressed diagnostic streams when the wireless link is limited.

QoS and ROS 2 interface compatibility

ROS 2 Quality of Service (QoS) policies express requirements such as reliability, durability, history, and deadline behavior. ROS 2 defines these concepts in its middleware-independent API, while each RMW implementation maps supported policies to its underlying transport capabilities.

Before deploying rmw_zenoh_cpp, validate the exact ROS 2 distribution and package version used by the robot. QoS support, graph behavior, service handling, and tooling integration can change between releases. A configuration tested with a DDS-based RMW must not be assumed to have identical behavior under Zenoh.

The following checks should be part of integration testing for a mobile platform.

Confirm that publishers and subscribers appear in ros2 node list and ros2 topic info -v.
Test the QoS profiles required by the application, including reliable and best-effort topic flows where supported by the installed RMW version.
Measure message delay and loss for control-adjacent topics such as /odom, /tf, and /cmd_vel.
Verify that lifecycle nodes, actions, parameters, rosbag recording, and diagnostics operate with the installed RMW version.
Test reconnection after a Wi-Fi interruption, router restart, or robot reboot.

Use with Leo Rover and Raph Rover

Leo Rover can be used with ROS 2 distributions supported by its software image and hardware configuration. On its onboard Raspberry Pi, middleware selection should be evaluated together with CPU load, memory use, wireless stability, and the requirements of the navigation stack. Zenoh can be considered when the robot needs ROS 2 communication across non-local network segments or when a router-based topology is easier to manage than multicast-dependent discovery.

Leo Rover uses differential drive and requires separate integration of sensor drivers, state estimation, SLAM, and navigation. For example, an autonomous configuration may publish wheel odometry, IMU data, LiDAR scans, and transforms locally, while only selected navigation status and diagnostic topics are forwarded to a remote station.

For a larger rover with demanding sensor and compute configurations, a router-assisted Zenoh deployment may be useful when the platform carries a LiDAR, multiple cameras, GNSS/RTK equipment, and an onboard GPU computer. The design objective should be deterministic local operation. Navigation and safety-relevant control loops should not depend on an external network connection.

Limitations and implementation notes

rmw_zenoh_cpp should be treated as a specific ROS 2 middleware implementation, not as a universal replacement for DDS. It has its own release maturity, packaging status, supported platforms, QoS coverage, and configuration model. A project should consult the package documentation and test the target ROS 2 distribution before making it part of a production robot image.

Zenoh is also related to, but distinct from, bridges that connect ROS 2 DDS traffic to Zenoh networks. A bridge and an RMW implementation solve different integration problems. The RMW approach runs ROS 2 nodes directly over Zenoh. A bridge preserves a DDS-based ROS 2 deployment while exposing selected traffic through Zenoh.

Normative references and documentation

The following primary sources define the relevant ROS 2 and Zenoh concepts.