[Ubuntu News] Bring Zenoh to ROS 2 with snaps

[xSicKxBot]

ROS 2 gives robotics developers the freedom to choose the middleware that fits their system. As a communication protocol for ROS, Zenoh has gained strong traction. It delivers proven performance and stability while giving developers explicit control over node discovery.

Zenoh is a lightweight, high-performance communication protocol designed for robotics and distributed systems. Supporting publisher/subscriber and query-based communication, it handles unreliable network connections efficiently. It can act as the middleware for ROS 2 systems.

For teams running ROS 2 applications with DDS (Data Distribution Service), a Zenoh bridge provides a way to keep applications as they are and bridge their communication into Zenoh. Meanwhile, the Zenoh router provides data stream routes and distributes queries across endpoints.

To deploy ROS 2 and Zenoh effectively, you need a stable, reliable environment. This blog explores how to achieve that using snaps, covering three key deployment approaches:

• Packaging: Include the Zenoh ROS middleware directly within your application
  
  
• Infrastructure: Run the Zenoh router as a standalone snap
  
  
• Integration: Use the Zenoh-to-DDS bridge to connect existing ROS 2 applications
  
  

These methods are not mutually exclusive, enabling teams to mix and match as needed to suit their architecture.

Package Zenoh with your ROS 2 application

When developers want to use Zenoh as part of the application, they can include the rmw_zenoh_cpp dependency directly in the ROS 2

Code:

snapcraft.yaml

.

The talker_listener_zenoh_core24 project in the ROS snap examples repository demonstrates this approach with ROS 2 Jazzy. It packages the familiar

Code:

demo_nodes_cpp

talker and listener while selecting Zenoh via the

Code:

RMW_IMPLEMENTATION

environment variable.

The important changes in

Code:

snapcraft.yaml

appear below:

Code:

[code]base: core24 confinement: strict parts: ros-demos: plugin: colcon source: https://github.com/ros2/demos.git source-branch: jazzy stage-packages: - [b]ros-jazzy-rmw-zenoh-cpp[/b] - ros-jazzy-ros2run apps: talker-router: command: opt/ros/jazzy/bin/ros2 run demo_nodes_cpp talker plugs: [network, network-bind] extensions: [ros2-jazzy] environment: [b] RMW_IMPLEMENTATION: rmw_zenoh_cpp[/b][/code]

The

Code:

ros2-jazzy extension

sets up the ROS 2 environment inside the snap. The

Code:

stage-packages

entry adds

Code:

rmw_zenoh_cpp

, while

Code:

RMW_IMPLEMENTATION

tells the application to use it at runtime.

This keeps the communication choice within the application. The developer controls the ROS 2 version, middleware package, environment, and application lifecycle in one artifact. The same tested package can then move between development systems and robots without rebuilding on each device.

The example provides two operating modes: one using a dedicated Zenoh router (talker-router/listener-router) and another relying on multicast scouting (talker/listener). This flexibility enables developers to start with a compact, all-in-one package for workstations or robots, then evolve to a separate router service if their communication architecture scales, without needing to change the application.

Run the Zenoh router as a snap

A router is infrastructure, and infrastructure requires stability.

The zenohd snap packages the Zenoh router as a command and a system service. It can be installed independently of the ROS 2 applications that use it:

Code:

[code]sudo snap install zenohd sudo snap start --enable zenohd.daemon[/code]

The service is installed disabled, so users decide when to enable it. Once enabled, snapd manages it like other snap services.

The router can also run as a terminal command:

Code:

[code]zenohd [OPTIONS][/code]

If you plan to pass a configuration file via the CLI, ensure it is in a location accessible to a strictly confined snap.

The snap looks for a JSON5 or YAML configuration under its snap-managed data directories. The default daemon configuration path is:

Code:

[code]/var/snap/zenohd/common/config.json5[/code]

The upstream reference configuration documents the available options.

