Posted by @mxgrey:
I’m very open to hearing different interpretations of how mutexes should work, and I’m happy to take these perspectives into account as we implement the “next generation” of Open-RMF which will be capable of addressing a much broader scope of capabilities than what the current implementation of Open-RMF is able to.
In the meantime, I can address questions and concerns in terms of the scope and capabilities of the current generation.
At this time possibly another robot is queueing in another mutex zone to enter the docking station, this results in the robot that is in the queue idleing in a mutex zone to waiting for the docking station to open up
In the context of this Discussion (and the current generation of Open-RMF in general), “idle” means the robot is not attempting to carry out any task. Instead of the word “idle”, we could say the robot is “jobless”. In the situation you’re describing, the queuing robot needs to queue in order to perform a task which is assigned to it. In that situation, the robot is not jobless and Open-RMF can reason about how it should behave. Open-RMF will keep the mutex locked for the queuing robot in that situation.
The problem with a completely idle/jobless robot keeping a mutex locked is that Open-RMF cannot reason about when that mutex might be released, or if it ever will be released. The only way for a jobless robot to ever release a mutex is for it to receive a new job at some point in the future. That will only happen when a user submits a new task request, which is not something that Open-RMF can predict. There’s even a possibility that no new request will ever be sent for that robot, so the mutex would remain locked forever. I think the balance of probabilities strongly favors that this is an erroneous state for the system to be in, so we automatically release the mutex to mitigate how much harm this will have on task execution.
I would like to ask if “Holding a mutex has serious implications for the ability of other robots to perform their task”, why is open-rmf giving a destination to fleet adapters that is in a mutex zone knowing that the robot will have to idle in the mutex zone as its waiting for other robots to clear the next stage of the path (and that robot ahead is possibly conducting a long duration task such as loading or unloading).
This kind of look-ahead is difficult to program in a completely general way. We’re working towards this capability with the “reservation system” which will be able to reserve resources in advance and be notified when the resources are ready, allowing those agents to pick designated holding areas to park in while they wait for the resource to become available, but this is still a work in progress.
why is the robot not automatically rerouted to the nearest none mutex waypoint.
This is the purpose of the “finishing task” (we’re transitioning the vocabulary of this over to “idle behavior”, but that term probably won’t take hold until the next generation). We recommend that users set the robot’s idle behavior to send it to a charger or a parking lot so it’s not an obstruction for general traffic. This isn’t something that Open-RMF forces on users because we can’t assume that this is always what users want (and in fact we’ve seen situations where users do not want this behavior).