A ROS 2 RMW implementation using the Zenoh protocol for efficient, scalable, and configurable middleware communication.
rmw_zenoh is a ROS 2 middleware (RMW) implementation that replaces the default DDS-based communication layer with the Zenoh protocol. It enables ROS 2 nodes to communicate using Zenoh's efficient data-centric pub/sub and query/response models, offering improved scalability, lower latency, and flexible deployment options for distributed robotics and IoT systems.
ROS 2 developers and robotics engineers building distributed systems that require scalable, low-latency communication across multiple machines or flexible network topologies, such as multi-robot fleets or cloud-connected robotic applications.
Developers choose rmw_zenoh over default DDS-based RMW implementations for its superior scalability, configurable network topologies (peer-to-peer, routed, client-server), and built-in shared memory optimization that works without requiring loaned messages API, reducing latency for intra-host communication.
RMW for ROS 2 using Zenoh as the middleware
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Provides SHM optimization for all messages without requiring loaned messages API, reducing intra-host latency as configured via Zenoh's transport settings.
Supports peer-to-peer, routed, and client-server modes through configurable Zenoh routers, enabling scalable distributed deployments as detailed in the Configuration section.
Includes authentication, encryption, and access control via Zenoh's security tools, with a dedicated package for generating secure configurations.
Implements a serialization buffer pool with configurable memory limits (default 8 MiB) to optimize performance and prevent uncontrolled allocation growth.
Requires running and managing Zenoh routers separately, adding operational overhead compared to DDS-based RMW implementations that handle discovery automatically.
Breaks communication between ROS 2 distributions like Humble and Iron due to type hash changes, leading to silent message drops without clear warnings.
Relies on environment variables and JSON5 config files for basic functionality, which can be error-prone and less intuitive than DDS-based alternatives.