After changing it, restart the service:

Code:

[code]sudo snap restart zenohd.daemon[/code]

The

Code:

snapcraft.yaml

file describes the daemon and command for reference.

With a router deployed in the cloud, multiple Zenoh-enabled applications can communicate across the internet. In that setup, consider configuring TLS authentication for Zenoh.

Add Zenoh to existing ROS 2 applications

Repackaging an application is not always the right starting point. A robot may already run several ROS 2 nodes using DDS, or a team may want to introduce Zenoh without changing those nodes.

The zenoh-bridge-ros2dds snap packages the upstream Zenoh bridge for ROS 2 over DDS. The bridge discovers ROS 2 communication on its DDS side and maps it to Zenoh. This lets existing ROS 2 applications keep their current middleware configuration.

Install and enable it with:

Code:

[code]sudo snap install zenoh-bridge-ros2dds sudo snap start --enable zenoh-bridge-ros2dds.bridge[/code]

Like the router snap, the bridge is installed disabled and can also run as a CLI:

Code:

[code]zenoh-bridge-ros2dds [OPTIONS][/code]

Its configuration can live in the snap’s common data directory:

Code:

[code]/var/snap/zenoh-bridge-ros2dds/common/config.json5[/code]

Or in the root user data directory

Code:

[code]/root/snap/zenoh-bridge-ros2dds/common/config.json5[/code]

The upstream reference configuration documents the available options.

The bridge can sit beside a ROS 2 system on a robot, workstation or other host and connect that DDS domain to the Zenoh side of the architecture. ROS 2 nodes do not need to know that the bridge is there.

The

Code:

snapcraft.yaml

file demonstrates how to package the Rust-based bridge as both a daemon and a CLI.

One RMW implementation, three approaches

To recap, Zenoh offers flexible deployment options for ROS 2 systems through three distinct approaches using snaps:

• Packaging: Developers can bundle the
  Code:

  rmw_zenoh_cpp
  RMW implementation directly within their application snap.
  
  
• Infrastructure: The
  Code:

  zenohd
  router snap serves as shared infrastructure for routing data streams across the system.
  
  
• Integration: The
  Code:

  zenoh-bridge-ros2dds
  snap bridges existing DDS-based applications into the Zenoh network without requiring code changes.
  
  

Snaps unify these deployments with a consistent operational model. All three approaches support

Code:

amd64

and

Code:

arm64

platforms, ensuring hardware-agnostic deployment across different robots. Furthermore, snaps provide a single framework for transactional updates, lifecycle management, and service control through

Code:

snapd

.

Security is central to this model. Strict confinement isolates the communication stack, while mandatory interfaces like

Code:

network

and

Code:

network-bind

enforce explicit system access. This ensures that each component operates within a well-defined boundary.

Ultimately, this allows the application, the bridge, and the router to evolve independently with their own configuration and refresh cycles. This modularity maintains a robust operational boundary for the entire robotics architecture.

Start snapping Zenoh into ROS 2

Here are some practical starting points for the three projects:

• Explore the
  Code:

  rmw_zenoh_cpp
  talker and listener example
  
  
• Install the
  Code:

  zenohd
  router snap
  
  
• Install the
  Code:

  zenoh-bridge-ros2dds
  snap
  
  
• Check the
  Code:

  zenohd
  snap source
  
  
• Check the
  Code:

  zenoh-bridge-ros2dds
  snap source
  
  

If snaps are new to you, start with the Snapcraft overview, then set up Snapcraft and follow the guide to create a snap. The Snapcraft robotics documentation covers the ROS-specific extensions and workflows.

For the middleware itself, consult the ROS 2 Jazzy guide to working with Zenoh, the

Code:

rmw_zenoh

repository, and the Zenoh documentation.

Whether Zenoh belongs inside your application, beside it, or at the center of its communication infrastructure, there is a snap-shaped way to deploy it.