Posted by @rajgavhale52:
Hey all,
I have already developed a package of RMF using its core functionality and python biddings, My custom robot localized into the RVIZ with help of its TF, i.e position updates are through tf whereas navigation is through NAV2, i am NOT using a free_fleet as zenoh bridge is again contrain for me.
Now, I want to focus on navigation of robot through RMF and NAV2 so tell me the any of concern/ requiredment / need of package to implement it successfully
Along with that tell me the use of Fleet_manager in system?
Edited by @rajgavhale52 at 2025-03-28T08:54:18Z
Posted by @aaronchongth:
Hi @rajgavhale52, if you’d like to integrate RMF and Nav2 without free fleet, you will need to implement a fleet adapter based on your own requirements. You can refer to this as a starting point, GitHub - open-rmf/fleet_adapter_template.
We have a basic fleet adapter implemented with RMF + Nav2 directly, but only in simulation, ionic_demo/fleet_adapter_nav2 at main · gazebosim/ionic_demo · GitHub. Take note that this only works in simulation because we have all the nodes (nav2 + RMF) on the same host, and ROS 2 works relatively well within the same machine. Based on our experience integrating with multiple machines, communication might not be reliable over ROS 2, hence the proposed architecture of free_fleet which relies on the Zenoh router for network discovery and traffic.
Posted by @rajgavhale52:
But I’m using ROS2 Humble, easy_full_control seems to be not available in humble and I need to use Humble only, in such case what should I do?
Posted by @mxgrey:
The main branches of all the RMF repos (besides rmf_simulation and rmf_demos) are still compatible with humble. You can build those branches from source inside of your 22.04 Humble distro. Many users set up a docker image with this configuration.
The easy full control API isn’t available through the build farm because it’s a new feature that was released after Humble was released.
Posted by @Oussama-Dallali99:
Hi @rajgavhale52, if you’d like to integrate RMF and Nav2 without free fleet, you will need to implement a fleet adapter based on your own requirements. You can refer to this as a starting point, GitHub - open-rmf/fleet_adapter_template.
We have a basic fleet adapter implemented with RMF + Nav2 directly, but only in simulation, ionic_demo/fleet_adapter_nav2 at main · gazebosim/ionic_demo · GitHub. Take note that this only works in simulation because we have all the nodes (nav2 + RMF) on the same host, and ROS 2 works relatively well within the same machine. Based on our experience integrating with multiple machines, communication might not be reliable over ROS 2, hence the proposed architecture of free_fleet which relies on the Zenoh router for network discovery and traffic.
Hi everyone ! ,is it possible and feasible to use the Free Fleet without Zenoh/dds bridge ,and just use the RMW_ZENOH ?
Posted by @aaronchongth:
@Oussama-Dallali99 it is possible, but not necessarily feasible. A large advantage of the zenoh bridge is to help with namespacing various topics on the zenoh key expression level, instead of manually namespacing ROS 2 topics for each robot. If rmw_zenoh is used, users will need to set up each of their robots to have namespaced ROS 2 topics.
One of the key objectives of free_fleet is to require the least number of changes to an existing Nav1/Nav2 robot for the integration to work, so that users with existing and working standalone robots can drop in a bridge and make the integration work immediately, as opposed to manually re-configuring each robot’s navigation stack
Posted by @davecrawley:
Yes but isn’t that assuming that the robot is using DDS. What if you have a robot that is using Zenoh. Can you use keys to make this easy?
To quote from here https://www.researchgate.net/publication/373757741_Zenoh_Unifying_Communication_Storage_and_Computation_from_the_Cloud_to_the_Microcontroller#pf4
“As an example, a publisher could be defined for a key, such
as home/kitchen/sensor/C2O2, or for a set of keys, such as,
home/kitchen/sensor/* or home/kitchen/.
Symmetrically, a subscriber should be thought as a
sink for resources matching key expression. As an ex-
ample, a subscriber could be defined for a key, such
as home/kitchen/sensor/C2O2, or for a set of keys, such as,
home//sensor/”
Also Zenoh supports pretty much all available Topologies - so aren’t there clever things we can do with the topology to make this work well?
Edited by @davecrawley at 2025-04-09T15:24:35Z
Posted by @aaronchongth:
Hi @davecrawley!
Yes but isn’t that assuming that the robot is using DDS.
Yes the assumption is like that at the moment. We were first looking at supporting robots that were set up according to official documentation of Nav2 (and Nav1), hence the focus on DDS for now.
What if you have a robot that is using Zenoh. Can you use keys to make this easy?
Absolutely. I see that Namespace prefix support by DenisBiryukov91 · Pull Request #1792 · eclipse-zenoh/zenoh · GitHub got merged rather recently, I’ve not managed to try it yet. Theoretically, if I understand this feature correctly, instead of spinning up a Zenoh bridge, users will need a central Zenoh router, then start a Zenoh router on each robot with the correct discovery settings with the main one, and use a namespace to allow for differentiating all the key expressions coming in from different robots.
Regarding rmw_zenoh, I see that the namespace feature has been ported over just a few days ago. I’m not too sure yet what will the effects of namespacing key expressions be when it is used as an rmw client, whether or not it gets parsed properly as a namespaced ROS 2 topic, or will the K.E.<—>topic mangling be messed up. I’ll update here when I get the chance to try it out.