Integrating ROS 2 with microcontrollers when using Zenoh

Embedded
,
1

Continuing the discussion from Reference implementation of Zenoh-pico to micro-ROS:

This is a post asking about the best way to go forward. We are working on robots that have a couple of different architectures:

1: One or several on-robot Single-Board Computers for navigation, Image processing, etc., and one or several microcontrollers (usually some ESP32 variety) for low-level motor control, safety, etc., connected through serial.

2: A purely microcontroller-powered robot that is managed through WiFi from a host.

In both cases, we have ROS 2 on the SBCs / hosts and micro-ROS on the microcontroller. We developed this framework to modularize the micro-ROS development:

All this work over DDS/XRCE-DDS in the classic way. Now we are trying to migrate to Zenoh as our RMW, as it would help a lot with our use cases (control over WiFi, remote cloud access…). The ROS 2 side change is straightforward enough, but I am a bit stumped on the best way to migrate our microcontroller code.

From the discussion in the linked topic, it seems there are only two feasible and “clean” methods to link an ESP32 to ROS 2 infrastructure when using Zenoh:

  1. Integrate Zenoh-pico as the middleware inside micro-ROS. PRO: allows to keep (some?) of the micro-ROS API and thus user code. CON: Sounds scary, high risk, and probably too complex an endeavour for us.

  2. Integrate ESP32 code directly against Zenoh-pico. PRO: few moving parts. CON: unclear how complex it is to translate raw Zenoh-pico to RMW concepts (if too complex, perhaps the right place is inside Micro-ROS?)

An alternative is to just keep micro-ROS as is and link its agent to the rest of the ROS 2 application through the DDS-Zenoh gateway. PRO: no rewritting is needed. CON: ugly, does not help with the microcontroller-WiFi-host use case.

Any input, comments, or ideas are welcome.

Jorge

2

We’ve just run in the same issue, just from the other side. We started in Gazebo on Zenoh and then my colleague finished the MCU code and we figured we have to give up Zenoh. What a pain!

What’s that? Where does it grow? =)

1 Like
3

Aghhh, I meant bridge, not gateway. :person_facepalming:

4
  1. Integrate ESP32 code directly against Zenoh-pico. PRO: few moving parts. CON: unclear how complex it is to translate raw Zenoh-pico to RMW concepts (if too complex, perhaps the right place is inside Micro-ROS?)

A community member was looking into this ROS2 Topic list not showing zenoh-pico nodes · Issue #580 · ros2/rmw_zenoh · GitHub so perhaps there is an opportunity to collaborate?

1 Like
5

Just thought to mention Service interoperability with FastRTPS · Issue #184 · ros2/rmw_cyclonedds · GitHub here.

The system configuration described by @xopxe is another example where we – as implementors/designers of (sub) systems – are not always in total control and can’t always dictate which specific RMW a (sub) set of nodes in a system should use.

Zenoh is of course not DDS-based, so not all of Service interoperability with FastRTPS · Issue #184 · ros2/rmw_cyclonedds · GitHub applies here, but rmw_zenoh does use CDR for (de)serialisation (eprosima::fastcdr even), so standardised (de)serialisation at the “ROS level” could help.

1 Like
6

That’s great! From what I’ve seen, the problem is currently far from solved, but work is underway.
Some conclusions:

  • The main complexity is in mapping some RMW concepts to Zenoh (like the ROS graph)
  • The zeno-rmw people are unlikely to work on Zenoh-pico support directly, but will help people (as in the linked post)
  • There’s a prototype micro-ROS - Zenoh-pico platform, but running over Linux. It might be interesting to try to add support for bare metal.