Flexibility in RMW Zenoh: Switching Between Zenoh-CPP and Zenoh Pico Backends

Next Generation ROS
, ,
1

I have been following the development of the rmw_zenoh implementation for ROS 2, and I noticed some significant updates in recent releases.

Originally, the project aimed to implement an RMW (ROS Middleware) layer written in C to interface with Zenoh, which itself had a C-based implementation.

However, it now appears that rmw_zenoh has shifted to a C++ implementation (rmw_zenoh_cpp) with dependencies on Zenoh’s C++ bindings (zenoh_cpp_vendor).

Why was the transition made from a C-based RMW layer to a C++ implementation?

What are the expected benefits with this new C++ based approach compared to the original C implementation?

2 Likes
2

Hi there,
Yes, we recently moved from using zenoh-c to zenoh-cpp as the backend for rmw_zenoh.

There are 2 major benefits to moving to zenoh-cpp:

  1. We were able to fix a number of our failing tests and some problems with undefined behavior by using zenoh-cpp. Specifically, the ability to pass lambdas with captures into zenoh-cpp subscription/queryable callbacks made it so that resources do not get destroyed while a Zenoh callback may still happen.
  2. zenoh-cpp is a “wrapper” around either zenoh-c or zenoh-pico. While there is no active work going on with zenoh-pico at the moment, the transition to zenoh-cpp may allow us to use zenoh-pico as a backend in the future.
7 Likes
3

If Zenoh-Pico becomes the backend for the ROS RMW, does this mean we could achieve a unification of embedded systems and standard ROS implementations under a single RMW setup?

This would streamline the setup and communication across microcontrollers, SBCs, and full-fledged systems. Has there been any progress or discussion regarding this possibility?

1 Like
4

With Zenoh maturing to 1.0 it is a real possibility, but only @clalancette can confirm this.

If you are interested, some people have already started looking into this:

Personally, I find micro-ros cumbersome, so I try to avoid using it. Excited for what ROS-zenoh pico might bring. Yet, mico-ros is a nice option to have for embedded.

1 Like
5

In all likelihood, zenoh-pico will never be the default backend. There is a reason it is a separate implementation from zenoh proper, and that’s because it doesn’t support all of the features of regular zenoh. However, it would be nice for zenoh-pico to become an option for those who want to build from source and prefer to use it in an embedded scenario.

1 Like
6

Thank you for clarifying.

I have a few follow-up questions regarding the RMW structure:

  1. The possibility of switching between backends like Zenoh-Cpp (For Zenoh Proper) and Zenoh pico. Will such flexibility be supported, and how would it be managed within the RMW?

  2. Will Zenoh-Cpp and Zenoh-pico co-exist within the same RMW structure? If so, how would the RMW handle the differing capabilities of the two implementations?

  3. Would it be possible for someone to use both Zenoh-Cpp and Zenoh-pico in the same project, for instance, to support both standard and embedded devices? If yes, how would the RMW manage communication or interoperability between these two backends?

1 Like
7

In short: I don’t know. We haven’t done any detailed examination of any of these questions, and we probably won’t look into it in the near future. But we did want to make the option available to those who wanted to poke at it and try it out.

8

I hope this discussion plants some seeds and sparks meaningful discourse around these points.
RMW_Zenoh is very interesting and with the prospect of leveraging most of Zenoh features and hopefully Zenoh-pico is thrilling.

Thank you for work the around RMW_Zenoh.

1 Like