Documentation / Integration with an existing Nav2 stack

[lucasl84]

Hi everyone,

I'm opening this discussion because I'm very confused as to how this project is supposed to be used. I've already built a multirobot solution using ROS2 and the Nav2 stack. Everything is working fine, I can move N robots around through RViz2.

Now the issue that I'm currently facing is that robots "collide" when they cross their paths. Moreover if I send a robot to a place and afterwards I send another robot to the same place, the robot that is approaching its goal will eventually try to push the robot that previously reached the very same goal. So to the point: given I have everything working, how do I integrate my existing stack with open-rmf?

Is there any documentation / tutorials on how to achieve this? I do understand that the demos are nice and all that if you want to try open-rmf from scratch, but the information I'm looking for (at least the places I've looked into) seems to be missing or non-existant.

Are there any plans to document this or at least to have a detailed guide on the things that need to be done in order to support an already existing multi-robot environment with Nav2?

Thanks,
Lucas.

[mxgrey]

The out-of-the-box solution for using Open-RMF with robots managed by Nav2 is to use free fleet.

The free fleet has fallen a bit behind in terms of what features of Open-RMF it supports, but @aaronchongth is actively working to get it up to date.

[lucasl84]

@mxgrey thanks for sharing that. Unfortunately nothing changes, the docs are really terrible and apparently they are way behind on ROS releases (being Galactic the latest currently supported, I'm currently on Jazzy as I was instructed to use the latest release). I can't believe that after so many months of work I spent with Nav2, making now the stack robot collision free will have to be a manual solution from scratch.

[mxgrey]

Sorry that you had a disappointing experience. Since this is a free open source project we don't always have opportunities within our budget to keep every piece of it as up to date as we'd like. Most of our users are system integrators who are working with proprietary APIs for their AMR platforms, so support for free fleet has languished more than we'd like as we've had to focus our attention elsewhere.

But the nice thing about open source projects is that anyone can contribute. I'm absolutely certain that any build issues you might be running into will be orders of magnitude easier for you to resolve than putting together your own multi-agent traffic management and task dispatching system from scratch. And if you were to work through those build issues then you'd have the opportunity to contribute the fixes upstream and be a hero to the whole community.

[aaronchongth]

hey @lucasl84, if you'd like to, you can give https://github.com/open-rmf/free_fleet/tree/easy-full-control a spin and provide some feedback on how the integration could work best. Please note that this is rather new and not fully tested on hardware yet.

With responsive_wait enabled, robots will be able to move out of their final destination's waypoint if it is in the way of another incoming robot with Open-RMF.

I can't believe that after so many months of work I spent with Nav2, making now the stack robot collision free will have to be a manual solution from scratch.

This is an interesting problem to have. By definition, the robot's collision detection should allow them to avoid unmoving robots (similar to static objects) even if Open-RMF is not involved. In the scenario you mentioned, the robots should at the very least be able to detect one another as dynamic or static obstacles, and if a waypoint is blocked, the navigation should just fail, instead of crashing into the other robot. My suggestion would be to first ensure that the robots can "see" each other as obstacles, and that can be achieved with either ultrasonic sensors or 3D cameras, this will allow the local planner to realize goals are unachievable.

[tomkimsour]

From what I have experienced. The integration with nav2 in simulation is complicated as namespaces does not seem to be handled properly by navigation2 stack.

[aaronchongth]

Hey @tomkimsour! You're right, it's not the best, especially with the spawning of robots and re-using robot descriptions, however nav2_bringup does have a nifty launch file now, unique_multi_tb3_simulation_launch.py, which shows an example of 2 turtlebot3s in the same simulation in separate navigation stacks.

You can also check out the multirobot sim section of the new easy-full-control branch of Free Fleet, https://github.com/open-rmf/free_fleet/tree/easy-full-control?tab=readme-ov-file#multiple-turtlebot3-world, for an example of how we plan to integrate nav2 with the newest features of Open-RMF.

[tomkimsour]

Thanks for sharing this. Regarding unique_multi_tb3_simulation_launch.py it does not work out of the box for me so I'm looking for other ways to do it but the approach you are taking in the easy-full-control branch of free_fleet looks like the approach I want to take as well. I will investigate this.

[aaronchongth]

Regarding unique_multi_tb3_simulation_launch.py it does not work out of the box for me so I'm looking for other ways to do it

that's unfortunate, I can't say for sure I'm very well versed with simulations + nav2, and I've had my fair share of issues, but the few gotchas I encountered were

• make sure that the GAZEBO_MODEL_PATH is pointing to where the tb3 model can be found
• running with the full simulation sometimes do get a little weird, I've had more luck running headless, and just with the 2 rviz2 windows
• using rmw_cyclonedds_cpp helps, and the usual ros2 daemon stop, ros2 daemon start, reboots, etc sometimes help too
• if you suspect your runtime setup could be polluted with binaries, you can try out distrobox too, to run an almost "clean" Ubuntu 24.04 setup

[tomkimsour]

Is the easy-full-control implementation meant to have only one server ? It's not a client-server like what free fleet used to be right ?
All you need to do is run the launch file starting the free_fleet_adapter and implement the execute_action in the nav2_robot_adapter. After that it's supposed to work for any robot ?

[aaronchongth]

Yup, instead of a standalone server funneling data to all the robots while working with RMF, the free_fleet_adapter will work directly with namespaced zenoh messages, provided by either a zenoh router or multiple zenoh bridges.

After that it's supposed to work for any robot?

In theory yes, but only if the robot and it's capabilities are configured properly for the fleet (check out the fleet config files), this is the configuration pattern we are inheriting from the easy-full-control implementation upstream.

We'll be fleshing out some of the more common actions (dock, undock, relocalize/change-map) in subsequent updates after more hardware testing