Posted by @alex-roba:
When a negotiation forfeit occurs and can not be resolved fast, the robots continue moving according to the conflict plan instead of stopping until the negotiation is resolved. This behavior poses a safety risk, as it could lead to collisions or unsafe operations in a shared environment. there should be a safety mechanism that stops all robots involved in a conflict when a negotiation forfeit occurs. The robots should remain stopped until the negotiation is successfully resolved.
Posted by @mxgrey:
I’ll provide some context for why the system behaves this way and how our view on this has evolved over time.
It was an intentional design choice very early on in the development of Open-RMF to not block robot movement when a negotiation fails. The following rationale all played a role in that decision:
- Open-RMF was originally envisioned as a system that supplements the on board navigation of AMRs, not as a system that strictly controls them. This vision was politically important to get buy-in from mobile robot vendors who were worried that Open-RMF would diminish the capabilities of their platforms.
- There was an expectation that certain kinds of traffic conflicts could be resolved by the AMRs themselves using their on-board navigation without Open-RMF interfering. If Open-RMF blocked the movement of the AMRs after a failed negotiation, then we would deprive the AMRs of the opportunity to resolve their conflicts through their built-in collision avoidance.
- Blocking due to a failed negotiation also posed the risk of unnecessary cascading delays for other robots whose schedules depend on the blocked robot.
- AMR vendors generally gave us assurances that their mobile robots had sufficient safety built into their hardware to prevent collisions from happening and to maintain a safe distance. Because of this, our expectation was that robots who were failing negotiations would eventually settle at some safe distance from each other, and then we could have them re-negotiate until a feasible plan is found.
Now that we’ve had some experience with deploying Open-RMF on a variety of platforms and in some challenging scenarios, our view on the above points has shifted. These are our observations:
- AMRs are generally not as safe as their advertising would have us believe. They often have blind spots or delayed reactions, especially to moving obstacles. Their emergency stop margins are often thin enough that dangerous collisions can occur despite the emergency stop being triggered.
- AMRs can only resolve their own traffic conflicts under very generous situations where they have a large amount of space to maneuver. The spaces where Open-RMF gets deployed will not always be so generous, so relying on the AMR’s built-in navigation can become a liability.
- Negotiations are hardest to resolve when robots are blocking each other face-to-face. It’s generally much easier (algorithmically) to find good negotiations ahead of time, when the conflicting robots are still far away from each other. This means the current behavior of allowing the robots to get close and then resolve the problem later is actually a liability that results is more delays than it prevents.
So overall we no longer stand by the assumptions that drove the original design. Unfortunately those assumptions are so heavily baked into the implementation that they cannot be removed without a total rewrite of the negotiation system. We are in fact actively working on that rewrite right now, but we don’t have a clear timeline for when it will be available to try. In the redesigned system, every change to a robot’s plan will seek consent from all other robots in the system before being approved by the fleet adapter. We’ll be opening a “request for comments” on the specification of the new system; I’ll be happy to tag you in that if you’re interested.
In the meantime, we introduced mutex groups into the current generation which should be manually inserted into navigation graphs in areas where negotiations are prone to fail. Mutex groups effectively disable the negotiation system in the regions where they’re used, in favor of very strictly marshaling robots one-at-a-time. There are some notable disadvantages to this, but by carefully using mutex groups in the hazardous areas and relying on the negotiation system elsewhere, you can usually get reasonable traffic behavior for the overall system.
Edited by @mxgrey at 2025-02-04T03:36:03Z
Posted by @alex-roba:
Thank you for your detailed response. I appreciate the insights provided.
Additionally, I was able to reproduce the issue of unnecessary wait in the office demo environment. For further reference, the details and discussion can be found here
https://github.com/open-rmf/rmf/discussions/567
Edited by @alex-roba at 2025-02-04T05:32:48Z