rmw_zenoh -- zenoh-python interop does not work when using the rmw_zenohd router

[vybhav-ibr]

Generated by Generative AI

No response

Operating System:

Ubuntu 22.04

ROS version or commit hash:

humble

RMW implementation (if applicable):

rmw_zenoh

RMW Configuration (if applicable):

No response

Client library (if applicable):

rlcpp

'ros2 doctor --report' output

If i start the zenoh router using the ros2 run rmw_zenoh_cpp rmw_zenohd, Interoperability between rmw_zenoh and zenoh-python does not work, my ros2 topics are not discovered by the zenoh-python subcriber even with the '**' key expression.

If i instead start the zenoh router directly with the zenohd command, the ros2 topics are discoverable using the zenoh-python subscriber.

Not sure if this is the expected behavior, does starting the router directly have any adverse effects ?
I only have a few zenoh-python 'nodes', but i have a lot of ros2 nodes using rmw_zenoh

Steps to reproduce issue

1, start a zenoh router using ros2 run rmw_zenoh_cpp rmw_zenohd
2, start a ros2 publisher using rmw_zenoh
3, try to subscribe to this topic from any zenoh process

Expected behavior

The data published using rmw_zenoh should be available to any zenoh process

Actual behavior

the data is not available

Additional information

No response

[YuanYuYuan]

Hello @vybhav-ibr, thank you for reporting this. This issue is closely related to the peer_failover_brokering option, which is set to false by default in rmw_zenohd.

The reason is that rmw_zenoh assumes sessions are reachable in a peer-to-peer (P2P) setup, which works pretty well in most cases.

In your setup, however, the zenoh-python subscriber likely runs in peer mode with multicast discovery enabled — but discovery is disabled by default on rmw_zenoh sessions.
The reason your configuration (rmw_zenoh publisher → zenohd → zenoh-python subscriber) still works is due to the failover brokering mechanism in the router,
which relays messages even when the publisher and subscriber are not directly discovered.

You can fix this in one of the following ways:

1. Set your zenoh-python node to client mode and connect it to rmw_zenohd or zenohd.
2. Load the RMW_ZENOH_SESSION_CONFIG file in your zenoh-python configuration.

We definitely need to enhance the documentation to clarify this 😅. Please let me know if you still have any issues with this.

Just out of curiosity, why don't you use rclpy with rmw_zenoh on the receiver side?

[vybhav-ibr]

Hi @YuanYuYuan, thanks for the detailed explanation, Ultimately I would like to use zenoh for communicating between an android app and ros2 for sensor streaming. I am using zenoh-android for streaming sensor data and ros2 with rmw_zenoh for receiving the data.

I was using python for observing and debugging the liveliness token, payloads, key expressions, payload attachments etc, when i encountered this error.

I have several questions, please provide some additional insight

• Does the suggested fix(using the RMW_ZENOH_SESSION_CONFIG when creating the zenoh session), carry over to the zenoh-android as well? or would i need something different ?
• Could you also elaborate on how i can set the zenoh-python/zenoh-kotlin node to client mode?. I can see the WhatAmI property in the zenoh-python docs, how do i set this?
• Assuming I use one of the suggested fixes, would data transfer work?. I noticed that TypeHash is not supported for ros2_humble and the GidLength is 24 in ros2 humble, Would things like this effect communication, any other additional caveats ?
  zenoh_android(or any other zenoh bindings) -> rmw_zenoh -> ros2(rclcpp, or rclpy)(any ros2 distro)
• How do i debug the rmw_zenoh if something is not working as expected ?, as far as i can tell, there is no verbose mode, no development mode, no logs, no rosout. Would i just have to compile from source and debug the code internally ?

Additionally, please add some examples in the ROS2 section of zenoh-demos with rmw_zenoh compatibility, currently only examples with ros2-bridge-zenoh-DDS are available

[VintageDoggo]

Hi @vybhav-ibr !

Just pitching in with what I've been using for bridging rnw_zenoh/ zenoh-pico. I'm not sure it will completely translate to your case, but it might help you get going.

As pointed out before, and as some of the rmw_zenoh design docs state, to connect an external session you'll need to open the session to "client" mode during the configuration of the session. If you use the RMW_ZENOH_SESSION_CONFIG, you'll be setting your session to "peer" mode. The default config generated by zenoh is enough.

In zenoh-pico you'd do something like:

z_config_default(&config);
zp_config_insert(z_config_loan_mut(&config), Z_CONFIG_MODE_KEY, "client");

As mentioned, you need to declare the connection to your zenohd. In zenoh-pico:

if (peer_locator != NULL){
                zp_config_insert(z_config_loan_mut(&config), Z_CONFIG_CONNECT_KEY, "tcp/my-cool-host-with-zenohd:7447");
}

If you are passing a config file, search for the config mode and endpoint connection keys and override there. Zenoh-kotlin seems to have an API for this as well in its examples.

Once you're able to connect to a ROS node data will flow, but you will have to serialize/deserialize your data with the appropriate ROS IDL type (and ROS 2 headers). See here for examples that will get you started.

I hope this helps out.