Traffic light AGV's footprint and vicinity ignored unless moving

[rcywongaa]

Bug report

Required information:

• Operating system and version:
  • rmf_demos container (17f43f1c79ff)

Description of the bug

It seems current traffic light implementation only reports AGV footprint and vicinity (via publishing to /rmf_traffic/itinerary_set) when AGV is moving (as shown by the yellow and blue circles on rviz). Once AGV stopped, it stops publishing to /itinerary_set. The footprint and vicinity of the AGV disappears on rviz and is disregarded by rmf_traffic. This causes rmf_traffic to fail to pause routes that pass through a stopped traffic light AGV.

Steps to reproduce the bug

• Running ros2 launch rmf_demos office_mock_traffic_light.launch.xml
• Move tinyRobot2 to be on the path between tinyRobot1_charging and tinyRobot2_charging
• Through web UI (http://localhost:5000) create a Loop request from tinyRobot1_charging to tinyRobot2_charging

Expected behavior

• Yellow and blue circles should appear on both tinyRobot1 and tinyRobot2
• rmf should pause tinyRobot1 before it collides with tinyRobot2

Actual behavior

• There is no yellow / blue circle on tinyRobot2 (traffic light AGV)
• gzserver triggers tinyRobot1 to stop to avoid collision instead of rmf

Screenshots

demo simulation

Another example with hardware in the loop simulation

• tinyRobot1 is simulated in gazebo
• sesto1 is an agv in real life (with traffic light implemented)
• sesto1 was sent to the T junction via external (non-rmf) API and stopped for a supposed job
• tinyRobot1 sent to Loop between TinyRobotStation and TinyRobotRC
• As seen, without the gazebo foresight of sesto1's location, tinyRobot1 is sent crashing into sesto1

[mxgrey]

I'm closing this issue because this is the intended behavior of the traffic light API.

There are two "illegal" conditions happening in your scenario:

1. tinyRobot1 has been tasked to move into a waypoint that is already occupied by another robot. Right now we rely on system integrators to not set up scenarios that create this situation, but in the future we will have a reservation system that will allow RMF to automatically enforce this rule.
2. A traffic light API robot must have exclusive rights to its start and end locations. This is related to issue 1., but more strict for the traffic light API. In the example you've given, even if tinyRobot2 were actively reporting its position to the schedule, there is nothing it can do to respond to the conflict with tinyRobot1. The traffic light API cannot ask one of its robots to move if it's not already moving. Ensuring a robot's exclusive rights to its startpoints and endpoints is the responsibility of the system integrator. That will always be the case because the traffic light API simply cannot intervene enough to do anything about this situation.

[rcywongaa]

Thanks @mxgrey for the prompt reply. I've updated the issue a bit to better illustrate my question. Namely, am I right to expect that RMF should be the one pausing tinyRobot1 instead of gazebo (since gazebo won't be available in real life)? Or is it the system integrator's responsibility to ensure that AGVs (especially traffic light AGVs) never stops on a path that other AGVs may take? Or do we rely on the AGV's own rerouting / obstacle avoidance to get around stopped AGVs?

[mxgrey]

Or is it the system integrator's responsibility to ensure that AGVs (especially traffic light AGVs) never stops on a path that other AGVs may take?

For traffic light AGVs in particular, yes, it is the responsibility of the system integrator to make sure that the AGV has exclusive rights to be at whatever place it is stopped. The traffic light API doesn't have enough authority over the AGV to resolve conflicts that come up from the AGV being parked in a bad place.

RMF should be the one pausing tinyRobot1 instead of gazebo (since gazebo won't be available in real life)?

RMF only deals with resolving traffic conflicts to the best ability allowed by the APIs of the traffic participants that are conflicting. That means RMF is not responsible for ensuring separation here, because the parked AGV has effectively declared that it has arrived at its own exclusive parking spot, and therefore is assumed to no longer be participating in the traffic system.

Or do we rely on the AGV's own rerouting / obstacle avoidance to get around stopped AGVs?

While I would discourage ever parking an AGV in a location where it would interfere with the traffic of another robot, the answer to this question is yes. Once an AGV is parked, it should be treated as an ordinary static obstacle and AMRs that are capable of navigating around static obstacles should simply navigate around it.

There are ways that the RMF traffic scheduling system could enforce separation of a parked traffic light AGV in the way that you were expecting, but I think that behavior could cause worse complications, like permanently blocking off a lane that the parked robot doesn't really need anymore. If we were to consider adding that behavior, it should first be written out in a very carefully thought out design document.

[rcywongaa]

Understood, thanks for the clarification!