mutex group is released when robot is not performing task

[cwrx777]

Hi,
rmf release: iron 20231229

Based my observation on /mutex_group_states topic, when a mutex group is released, it is still in the assignments list but the claimant value become some long integer.
I also noted there is Forcibly releasing mutex group [] requested by robot [] because the robot has been idle for an excessive amount of time, which is about 10 seconds after the task ends.
Why is mutex group released when robot is not performing task (including after rmf/fleet adapter restart)? Robot not performing task does not mean that the robot is not occupying the waypoint/lanes with the mutex group set. And with mutex group released, other robots may be coming to use the lanes.

[mxgrey]

Open-RMF cannot reasonably do traffic management for fully idle robots.

If you want a robot to be idle in an area with traffic, then you need to have the responsive wait feature on, which will keep the robot responsive to traffic and let it hold the mutex.

However the current implementation of the responsive wait behavior isn't generally great for traffic management over long periods of time, so I really recommend giving idle robots a finishing task to park somewhere out of the way when they are finished with their tasks.

Holding a mutex has serious implications for the ability of other robots to perform their tasks, so I find it difficult to imagine situations where it's desirable or intended for a fully idle robot to keep a mutex locked indefinitely. But if you have a use case where you think there's a legitimate justification for that, I'm happy to discuss that in more depth.

[Bluedragonplayz2]

There is a possibility that a robot would idle in a mutex, yet still require open rmf to hold the mutex group for the robot.

I'm not too sure about the uses of mutex group or the responsive wait feature, but in this case the mutex group is used to hold an exit/entry lane clear while a robot picks up its load/cart. 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

No matter the situation, 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).

another question is that when forcibly releasing a mutex group, why is the robot not automatically rerouted to the nearest none mutex waypoint. The robot still exists in the real world which may cause traffic deadlock for other robots pathing through the mutex zone. This point is especially important as I highly doubt a agv style robot can find a path pass an idle robot that is not accounted for by open rmf

again I'm not too familiar with the use case of mutex and its intended purpose so if any of the above is a bad example please let me know

[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).

[cwrx777]

@mxgrey ,
is the robot still holding mutex while it's performing on_cancel?

[mxgrey]

If it's holding a mutex when a task is cancelled, it should continue holding the mutex until the cancellation behavior or the next task instructs the robot to move out of the mutexed area.