There have been some really great and accurate points raised by both @chfritz and @gbiggs .
As @chfritz pointed out, in wide open spaces the on-board navigation will provide the most value in terms of avoiding unexpected obstacles, which in an airport may include humans, luggages, small passenger vehicles, wheelchairs, etc. While Open-RMF manages traffic via discrete graphs, it is specifically designed to allow robots to deviate from those graphs as needed to get around obstacles. We’ve seen them do this quite effectively in the Changi Airport deployment.
As @gbiggs pointed out, airports will have chokepoints like narrow corridors in the backrooms where the robots get charged. There may be doorways that the robots need to pass through on the way to their tasks. These regions may need some sensitive traffic control to prevent the robots from getting jammed up, even if they have on-board obstacle avoidance. There may be secure doors that require a specific protocol to use, or you may need the robots to use elevators. These are the places where Open-RMF will help the most.
Now to address the original questions directly:
- How well does RMF scale with a large number of robots?
This question comes up pretty regularly, so I’ll link to a previous answer.
That answer applies to the current Open-RMF implementation available today. We’re also working on a next generation of Open-RMF where users can choose what algorithms are used for traffic planning. For the next generation we intend to provide algorithms that can support hundreds to thousands of densely packed robots, but you will also have the options of
- Using your own algorithm
- Using an algorithm made by a community member
- Using a proprietary traffic management system that integrates with Open-RMF
With that the scaling will primarily depend on the characteristics of the algorithm that you choose. In the mutli-agent path finding space, different algorithms have different trade-offs, e.g. number of robots that can be handled, how disruptive dynamic obstacles are, whether they use discrete grids or graphs or free space, etc.
- How robust is the negotiation system when robots deviate from their planned trajectories?
Earlier in this comment I mentioned that Open-RMF is okay with robots deviating through free space. The negotiation system will generally adapt to whatever the robots are doing. When a traffic conflict is detected, it will have them negotiate based on whatever the current locations of the robots happen to be.
However negotiations are carried out based on the discrete navigation graph, so if robots are far away from the navigation graph lanes then some of the negotiation results may be wonky. Nevertheless, the negotiation system will always do one of two things:
- Find a multi-agent plan that resolves the traffic conflicts
- Fail to find a plan, allow the robots to continue moving towards their goals, and make another attempt to resolve the conflicts a few seconds later if the conflict still exists.
If (1) happens then the robots will be able to make progress towards their goals. If (2) happens, the robots might be able to resolve the conflicts on their own using their on-board navigation. If not, there will be another attempt at negotiation shortly, based on whatever the robots new positions are. In wide open spaces this will generally resolve quickly. In narrow, confined spaces you will need to strategically design the navigation graph to help it know how to resolve pile-ups in those spaces. In the next generation traffic management, we plan on supporting free space negotiation, which will be less sensitive to the design of your navigation graph.
- How critical is accurate ETA/prediction from the fleet adapter in real deployments?
Predictive accuracy is not critical at all. The traffic system is constantly adapting to any delays that occur in the movement of the agents. If predictions are very bad then you might find robots waiting longer than they need to because they think some other robot is going to be an obstacle for them but actually that other robot is very far away. So the quality of some traffic decision-making could be degraded if predictions are very bad, but every robot will eventually get where it needs to go.
- Is RMF typically used for full traffic coordination, or mainly as a higher-level task dispatcher with local autonomy handling most conflicts?
The intention of Open-RMF is to focus on resolving conflicts between different systems that need to operate in the same space, but in practice it often gets used for full traffic coordination.
- How does latency behave as the number of robots increases (e.g., schedule updates, negotiations, task dispatch), and are there known bottlenecks?
I haven’t seen any issues or complaints about latency or network bottlenecks. The traffic schedule updates are fairly efficient, and so is the negotiation protocol. I think the physical systems will have trouble scaling long before the network is overwhelmed.
We can also think of having flexible task scheduling but since our robot serves a different purpose than cleaning robots, they would need to move along with crowd as well.
In such scenarios, would you still we value in using RMF beyond task orchestration for constrained areas or shared resources where most of complexity shifts to local navigation layer than task scheduling?
The intent of Open-RMF is to interfere as little as possible with the behavior of the robots, and to adapt the traffic schedule to any delays or deviations that the robots undertake. In the scenarios where the robots need to act based on the environment, Open-RMF should not interfere until a traffic conflict emerges. In the scenarios where Open-RMF isn’t needed, the behavior of the robots should not be significantly affected. In the scenarios where traffic conflicts start happening, Open-RMF should kick in and help resolve them.