Zenoh is a new communication middleware that ZettaScale has developed.
At eSOL, we have been porting Zenoh-pico to micro-ROS.
Zenoh-pico is Zenoh’s implementation for microcontrollers.
This post is the announcement of the prototype of Zenoh-pico adaptation to micro-ROS.
Although it is still experimental, we confirmed it would work on the generic (Linux) or Raspbian platforms of micro-ROS.
Ideally, we would have liked to include Zenoh in the transport specification.
However, we treated it as an RTOS equivalent since Zenoh can select TCP, UDP, or serial.
This Zenoh-pico and micro-ROS system is assumed to communicate with “rmw_zenoh” on ROS. It is set as an environment variable, RMW_IMPLEMENTATION.
They can communicate directly with rmw_zenoh; the structure is just agent-less, like using embedded RTPS.
You can use it as a reference implementation. It would be even better if the ZettaScale and micro-ROS communities could discuss it.
Note:
As the previous post was from a personal account, I reposted it from the company account.
So cool! I implemented support for zenoh-pico about four years ago for the first version of the rmw_zenoh implementation, you can still find it in the archived branch of rmw_zenoh
The advantage of my implementation is that it shares as much code as possible with the regular rmw_zenoh, so it should be easier to maintain and keep up with any improvements in rmw_zenoh.
I didn’t need to use micro-ROS at all, I got the whole ROS 2 stack running on a microcontroller running Zephyr (and NuttX? I can’t remember). I can’t remember the specs for the microcontroller, I must have been an STM32 and I’m pretty sure it had at least 1MB of flash memory.
Anyway, really cool to see support for zenoh-pico in ROS! Let me know if there’s anything I can help with, I had a bunch of ideas on how to improve it, but I don’t know if they would work with the current rmw_zenoh, though.
The micro-ROS and the core ROS 2 stack are basically the same.
micro-ROS builds core ROS 2 packages for a wide range of microcontrollers and RTOS, with the following differences:
We do not build rclcpp, instead, we provide rclc as a user API to ease integration with C environments, non-POSIX threading models and deterministic execution.
Some utilities such as file system access, logging, or tracing are unavailable due to embedded constraints in targets.
Those design decisions might have been made differently if the target had been a beefy RTOS/toolchain/environment such as Zephyr or Nuttx, instead, micro-ROS not only supports those two but many more, even bare metal environments.
From my point of view, the difference between core and whole ROS 2 stack is packages above the user API layer (rclcpp, rclc, rclpy…) such as Nav2, MoveIt or control packages, which cannot be directly built for embedded targets.