[BUG] Protocol Version Mismatch: zenoh-pico (Protocol v9) rejected by ROS 2 Rolling rmw_zenoh_cpp (v1.0.0)

[ShahazadAbdulla]

Description:
Currently, the zenoh-pico submodule integrated into Pico-ROS uses an outdated protocol version. When attempting to interface an ESP32 running Pico-ROS with a host machine running ROS 2 Rolling (which uses rmw_zenoh_cpp v1.0.0), the host router rejects the topic declarations and drops the connection, causing the ESP32 to crash.

Steps to Reproduce:

Flash the ESP32 with the standard Pico-ROS publisher/subscriber example.

Start the host router on ROS 2 Rolling: ros2 run rmw_zenoh_cpp rmw_zenohd

Observe the host rejecting the connection with an unknown scope error.

The ESP32 lease timer expires (15 seconds), triggering a FreeRTOS spinlock panic.

Root Cause (From Trace Logs):
Running the host router in RUST_LOG=trace reveals the handshake failure:
Received:

2026-04-10T13:27:02.256321Z TRACE acc-0 ThreadId(04) zenoh_transport::unicast::establishment::accept: Establishment Accept InitSyn: udp/[::ffff:192.168.240.53]:7447 => udp/[::ffff:192.168.240.135]:58522. Received: TransportMessage { body: InitSyn(InitSyn { version: 9, whatami: Client, zid: b7f02a488965714228bb54147feeefb7, resolution: Resolution(10), batch_size: 2048, ext_qos: None, ext_qos_link: None, ext_shm: None, ext_auth: None, ext_mlink: None, ext_lowlatency: None, ext_compression: None, ext_patch: PatchType(1) }) }

The host rmw_zenoh_cpp expects the newer Zenoh protocol, fails to parse the ROS 2 CDR scope dictionaries, and terminates the UDP session.

Expected Behavior:
Pico-ROS should update its zenoh-pico submodule to align with the current Zenoh 1.0.0 release used by ROS 2 Jazzy/Rolling, or explicitly document that it only supports older RMW versions.

[g4sp3r]

