Deconflict issue

[cwrx777]

RMF release: 22.09

Steps to replicate:

1. Modify office.building.yaml as follows:
   • move supplies as shown
   • remove wall between supplies and coe

2. modify tinyRobot_config.yaml:
   • set reversible to False.
3. rebuild the rmf_demos_maps and rmf_demos package
4. run office demo:
   ros2 launch rmf_demos_gz_classic office.launch.xml
5. send tinyRobot1 to supplies:
   ros2 run rmf_demos_tasks dispatch_patrol -p supplies -F tinyRobot -R tinyRobot1 --use_sim_time
6. wait until tinyRobot1 is reaching supplies, send tinyRobot2 to supplies:
   ros2 run rmf_demos_tasks dispatch_patrol -p supplies -F tinyRobot -R tinyRobot2 --use_sim_time
7. when tinyRobot2 is on the lane between pos_A (see pic) and supplies, send tinyRobot1 to pantry:
   ros2 run rmf_demos_tasks dispatch_patrol -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time

Observation:

The two robots were not able to recover from conflict.

[Yadunund]

This is a known limitation and has been discussed extensively in this discussion #162 (comment)
It will be resolved by the introduction of a reservation system. Closing this ticket as its a duplicate.

[cwrx777]

Hi @Yadunund ,

I have edited the steps in the original post. At step7, the destinations of the two robots are actually different:
tinyRobot1 is going to pantry and tinyRobot2 is going to supplies.

[cwrx777]

• Part 1

deconflict_issue_20230518_part_1.mp4

In Part 1, while tinyRobot2 was moving to pos_1 (the current position of tinyRobot1), tinyRobot2 waited at the beginning of the lane (01:13).
And after tinyRobot1 was sent a command to exit pos_1 (01:48) , tinyRobot2 was able to give way to tinyRobot1 (deconflict was successful).
See also 04:34

• Part 2

deconflict_issue_20230518_part_2.mp4

In Part 2, while tinyRobot2 was moving to pos_3, (the current position of tinyRobot1), tinyRobot2 moved into the lane to go to pos_2 at stop approx 1.2meters from tinyRobot1 (00:55).
And after tinyRobot1 was sent a command to exit_pos_3 (01:20) , tinyRobot2 was able to give way (deconflict was successful).
See also 3:46

• Part 3

deconflict_issue_20230518_part_3.mp4

In Part 3, while tinyRobot2 was moving to pos_5, (the current position of tinyRobot1), tinyRobot2 moved into the lane to go to pos_3 at stop approx 1.2meters from tinyRobot1 (00:40).
And after tinyRobot1 was sent a comand to go to exit pos_5 (00:50), tinyRobot2 was not able to give way, and deconflict failed.

There seems to be a minimum lane length that will make robot to wait during deconflict and also minimum distance between a robot and another robot before the idling robot is assigned with another task in order for deconflict to be successful.
Which node is responsible to plan the path during deconflict and what parameters can be adjusted?

[mxgrey]

I don't think it's a matter of minimum lane length. I suspect if you add a short vertical lane that goes up from the pos_5 exit, just enough for tinyRobot2 to move out of the way of tinyRobot1 (see purple addition in picture below), then the negotiation might work. Especially if you mark the waypoint at the end of the short lane as a "holding point".

The root issue here is that you have a token swapping problem where A needs to wait for B which then needs to wait for A later. The current negotiation system can sometimes handle this, but it will usually need help with a nearby holding point. Even then it's not really guaranteed to find a solution. This is an issue we're actively working to improve for the next generation of RMF traffic negotiation.

In the meantime the most reliable way to avoid this problem is to provide parallel lanes going to a waypoint. Providing two parallel one-way lanes in opposite directions (like a street for automobiles) is especially effective. That eliminates the need for the robots to swap places which makes the traffic negotiation much more reliable even in the current implementation.

[cwrx777]

Hi @mxgrey ,

Thanks for the input. Quite often the place does not have the space to fit two MiR100 robots to move in opposite directions.
e.g.

Using the video I posted earlier as an example,
if the robot waits at the lane entry point (Part 1 - 01:13), the deconflict will be always successful, and if the robot moves into the lane of the destination point when there is already a robot there, most of the time deconflict will fail. What makes RMF decide on the different behavior (wait at lane entry vs move to destination)?

I have added another video with the holding points added.
only success once at 01:34.

deconflict_failed_2023-05-19_07-19-29.mp4

Previously I opened another discussion ticket #348 asking about how RMF uses different types of waypoints for deconfliction.

[cwrx777]

Hi @mxgrey ,

Can deconflict be resolved or improved by using the blockade system?