[Bug]: Robots Entering Shared Docking Lane Simultaneously Despite Mutex Configuration

[osama-z-salah]

Before proceeding, is there an existing issue or discussion for this?

• [X] I have done a search for similar issues and discussions.

OS and version

Ubuntu 22.04

Open-RMF installation type

Source build

Other Open-RMF installation methods

No response

Open-RMF version or commit hash

iron

ROS distribution

Iron

ROS installation type

Source build

Other ROS installation methods

No response

Package or library, if applicable

No response

Description of the bug

I am simulating a scenario where two robots need to pick up objects from a shared docking station. However, both robots are entering the docking lane simultaneously, causing them to collide with each other. I've already configured the lane and waypoint as mutually exclusive (mutex) in the traffic editor, but the collision still occurs. The attached video demonstrates the issue. Screencast from 08-21-2024 05:33:36 PM.webm

Steps to reproduce the bug

1. Run simulation with turtlebots

Expected behavior

No response

Actual behavior

No response

Additional information or screenshots

No response

[xiyuoh]

Hello @osama-z-salah ! May I understand your navigation graph better - which waypoints are assigned the mutex group? What is the mutex group called, and is the name consistent across the relevant waypoints and lanes? Lastly, may I check if you launched the mutex group supervisor node? If not, you may try adding these lines to your own common.launch.xml:

<group>
  <node pkg="rmf_fleet_adapter" exec="mutex_group_supervisor" output="both" />
</group>

[osama-z-salah]

Hello @xiyuoh, thanks for your response! My goal is to pick up an object from the ato_dock waypoint, which serves as a docking waypoint. I’m still trying to fully understand how to properly use mutexes. I've added a mutex property to both the lane leading to the docking waypoint and the waypoint itself. I named the mutex for the waypoint the same as the waypoint (ato_dock), while for the lane, I used a different name, docking_lane. Regarding the mutex_group_supervisor, I have added it to the common.

One more thing I'm struggling to understand is the use of override_schedule. Should I apply it when performing actions at the docking waypoint, even if I'm not moving (e.g., jacking up the load), or is it sufficient to use it just for the docking itself? Could this be related to the current conflict I'm experiencing?

[xiyuoh]

I see! For areas where you want only 1 robot to occupy, you'll have to assign a uniquely-named mutex group to all the waypoints and lanes within this area. In other words, each mutex "area" is defined by the mutex group name. Seems like the issue here is the waypoint and lane carrying different mutex group names, so both robots could access them at the same time.

Can you try making the mutex group name identical for both the docking waypoint and the lane leading to this waypoint? You might also want to assign the same mutex group name to the entry waypoint adjacent to the docking waypoint, to ease the deconfliction process. When you run this, you should be able to see something like "robot2 waiting for the mutex held by robot1" printed on the fleet adapter terminal.

Let me know if this works!

[osama-z-salah]

Thanks! Yes, it works now, but I'm facing another issue with override_schedule. After it finishes, it re-plans and makes my robot attempt to dock again, even though it’s already docked.

Also, one last question: is it necessary to apply override_schedule when performing actions at the docking waypoint, even if the robot isn't moving (e.g., jacking up the load), or is it sufficient to use it just for the docking itself?

[xiyuoh]

You can try removing the override_schedule. But if the issues persists, feel free to provide some logs from the terminal, perhaps from the point where the robot has completed docking, and put them in a gist if the logs are too long.

And no, you don't have to apply override_schedule for every single step of your performable action, especially in your use case where the robot is stationary and the docking area is "protected" by a mutex group. You may use it to take into account any specific trajectory unknown to RMF during your action, and it is helpful to spot any potential traffic conflict. Here is the API for it as a reference.