Open esteve opened 4 years ago
@kydos @JEnoch @Mallets can you assign this to me? I don't have perms. Thanks
@esteve a tagged version of zenoh-pico is now available (0.5.0.beta.5 at the time of writing this comment). You can use the tagged version for zenoh-pico
@esteve We make a prototype of the rmw_zenoh_pico and micro-ROS.
@k-yokoyama-esol: nice work :+1:
would this perhaps deserve a post on ROS Discourse?
Not many people will discover your comment here, under a 4 year old PR :)
@gavanderhoorn Thank you for replying.
would this perhaps deserve a post on ROS Discourse?
Yes. Of course. But I can't post yet because I've only been ROS Discourse a short time. Could you wait a few days? I'll link the topic URL to this issue after posting.
But I can't post yet because I've only been ROS Discourse a short time.
ah, ok. I thought there was only a limit to the amount of links new users could post.
Could you wait a few days? I'll link the topic URL to this issue after posting.
I'll be ok for a few days :)
I just wanted to make sure you get the attention this work deserves.
Just curious, what's the point of using Zenoh with microROS? If Zenoh stack is small enough to fit with MCUs, we can just use ROS 2 without microROS agent, no?
What am I missing?
(Don't get me wrong. It's indeed a nice work. But, I just feel like I'm missing something important.)
@gavanderhoorn My Discourse Trust Level has improved, so I'm posting now. https://discourse.ros.org/t/reference-implementation-of-zenoh-pico-to-micro-ros/40750
@yashi In our company, there are cases where we want to communicate with microcomputers and ROS. It seems that communicating with these IoT devices using Zenoh makes sense.
Zenoh's mesh network is powerful in environments with unstable connectivity, such as robots and mobility. Our implementation is currently only for Linux, but we think it can also be used with embedded modules that have wireless functionality.
@k-yokoyama-esol: if I understand correctly, the Micro XRCE-DDS Agent is no longer used with rmw_zenoh_pico
, correct?
If that's the case, I believe that would be why this makes sense @yashi.
@yashi , @gavanderhoorn
if I understand correctly, the Micro XRCE-DDS Agent is no longer used with rmw_zenoh_pico, correct?
Ah, Yes! Our suggestion is agentless system, so it can communicate with ROS directly. We use the micro-ROS build system for the rclc, rcl, rmw functions.
We use the micro-ROS build system for the rclc, rcl, rmw functions.
That's super! Thanks for the info, @k-yokoyama-esol !
Our suggestion is agentless system, so it can communicate with ROS directly.
certainly true, although Zenoh then 'requires' the router IIRC :)
Zenoh supports UDP multicast, so the router is not strictly needed
@gabrik Ideally, your comment is correct. However, the ROS community seems to be avoiding DDS via UDP communication for several reasons. https://discourse.ros.org/t/ros-2-alternative-middleware-report/33771
UDP multicast feature is disabled at rmw_zenoh. https://github.com/ros2/rmw_zenoh/blob/868b64ef3fd64e4f52d76f9933308791a915b6de/rmw_zenoh_cpp/config/DEFAULT_RMW_ZENOH_ROUTER_CONFIG.json5#L39
Therefore, in our environment, zenohd
needs to be enabled to register new sessions.
That's a depoyment detail, Zenoh uses UDP multicast on a completely different way compared to DDS, the amount of traffic when using Zenoh over UDP multicast is way lower than DDS.
That said depending on the use-case a router (or a peer for that matter) can bridge between microROS and the rest of the system, or UDP can be used to avoid SPoF.
I agree with you. It's not a technical problem but a philosophical one.
I want UDP multicast for rmw_zenoh
to be enabled.
Unless enabled, the proposed structure is necessary for Zenoh-pico to communicate with the current ROS system.
@k-yokoyama-esol as I said on the ROS discourse post (https://discourse.ros.org/t/reference-implementation-of-zenoh-pico-to-micro-ros/40750/2?u=esteve), so cool! :slightly_smiling_face:
I ended up adding support for zenoh-pico
in the first version of rmw_zenoh
(see https://github.com/esol-community/rmw_zenoh_pico/tree/main/rmw_zenoh_pico), but didn't close this ticket because I didn't add CI for it. Anyway, my approach was different to yours.
I made it so that rmw_zenoh_cpp
and rmw_zenoh_pico_cpp
shared as much code as possible, the zenoh-pico
API is compatible with the one from zenoh-c
, so there was no need to have an entirely separate rmw
implementation (except for things like requiring an address for the zenoh broker for zenoh-pico
, linking to the correct library, etc.), all shared code is in rmw_zenoh_common_cpp
.
I didn't use micro-ROS either, but the regular ROS stack, so there was no need for a micro-ROS agent (Edit: I see you're not using the micro-ROS agent either, only the micro-ROS build system). However, the microcontroller I used as a test had at least 1MB of flash memory IIRC, there may be ways to trim the size down, perhaps migrating parts of the code in rmw_zenoh
from C++ to C (e.g. replacing FastCDR with CycloneDDS' CDR library), but I didn't have time to investigate further.
Anyway, happy to see that you're working on this, let me know if I can help somehow.
I didn't use micro-ROS either, but the regular ROS stack, so there was no need for a micro-ROS agent (Edit: I see you're not using the micro-ROS agent either, only the micro-ROS build system).
yes, that is not always clear when someone says they're "using micro-ROS".
in reality it's typically more: using the rclc
implementation from the micro-ROS project, and perhaps a C-based RMW, which could mean rmw_microxrcedds
but doesn't have to be.
If you use rmw_microxrcedds
, you do need the Agent (currently, there is some (abandoned?) work towards P2P capability). Otherwise it's not needed, provided you use a compatible (de)serialiser (like the CDR implementations you mention @esteve).
@esteve Thanks for your reply. I also checked the ROS Discourse post, but I continue to discuss the issue on this page because many members are watching.
At first, we didn't have ideas for implementing rmw_zenoh_pico
when we started to develop it.
Our members have experience developing custom transport layers of micro-ROS.
So we decided to make rmw_zenoh_pico
based on rmw_microxrcedds
, replacing micro-XRCE-DDS functions.
As you say, our implementation could be more straightforward. It's the result of a bottom-up style of development. Considering that Zenoh-pico has fewer features than native Zenoh, the system structure and support ROS features must be optimized for embedded devices. Some rmw functions are not currently supported.
The next TODO is to update the version of Zenoh-pico (>=1.0.0) and check the communication on embedded MCUs. If you have a different approach to improvement, we can accept the changes.
I didn't use micro-ROS either, but the regular ROS stack
From my experience, rcutils was not ready for Zephyr at the time of Humble. Mainly it was filesystem and unix-realated things. Not sure how much improvement it's got since then, though.
Everything else in the micro-ROS was related to Micro XRCE-DDS.
So I'm kinda wandering how many micro-ROS stack components @k-yokoyama-esol really needed when he replaced DDS with Zenoh Pico.
This is all I needed with my micro-ROS-based system (+ components unique to my system, of course)
@yashi Could you see it? There are client-side packages for Zenoh-pico. https://github.com/esol-community/micro_ros_setup/blob/dad1d2e1b44a278f548cc4a55c3c7250eb39bfba/config/zenoh/host/client_host_packages.repos
We added the last two packages: Zenoh-pico and rmw_zenoh_pico
.
The modified package is only rmw_zenoh_pico
based on rmw_microxrcedds.
In addition, we don't support the RTOS platform now. The package dependencies should be checked.
Anyway, it is better to split the topic about constructing micro-ROS. This issue page should deal with packet compatibility and functionality of Zenoh-pico. If you live in Japan saying in your profile, we can communicate through the company's official channels.