I would like to propose a possible enhancement to Open-RMF’s lift selection mechanism.
From my understanding, when a robot plans a route that involves changing floors, the planner also decides which lift the robot will use. If there are multiple lifts serving the same lift lobby, the planner typically selects the one with the lowest estimated cost, so the robot commits to a specific lift before reaching the lobby.
Instead, would it make sense to plan only up to the lift lobby, rather than to a specific lift?
The idea is that once the robot reaches the lift lobby entrance, RMF could then assign it to whichever lift is currently the best choice based on real-time availability and waiting time.
High-level flow:
Plan the route to a lift lobby.
Travel to the lift lobby entrance.
Select the best available lift in the lift lobby
Continue the journey.
This could improve lift utilisation and reduce waiting time in buildings where multiple lifts serve the same lobby.
The downside of this is that the robot cannot call the elevator ahead of time. It seems like the optimal thing to do would be the following. While the robot travels to the elevator lobby, keep estimating when each lift could arrive on the current floor if it was called now and keep estimating the robot’s own arrival time in the lobby. If all elevators would arrive after the expected robot arrival time, call the closest one immediately. Otherwise wait until the robot is “within range”, and then call an elevator in the moment the two arrival times coincide – probably with some buffer for the robot, i.e., call the elevator to arrive slightly later than the robot.
Ive written entire papers on this problem… If you have control over elevator schedules then one could potentially optimise jointly.
Im hoping with the next generation work we are doing we should be able to tailor such requests to individual use cases. I can see @Charly_Wu 's use case for when we dont have very good control over the lifts themselves.
That’s usually the real bottleneck. At least back in 2019 when I left Savioke/Relay, elevator APIs, if they even existed, were still very different between the various elevator makers and service providers. And when they don’t yet have an API then it is usually cost-prohibitive to integrate with more than one specific elevator, so the opportunity for optimization doesn’t even arise. Would be curious to hear how things have changed since then. It’s also a very US-focused experience and I suspect Singapore is ahead of the curve here with APIs.
This is an important topic for the Open-RMF project.
We’ve known for many years now that the lift lobbies of certain buildings will not provide an API for summoning a specific lift. Instead we can only make a request that some lift in the lobby provides a journey from the current level to the destination level, and then the lift lobby controller decides which lift to use and tells us. I think this is a similar workflow to what you’ve described about selecting the best available lift.
This is something we intend to account for the second stage of the “Next Generation” Open-RMF development, after basic multi-vehicle traffic management has been implemented.
In the meantime, the team at CHART is already well underway with a zone feature in the current generation of Open-RMF which should be able to accomplish what you’re looking for once it’s complete. There would be a zone manager node that could manage a lift lobby and redirect robots to specific lifts within the lobby.