Question: Are there plans to support zenoh-pico?

[bjsowa]

Are you guys planning to also add middleware implementation based on the zenoh-pico library like in the archived version?

If not, could you please consider it?

I would love to try Zenoh as an alternative to eProsima's XRCE-DDS used in Micro-ROS.

[gavanderhoorn]

I'd also like to try this. Primarily to circumvent the 16 bit payload size limitation present in micro-ROS.

My plan was to wait for rmw_zenoh to stabilise a bit and then try to resurrect the previous Pico-based RMW (I'm not sure whether I'd have time to do that though).

[clalancette]

Are you guys planning to also add middleware implementation based on the zenoh-pico library like in the archived version?

Not at the moment, no. Right now we are just focused on getting it working with the full Zenoh library.

It may be possible to support zenoh-pico in the future, though that is not certain. We are using a lot of the new features of Zenoh and zenoh-c to support various parts of the RMW API, and zenoh-pico doesn't support many of them. There are some possible workarounds to supporting zenoh-pico, but they will have downsides (like a lot more network traffic). The other possibility is to extend zenoh-pico itself to support more of these features, but that has to be balanced with keeping zenoh-pico small.

In short, I think it will be a fairly large effort to support zenoh-pico, and we aren't planning on that in the near future. That said, if you'd like to look into it we'd be happy to entertain PRs in that direction.

[gavanderhoorn]

With rmw_zenoh now feature complete (as stated by @clalancette on Discourse): could someone from the Zenoh team comment on which features are lacking in Zenoh-Pico which would (still) be needed to make it possible to implement a rmw_zenoh_pico_c wire-compatible with rmw_zenoh_cpp?

[JEnoch]

I think only the Liveliness Tokens feature is missing.
With rmw_zenoh they are used to announce/retrieve all the ROS interfaces and thus create the ROS graph. And also by Services/Actions Clients to wait for discovery of the Server before sending a Request.

Actually, just for pub/sub it probably already works since I don't think the ROS graph is required for pub/sub communications.
That's assuming matching key expressions and encoding (CDR) are used. See for topic name to key expr mapping:

rmw_zenoh/rmw_zenoh_cpp/src/rmw_zenoh.cpp

Lines 82 to 88 in 93ba28e

	z_owned_keyexpr_t ros_topic_name_to_zenoh_key(const char * const topic_name, size_t domain_id)
	{
	const std::string keyexpr_str = std::to_string(domain_id) +
	"/" +
	rmw_zenoh_cpp::liveliness::mangle_name(topic_name);
	return z_keyexpr_new(keyexpr_str.c_str());
	}

Note that this might change with #171 which adds the type name in key expr.

[brandonho667]

Has this changed since for pub/sub? Using the sample talker which publishes to /chatter, debug output showed me the zenoh topic was

0/chatter/std_msgs::msg::dds_::String_/RIHS01_df668c740482bbd48fb39d76a70dfd4bd59db1288021743503259e948f6b1a18

Subscribing to the the above topic in zenoh-pico and running the ROS talker, the router debug shows

Declare subscription Face ...
Register router subscription <above topic name>

but the zenoh-pico subscriber doesn't receive any messages. Is there something I'm missing?

[yashi]

https://discourse.ros.org/t/reference-implementation-of-zenoh-pico-to-micro-ros/40750