Hi @ShahazadAbdulla. I synced my fork of zenoh-pico with mainline (still have some commits from eclipse-zenoh/zenoh-pico#1126 that we need in our system). Updated Pico-ROS to point to new submodule version.
Hope that fixes your issue.

[ShahazadAbdulla]

Hi @g4sp3r ,

Update on testing with ESP-IDF v5.2 and ROS 2 (Humble & Rolling)

In the recent update bumping the zenoh-pico submodule to v1.0.0. I recently ran an extended diagnostic on an ESP32 over Wi-Fi (UDP) to evaluate the stability of the new version.

While the submodule bump successfully resolved the initial connection panics (unknown scope 3), the wrapper currently exhibits several critical failures across the transport and ROS 2 abstraction layers when tested against modern ROS 2 distributions.

1. ESP-IDF CMakeLists.txt Incomplete Integration:
   The component fails to build out of the box for ESP-IDF. The CMakeLists.txt within the ESP-IDF component directory does not explicitly link the required Zenoh-Pico source files or properly configure the background executor flags required by v1.0.0, necessitating manual patching to compile the project.

2. ROS 2 Humble Incompatibility (Hardcoded RIHS Hashes):
   The updated library structures (picoros_publisher_t) now include the .rihs_hash field to comply with ROS 2 Iron/Rolling type hashes.

   The Failure: If tested against a ROS 2 Humble host, Zenoh strictly drops the packets due to string mismatch. The ESP32 formats the key as 0/ping/std_msgs::msg::dds_::Int64_/RIHS01..., while Humble expects 0/ping/std_msgs::msg::dds_::Int64_.

   Note: We successfully bypassed this specific layer by switching our host entirely to ROS 2 Rolling as in the backward compatibility is bad with rmw_zenoh_cpp too.

!IMPORTANT
3. Pthread Starvation and 20-Second Lease Timeouts:
Even when perfectly aligned with a ROS 2 Rolling host, the Zenoh session forcefully drops every 10 to 20 seconds.
The underlying ESP-IDF POSIX wrapper fails to properly initialize the Zenoh-Pico background thread, indicated by these constant warnings on the ESP32:

W (36961) esp_pthread: pthread_condattr_init not yet implemented (0x3ffba960)
W (36961) esp_pthread: pthread_condattr_setclock: not yet supported!

Because the background thread stalls, the ESP32 fails to send Keep-Alive/Heartbeat packets. The router logs explicitly show the session opening, declaring topics, and then expiring exactly 10-20 seconds later due to lease timeout:

# Session Opens
2026-04-17T13:44:45.549088Z DEBUG acc-0 ThreadId(04) zenoh_transport::unicast::establishment::accept: New transport link accepted from ef4ca... to 9733f...: TransportLinkUnicast { link: Link { src: udp/10.115.50.53:7447, dst: udp/10.115.50.135:57980 ... }

# Topics Declared
2026-04-17T13:44:45.567920Z DEBUG rx-2 ThreadId(15) zenoh::net::routing::dispatcher::interests: Face{19, ef4ca...} Declare interest 3 (0/pong/std_msgs::msg::dds_::Int64_/RIHS01_8cd104...)

# Exactly 20 seconds later: Router kills the starved connection
2026-04-17T13:45:05.776677Z DEBUG net-0 ThreadId(03) zenoh_transport::unicast::universal::transport: [9733f...] Closing transport with peer: ef4ca...
2026-04-17T13:45:05.776822Z DEBUG net-0 ThreadId(03) zenoh::net::routing::dispatcher::face: Face{19, ef4ca...} Close
2026-04-17T13:45:05.776956Z DEBUG net-0 ThreadId(03) zenoh::net::routing::dispatcher::resource: Unregister resource 0/ping/std_msgs::msg::dds_::Int64_/RIHS01_8cd104...

4. Deprecated Liveliness Tokens (Ghost Node):
   By utilizing a manual publisher loop to force UDP packets ([PULSE]) and using zenoh-browse, we confirmed that raw Base64 payload data (AAEAAAAAAAAAAAAA) successfully reaches the Host.

However, ros2 topic list remains completely empty. The router logs reveal that Pico-ROS is attempting to announce its nodes using a deprecated ROS 2 Liveliness Token syntax (@ros2_lv/...):

2026-04-17T13:44:25.189855Z DEBUG rx-1 ThreadId(07) zenoh::net::routing::dispatcher::token: Face{18, ef4ca...} Declare token 4 (@ros2_lv/0/a55d4c6d4b5bce1bbfe6c6f224a14cef/0/11/MP/%/%/picoros_reflector/%pong/std_msgs::msg::dds_::Int64_/RIHS01_8cd1048c2f186b6bd9a92472dc1ce51723c0833a221e2b7aecfff111774f4b49/::,:,:,:,,)

Modern rmw_zenoh_cpp fails to parse this older dialect, rendering the ESP32 a "ghost node" to the ROS graph.

Conclusion:
While the transport layer update to v1.0.0 allows for brief UDP handshakes, the library currently cannot maintain a stable session due to ESP-IDF threading starvation, and its internal ROS 2 metadata generation is structurally incompatible with modern distributions (Humble/Rolling).

[g4sp3r]

1. Yes examples and idf-component were not yet updated with the new submodule point and glob of new zenoh-pico sources. Fixed now.
2. Humble is not supported currently. According to rmw_zenoh_cpp humble docs the format should be .../<type>/TypeHashNotSupported/<qos> . We could provide a compile configuration for that but I am afraid some other incompatibilities will also come up.
3. Check esp32-joystick example core panic after 20s. picoros-examples#1, it sounds very similar. Did you configure Z_TRANSPORT_LEASE 60000 and Z_TRANSPORT_LEASE_EXPIRE_FACTOR 2 in your zenoh-pico/include/zenoh-pico/config.h? Those are default values for rmw_zenoh.
4. The @ros2_lv/... prefix and field order are identical across all versions of rmw_zenoh design doc and should work. I don't see any problem in the log line you posted. Can you be more specific, what is "Modern rmw_zenoh_cpp" an where is the incompatibility with "older dialect"?

[ShahazadAbdulla]

Hi @g4sp3r ,

Thanks for the help.I changed the config.h settings to

Z_TRANSPORT_LEASE 60000 
Z_TRANSPORT_LEASE_EXPIRE_FACTOR 2

and it successfully got the 60s lease.

I am trying to run a simple ping-pong reflector to test high-frequency control loops (100Hz up to 1000Hz). We expect packets to drop at high speeds (which is what I want to benchmark), but I am running into two weird issues and wanted to ask if I'm doing something wrong.

1. The ROS 2 Graph and DDS Types
   ros2 topic list was empty on my ROS 2 Rolling host, so I turned on RUST_LOG=trace in the router. I noticed that the resource registers successfully, but the type has dds_ in the middle of it:

2026-04-18T14:50:36.067148Z DEBUG  rx-1 ThreadId(07) zenoh::net::routing::dispatcher::resource: Register resource 0/pong/std_msgs::msg::dds_::Int64_/RIHS01_8cd1048c2f186b6bd9a92472dc1ce51723c0833a221e2b7aecfff111774f4b49

Is this ::dds_:: part why modern ROS 2 can't see the topics?

2. Connection Drops & pthread warnings
   When the ESP32 boots up, I get these warnings at first:

W (13560) esp_pthread: pthread_condattr_init not yet implemented (0x3ffc9750)
W (13560) esp_pthread: pthread_condattr_setclock: not yet supported!

If I constantly send data from the ESP32, the connection stays alive perfectly. But if I just leave the node waiting for incoming pings, the router drops the connection after exactly 60 seconds with this error or after the first keep alive message the second one wont be reaching or like that:

2026-04-18T14:48:19.727158Z DEBUG  rx-1 ThreadId(07) zenoh_transport::unicast::universal::link: RX task failed: udp/10.58.15.53:7447 => udp/10.58.15.135:56559:TransportLinkUnicastConfig { direction: Inbound, batch: BatchConfig { mtu: 2048, is_streamed: false, is_compression: false }, priorities: None, reliability: None }: expired after 60000 milliseconds at /home/buildfarm/.cargo/git/checkouts/zenoh-cc237f2570fab813/b81e253/io/zenoh-transport/src/unicast/universal/link.rs:292.

Is the esp_pthread warning breaking the background keep-alive task?

Here is the exact code I'm running on the ESP32. Am I missing an executor spin or something, or is Pico-ROS not meant for this kind of high-frequency loop setup?

#include <stdio.h>
#include <stdint.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_system.h"
#include "esp_wifi.h"
#include "protocol_examples_common.h"
#include "picoros.h"
#include "picoserdes.h"

#define LOCATOR "udp/10.58.15.53:7447"
uint8_t pub_buf[128];

picoros_interface_t ifx = { .mode = "client", .locator = LOCATOR };
picoros_node_t node = { .name = "esp32_reflector" };

picoros_publisher_t pub_pong = {
    .topic = {
        .name = "pong",
        .type = ROSTYPE_NAME(ros_Int64),
        .rihs_hash = ROSTYPE_HASH(ros_Int64),
    },
};

void ping_callback(uint8_t* rx_data, size_t data_len)
{
    int64_t timestamp_msg = 0;
    if (ps_deserialize(rx_data, &timestamp_msg, data_len) > 0) {
        size_t pub_len = ps_serialize(pub_buf, &timestamp_msg, sizeof(pub_buf));
        picoros_publish(&pub_pong, pub_buf, pub_len);
    }
}

picoros_subscriber_t sub_ping = {
    .topic = {
        .name = "ping",
        .type = ROSTYPE_NAME(ros_Int64),
        .rihs_hash = ROSTYPE_HASH(ros_Int64),
    },
    .user_callback = ping_callback,
};

void picoros_task(void * arg)
{
    while (picoros_interface_init(&ifx) == PICOROS_NOT_READY){
        vTaskDelay(1000 / portTICK_PERIOD_MS);
    }
    vTaskDelay(1000 / portTICK_PERIOD_MS); 

    picoros_node_init(&node);
    picoros_publisher_declare(&node, &pub_pong);
    picoros_subscriber_declare(&node, &sub_ping);

    while (1) {
        vTaskDelay(1); // Watchdog yield
    }
}

void app_main(void)
{
    ESP_ERROR_CHECK(esp_netif_init());
    ESP_ERROR_CHECK(esp_event_loop_create_default());
    ESP_ERROR_CHECK(example_connect()); 

    xTaskCreatePinnedToCore(picoros_task, "picoros_task", 8192, NULL, 5, NULL, 1);
}

[g4sp3r]

1. dds_ part was needed in ROS Jazzy. I don't know if format changed in Rolling but it is now hard-coded in example_types.h generated with tools/type-gen on Jazzy branches of message repositories so you could change it if it's a problem. Important for graph are liveliness expressions ("@ros2_lv... ") so you need to check for those in the router logs and see if there are some errors reported.
2. Not sure about the state of ESP32 zenoh-pico port, I am guessing it's coming from system.c. Maybe the lease task dies. That would explain why ESP32 doesn't send any keep-alive messages and the link is closed by router, but is kept open when you send messages. Try running ESP32 with -DZENOH_DEBUG=3 and -DPICOROS_DEBUG=1 and see if you get any more info from zenoh-pico.

Code looks fine on quick check. Maybe start with 1Hz and then ramp up.

[ShahazadAbdulla]

1, I have changed the environment to ROS2 Jazzy and it worked, got the topic name to be shown in ros2 topic list and conducted the benchmark. (Will test this one more time with a clean ROS2 rolling docker pull and will give the conclusion)

2, The lease task is running properly in the same code without any edits.

Will update with final findings and close the issue soon.

Thanks for your time again.