Robot Stuck in "Waiting for Traffic" State Despite No Blockage

[alex-roba]

I've observed an issue where a robot unnecessarily waits for traffic at a waypoint, even though its destination is clear and unblocked. The robot remains stuck in the "Waiting for Traffic" state indefinitely, until another robot moves to a different location. At that point, the waiting robot resumes its operation.

I've attached a video demonstrating the behavior. In the video, pay close attention to Robot 1, which exhibits the issue. It stops and waits unnecessarily without any apparent reason for the delay.

unncceary_wait.-.Trim.online-video-cutter.com.1.mp4

[mxgrey]

Thanks for catching and reporting this. It appears to be a bug in either the traffic dependency system or the traffic schedule update system. If you're able to provide a package (i.e. the map file and some launch files) that reliably reproduce the bug, I'll dig in to identify the cause and figure out a fix.

[alex-roba]

Hi @mxgrey,

I was able to reliably reproduce the bug in the office world. Below is the step-by-step procedure in Jazzy:

1. Launch the office world using:
   ros2 launch rmf_demos_gz office.launch.xml

2. Send a patrol task for robot 1 to the lounge using:
   ros2 run rmf_demos_tasks dispatch_patrol -F tinyRobot -R tinyRobot1 -p lounge -n 1 --use_sim_time

3. Once robot 1 passes the patrol_D1 waypoint, send a patrol task for robot 2 to the lounge waypoint using:
   ros2 run rmf_demos_tasks dispatch_patrol -F tinyRobot -R tinyRobot2 -p lounge -n 1 --use_sim_time

You will notice that tinyRobot1 is unnecessarily waiting at the waypoint before the lounge, even though tinyRobot2 has already completed its task, arrived at the lounge, and is parked. This wait is eventually interrupted by the excessively delayed behavior, which lasts around 30 seconds.

I am not using the reservation node here, but the same bug is also observed when the reservation node is enabled.

Let me know if you need more details!

wait.delay.-.Trim.online-video-cutter.com.mp4

[alex-roba]

Hi @mxgrey,

I was able to reliably reproduce the bug in the office world. Below is the step-by-step procedure in Jazzy:

Launch the office world using:
ros2 launch rmf_demos_gz office.launch.xml

Send a patrol task for robot 1 to the lounge using:
ros2 run rmf_demos_tasks dispatch_patrol -F tinyRobot -R tinyRobot1 -p lounge -n 1 --use_sim_time

Once robot 1 passes the patrol_D1 waypoint, send a patrol task for robot 2 to the lounge waypoint using:
ros2 run rmf_demos_tasks dispatch_patrol -F tinyRobot -R tinyRobot2 -p lounge -n 1 --use_sim_time

You will notice that tinyRobot1 is unnecessarily waiting at the waypoint before the lounge, even though tinyRobot2 has already completed its task, arrived at the lounge, and is parked. This wait is eventually interrupted by the excessively delayed behavior, which lasts around 30 seconds.

I am not using the reservation node here, but the same bug is also observed when the reservation node is enabled.

Let me know if you need more details!