Posted by @cwrx777:
RMF release: 22.09
Steps to replicate:
- Modify office.building.yaml as follows:
- move
supplies as shown
- remove wall between
supplies and coe
- modify tinyRobot_config.yaml:
- rebuild the rmf_demos_maps and rmf_demos package
- run office demo:
ros2 launch rmf_demos_gz_classic office.launch.xml
- send
tinyRobot1 to supplies:
ros2 run rmf_demos_tasks dispatch_patrol -p supplies -F tinyRobot -R tinyRobot1 --use_sim_time
- 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
- 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.
Posted by @Yadunund:
This is a known limitation and has been discussed extensively in this discussion RMF Traffic occasionally fails to manage multiple robots headed to the same destination · open-rmf/rmf · Discussion #162 · GitHub
It will be resolved by the introduction of a reservation system. Closing this ticket as its a duplicate.
Posted by @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.
Posted by @cwrx777:
https://github.com/open-rmf/rmf/assets/3224215/a0278309-910e-4d53-a18b-7495b4103933
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
https://github.com/open-rmf/rmf/assets/3224215/de7f383c-0e2a-4eda-aa64-3af8fd111d44
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
https://github.com/open-rmf/rmf/assets/3224215/c62185b9-1aea-4058-9a54-a8eb36d34a40
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?
Posted by @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.
Posted by @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.
https://github.com/open-rmf/rmf/assets/3224215/0bebeb72-68e2-489a-b073-2fe03ca42f2d
Previously I opened another discussion ticket #348 asking about how RMF uses different types of waypoints for deconfliction.
Posted by @cwrx777:
Hi @mxgrey ,
Can deconflict be resolved or improved by using the blockade system?
