For those of you that attended the ROSCon 2022 workshop and participated in the hands-on learning for Open-RMF, thank you for your participation and questions!! We learned with you! We now have the slides and materials ready to share.
For those that couldn’t make it but wish they did, here’s your second chance!
This was an 8-hour overview introducing the benefits, capabilities, architecture, and source code of Open-RMF (www.open-rmf.org), an open-source interoperability enabling platform. Specifically in this material, you will learn:
(1) the requirements, benefits and steps to build multi-fleet traffic maps,
(2) how to generate building simulation models from traffic map files, and then simulate fleets of robots in Gazebo using those models,
(3) how to use existing software adapters, or develop new adapters, to integrate your mobile robot fleets, doors, elevators and workcells, and
(4) how to visualize and and control your Open-RMF assets using RMF Web.
We hope the sharing is helpful in your learning journey and hope we get to collaborate with more and more teams to improve interoperability and grow together.
Can the routes/planning made in the traffic editor be used outside of the OpenRMF context? I’m wondering if they’re sufficiently decoupled to be able to be shared among other applications like Nav2 or its nested deeply within that system it wouldn’t be easy to share?
The motion planning and traffic negotiation algorithms are implemented in rmf_traffic which is relatively low on dependencies and intended to be useful independently from the overall RMF system. The traffic editor application can also be used independently from the rest of RMF, and provides the easiest way to specify traffic graphs that can be loaded and used by rmf_traffic.
In fact, we do have a roadmap that relates directly to Nav2. The outline of that roadmap is something like this:
Implement free space planning for the traffic negotiations so we no longer rely on predefined traffic graphs (but predefined traffic graphs would continue to be an option for cases where they’re preferable).
Use that implementation to write a Nav2 plugin that can participate in traffic negotiation. Navigation around obstacles that have predictable movements is a free bonus from having this.
Make an optional bridge for the Nav2 plugin to trivially integrate into an RMF traffic negotiation system.
With that plan, Nav2 users would get to have navigation around moving obstacles and traffic deconfliction with all other Nav2 robots that use the plugin, and perhaps the ability to evade conflicts with Nav2 robots that don’t use the plugin. Additionally any robot using the plugin would automatically be integrated with an RMF traffic system simply by turning on the bridge, which means they’ll benefit from traffic deconfliction against any robot that has RMF integration, even if those other robots are not running Nav2 or are not even ROS[2] robots.
That roadmap seems very reasonable. Let me know if there are any points of collaboration that are sensible.
W.r.t. the navigation routing, its in my likely 2023 plans to build something like this for Nav2 to take in arbitrarily defined route graphs for navigation (e.g. could be handle-selected like what RMF has, or generated from a PRM, or from some automatic algorithm based on voronoi diagrams/visibility graphs/whatever more modern methods exist) to augment Nav2 to have the capability of using pre-defined graphs for planning in (1) exceptionally large spaces, (2) where repeatable behavior / lanes are desirable, and (3) in non-planar environments. This would be a parallel task server to the planning server which computes paths based on free-space in the occupancy grid. For (1) that requires no global costmap at the massive environment scale (though perhaps a large, but considerably smaller one to do rolling-global planning along the route), (2) gives option for lanes and repeatable behavior, (3) allow to define routes that go up inclines or in outdoor non-planar environments without needing to have a global traversibility model (though still need a local one - to be a logical next project).
There seems to be a great deal of overlap so I wouldn’t want to reinvent anything we can share but I am looking to make something robot-centric versus fleet-centric – if that distinction makes sense. It would live as an alternative planning model within the navigation system rather than being a task defined from the fleet manager / autonomy system. The API would still say go from A->B, but now routing from A->B via this navigation graph rather than free-space planning.
While I think there are subtle changes in the requirements and implementation challenges between those methods, the core (an editor, a file format, a navigation graph solution solver) are shared resources if they can be made independent and general enough for both applications. Perhaps it would be good to get on a call at some point in the next few weeks and chat?
There seems to be a great deal of overlap so I wouldn’t want to reinvent anything we can share
Absolutely agree, I think there’s a huge amount of opportunity for collaboration here.
but I am looking to make something robot-centric versus fleet-centric
To clarify a bit on how rmf_traffic works, it’s very similar to conflict-based search in that it has two “layers” of planning: (1) a super fast single-agent motion planner that can plan around moving obstacles, (2) a higher level multi-agent planner that iterates on calls to the single-agent planners. One thing that makes RMF’s approach a bit different from conventional conflict-based search is that the second layer is spread across a distributed system instead of being centralized, so individual agents can “negotiate” on their own behalves.
As a result, there are many tools within rmf_traffic and the traffic editor that are very suitable for applying to a single robot and aren’t directly related to the overall fleet management.
It would live as an alternative planning model within the navigation system rather than being a task defined from the fleet manager / autonomy system. The API would still say go from A->B, but now routing from A->B via this navigation graph rather than free-space planning.
This is exactly how I’d like to implement the plugin that I’m proposing. One question that would be interesting is whether incoming requests will be able to specify which strategy to use - free space or fixed graph - on a request-by-request basis. That could be an interesting feature for setups where the robots have access to both the occupancy/cost information and a fixed graph. I apologize that I’m not yet familiar enough with Nav2 to know if that would require an API change. Maybe the behavior_tree parameter could be used to select between the two strategies?
Perhaps it would be good to get on a call at some point in the next few weeks and chat?
Absolutely! We can figure out a time offline to minimize noise on this thread.
On the topic of traffic editing, I’ll mention that we’re currently developing the RMF Site Editor as a replacement for the rmf_traffic_editor and as a foundation for others to optionally extend for customized site+traffic editing, visualization, and simulation. It’s not completely ready to replace the traffic editor yet, but it’s on track to be ready in ~1-2 months from now. In the meantime you can see a preview that can run in your web browser by visiting this link.
Huh, interesting. I would have thought you’d want to prescribe the route centrally which would have the navigation-graph route (I don’t have precise language for this, I iterate between route graph, navigation graph, etc) as a input to the navigation system.
EZ-PZ and that kind of transition is already supported today.
Hello, I participated workshop. It is great time to use rmf in myself.
I am developing traffic management. After this workshop, I wanna use my management with rmf.
I have some questions about rmf_traffic.
How do you usually evaluate traffic management (cheduling and negotiating mobile robot traffic)?
How many robots can the RMF system traffic manage?
How long does it take to calculate 100 robots for traffic management?
How do you usually evaluate traffic management (cheduling and negotiating mobile robot traffic)?
Is this question asking “How do you solve traffic management problems” or is it asking “How do you decide if the way you’re solving traffic management problems is good / How do you compare the quality of your approach against other options?”
How many robots can the RMF system traffic manage?
This is presently a somewhat open question and not a simple one to give a firm response to. I can say that the traffic negotiation system is not as sensitive to the number of robots as it is sensitive to the frequency of traffic conflicts and how difficult it is to find solutions to those conflicts. Factors like traffic flow rules, numbers of intersections, and density of simultaneously operating robots will be more consequential for performance than simply the number of robots. This is a question that we’re interested in investigating rigorously as time and resources permit, but for right now we’re more focused on testing RMF systems for suitability on specific real-world use cases and addressing performance issues as they appear.
How long does it take to calculate 100 robots for traffic management?
This question seems to assume that RMF uses a centralized planning system and solves the entire multi-agent planning problem upfront, but that’s not how RMF actually works. RMF’s traffic system is distributed, so individual robots (or fleets) plan their motions for themselves and then conflicts are identified on the fly. When a conflict is detected, the conflicting agents (or their RMF adapters) negotiate a mutually acceptable solution. It’s extremely improbable to have a single 100-robot conflict, at least in the use cases that we’ve encountered so far. Even if a scenario has many robots, the traffic conflicts can usually be segmented as numerous separate conflicts happening between 2-3 robots rather than a single conflict between all the robots. I think a scenario involving 100 robots that all simultaneously conflict together would be outside the current scope of RMF and would be better to solve with a constrained, centralized, application-specific multi-agent path finding server.
That being said, I would be very interested in RMF supporting strategies that can manage hundreds of high-density robots. We’ve thought about providing a centralized MAPF server as one integration option which would be particularly helpful for that kind of scenario, but it hasn’t been relevant to any of our funded use-cases yet.
Thank you for answer!! With your answer, I understand that RMF traffic goal is suitability on specific real-world use case.
It’s extremely improbable to have a single 100-robot conflict, at least in the use cases that we’ve encountered so far. Even if a scenario has many robots, the traffic conflicts can usually be segmented as numerous separate conflicts happening between 2-3 robots rather than a single conflict between all the robots.
Factors like traffic flow rules, numbers of intersections, and density of simultaneously operating robots will be more consequential for performance than simply the number of robots.
Also, You gave an appropriate answer to a slightly wider question. It seems to be more important what factors to evaluate rather than the number of robots.
Is this question asking “How do you solve traffic management problems” or is it asking “How do you decide if the way you’re solving traffic management problems is good / How do you compare the quality of your approach against other options?”
Yes. I wanna ask those. “How do you decide if the way you’re solving traffic management problems is good / How do you compare the quality of your approach against other options?” When comparing your system with other traffic management, I am curious what evaluation criteria you use.
Among your answers, it was interesting that the high level multi-agent planner is running on each robot rather than the server. Are there any papers on this?
To clarify a bit on how rmf_traffic works, it’s very similar to conflict-based search in that it has two “layers” of planning: (1) a super fast single-agent motion planner that can plan around moving obstacles, (2) a higher level multi-agent planner that iterates on calls to the single-agent planners. One thing that makes RMF’s approach a bit different from conventional conflict-based search is that the second layer is spread across a distributed system instead of being centralized, so individual agents can “negotiate” on their own behalves.
slides are now available here and the 
repo has been updated here. 