[Bug]: Potential improvement in Negotiation procedure

[CarlyyyChen]

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

• 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

2.0.3

ROS distribution

Humble

ROS installation type

Source build

Other ROS installation methods

No response

Package or library, if applicable

rmf_traffic

Description of the bug

Hello team, in a simulation, when two robots are both heading to cafe to pick up coke, I notice that the negotiation takes a long time and sometimes the negotiation fails to be resolved and there is a "deadlock" when both robots refuse to yield. As you can see in the below video, both robots are heading to "cafe" to pick up the coke, however after that they have a long negotiation on which one should go first to deliver the coke. The negotiation gets resolved at 1:46 when one robot moves along a longer path. I am wondering if there is a way to reduce the negotiation time and to limit the number of oscillations during negotiation.

Negotiation.takes.a.long.time.webm

I have read relevant issues like open-rmf/rmf#162 and open-rmf/rmf#294, and I understand that currently it is not supported in open-rmf for two robots to go to the same place at the same time and it is suggested that system integrators should take on the responsibility of not commanding multiple robots to the same location at the same time. As a matter of fact, if I move one robot further away from the cafe, then above situation will not happen since they will not be at the cafe at the same time. But instead of getting around this issue, I am more interested in how to improve the current negotiation procedure. I understand that you have an enhancement ticket to introduce a queue system (open-rmf/rmf_ros2#214) so that the robots will wait in a queue area to access the resource one at a time, and it is not currently actively worked on. I also briefly understand how traffic management and negotiation works by reading your multi-robot book and relevant issues and pull requests including osrf/rmf_core#189 and osrf/rmf_core#101.

Besides working on the queue system, I wonder if there is a faster way to avoid negotiation deadlocks from happening and to reduce negotiation time? For example, when a negotiation is taking too long (like when a third negotiation is triggered), we can set an arbitrary robot to "freeze" and let the other robot to move first. Do you think if that is available? If so, what packages and classes shall I update in order for this new negotiation logic to work?

A second question will be, if above is available, is there a way for the traffic manager to know if a robot is active (running a task) or idle (coming back from previous task), so that it will always ask the idle robot to yield in a negotiation?

Any comments or suggestions on this is highly appreciated. Look forward to your reply!

Steps to reproduce the bug

1. Launch simulation in Rviz and Gazebo
2. send two delivery tasks for the robot to take
3. If the robots are moving to the cafe to pick up the coke at (nearly) the same time, negotiation will happen and sometimes it takes a long time to resolve

Expected behavior

No response

Actual behavior

No response

Additional information or screenshots

No response