Posted by @cwrx777:
open-rmf release: iron 20231229
Issue summary: robot does enters lift without having lift session if while waiting for lift, robot current task is cancelled and assigned with another task.
Building yaml: hotel.building.yaml
Difference with original building yaml:
- remove lane to Lift2. This is so that only Lift1 is used.
- use unidirectional lanes to enter and exit Lift1
Robot starting position is set by using spawn_entity.launch.xml and robotplacer.launch.xml
Task is dispatched by using this modified dispatch_patrol.py
https://github.com/user-attachments/assets/abbb57fa-8633-46f7-a9fd-32a63f633ed5
Initial position:
tinyBot_1
is at Lift_LWP_L1
and tinyBot_2
is at Lift1_LWP_L2
.
First, send tinyBot_2
to a location at L1
.
ros2 run rmf_demos_tasks dispatch_patrol -F tinyRobot -R tinyBot_2 -p restaurant --use_sim_time -id task_1;
Then, a moment later, send tinyBot_1
to a location on L2
. This is to make tinyBot_1
to keep requesting for the lift.
sleep 5;
ros2 run rmf_demos_tasks dispatch_patrol -F tinyRobot -R tinyBot_1 -p L2_room15 --use_sim_time -id task_2;
(refer to video at 00:25
), when tinyBot_1
reach L1
and lift door start to open, cancel tinyBot_2
’s task and send it to another location on L1
.
ros2 run rmf_demos_tasks cancel_task -id task_2;
ros2 run rmf_demos_tasks dispatch_patrol -F tinyRobot -R tinyBot_1 -p restaurant --use_sim_time -id task_3;
Observation:
tinyBot_2
enters lift while tinyBot_1
is still inside.
Edited by @cwrx777 at 2024-10-25T16:17:37Z
Chosen answer
Answer chosen by @cwrx777 at 2024-11-18T00:26:49Z.
Answered by @mxgrey:
The bug has been found and fixed here: Fix lift disruption issue by mxgrey · Pull Request #393 · open-rmf/rmf_ros2 · GitHub
There are exactly two ways that the bug can occur:
- A task gets cancelled while the robot is waiting to use a lift, and a new task is assigned (such as the finishing task) which tells the robot to use the same lift right away.
- A negotiation or replan happens while the robot is waiting to use a lift, and the new plan tells the robot to use the same lift right away
I believe all the bugged cases that you’ve discovered match one of those categories, so the fix should cover everything.
That said, I would still recommend making sure that robots can always enter and exit lifts without a risk of conflicts occurring (e.g. by using mutex groups) since negotiating may still cause significant disruption during the somewhat brittle process of getting in and out of lifts.