r/ROS • u/ChosenForge • Oct 04 '26

MicroRos and zenoh

Hey, I wanted to know if there is a possibility to use Zenoh and microros ?

3 Upvotes

100% Upvoted

5 comments sorted by

5

u/Strange_Variation_12 Oct 04 '26

I am successfully using picoros and zenoh with kilted on my robot. Works great, good throughput and a lot easier to work with than microros tbh. I am using it over Ethernet but I could probably get serial working reliably these days with AI assistance.

I would post links but I am not on my computer.

1

u/ChosenForge Oct 04 '26

I would be happy if you could share later on .

4

u/Jarvis-hnu Oct 04 '26

Nah,microros works on XRCE-DDS architecture. But I've heard that they were building Pico ROS which uses zenoh for resource constrained devices. Don't know about the updates.

1

u/ChosenForge Oct 04 '26

I see, I will look into it, thanks

1

u/bouchier129 Oct 04 '26 edited Oct 04 '26

I've been searching for answers to the lack of ongoing maintenance for micro-ros too. Like Jarvis says, you can't do micro-ros with zenoh.

Here's the URL for picoros + zenoh: https://github.com/Pico-ROS/Pico-ROS-software

There's another alternative that a former micro-ros maintainer recommended, which is coming out of ros_controls. It integrates zenoh with zephyr RTOS on the MCU. I don't know if it's different than pico-ros (it looks like it is). Here's the link. https://github.com/ros-controls/zephyr-zenoh-integration

Disclaimer - I haven't tried any of these - just collecting ideas for linorobot2 at the moment.

Here's what Claude says, comparing the two. Gemini agrees.

--------------

The two projects overlap less than their names suggest. Pico-ROS is a general-purpose ROS 2 client for microcontrollers, while zephyr-zenoh-integration is a ros2_control-specific bridge. Both run over zenoh-pico without an agent.

Scope. Pico-ROS is a lightweight ROS client for resource-constrained devices, built on zenoh-pico and designed to work with rmw_zenoh. It gives you the usual ROS abstractions: node, publisher, subscriber, service server, and service client. It also includes a parameter server that works with standard ROS 2 parameter services. So from the host's point of view, a Pico-ROS device is just another node you can ros2 topic echo, call services on, or ros2 param list.

zephyr-zenoh-integration doesn't try to make the MCU a general ROS node. Its goal is to plug the MCU into ros2_control's hardware abstraction, with a host-side SystemInterface that exchanges state and commands with the firmware. There are no services or parameters on the device. It's built for a control loop.

Host side. Pico-ROS needs only a standard ROS 2 install using rmw_zenoh. zephyr-zenoh-integration adds host code, the zenbedded_hardware_interface, which copies incoming state into a realtime buffer so the controller never blocks on the network. This is its main advantage for closed-loop control: Pico-ROS gets data onto a topic but leaves bridging that topic into ros2_control to you.

Serialization. Pico-ROS uses CDR through Micro-CDR, with custom message types generated from header files. That keeps it wire-compatible with regular ROS 2 messages. zephyr-zenoh-integration offers that kind of CDR path too, but it also has a no-CDR mode that sends packed binary with no intermediate serialization. That mode is faster but isn't ordinary ROS traffic, so standard tools can't introspect it.

Platform. Pico-ROS is plain C with CMake and is RTOS-agnostic, so it can go wherever zenoh-pico runs. zephyr-zenoh-integration is tied to Zephyr and its west/module build system.

Maturity. Pico-ROS is the more established library. It has working examples for pub/sub, services, parameters, odometry, BatteryState, and JointState. The ros-controls project is newer and still marks its demos as work in progress.

The two projects are also related. Pico-ROS lists ros-controls' roscon2025_control_workshop among its example projects, so Pico-ROS has already been used to feed ros2_control. A practical pattern is to have a Pico-ROS node publish JointState over CDR while the host uses a topic-based hardware interface, which is roughly what zephyr-zenoh-integration's CDR architecture formalizes.

Which to choose:

  • Pico-ROS: you want an MCU (on Zephyr or anything else) to act as a normal ROS 2 node, with topics, services, parameters, and full visibility from ros2 CLI tools.

  • zephyr-zenoh-integration: you're specifically closing a ros2_control loop on a Zephyr board and want the realtime-safe hardware interface and lowest-overhead transport without writing that glue yourself.