Posted by @acf986:
In the rmf_traffic package, we have this core class “Route”, which have the following function:
Route& add_dependency(
CheckpointId dependent_checkpoint,
Dependency dependency);
It says, it will make this Route’s certain checkpoint to “depend on” the other participant’s checkpoint.
What is the physical meaning of this “dependency”?
Edit:
I have checked the code in the Crawler::ignore function, it seems that the “dependency” means that, if the other agent have moved passed the dependent waypoint, we could ignore the collision checking? Is my understanding correct? A little bit confused now.
Edited by @acf986 at 2022-09-18T14:51:05Z
Chosen answer
Answer chosen by @acf986 at 2022-09-18T16:06:23Z.
Answered by @mxgrey:
I think the best way to explain it is to share this slide.
For a short overview, a “traffic dependency” means that one robot intends to wait at a certain waypoint (let’s say B2 to match the slide) along its route until another robot has reached a certain checkpoint (let’s say A3 to match the slide). We encode that explicitly into the traffic schedule because if there is a significant delay in the robot that is being waited on, that could be interpreted as a traffic conflict. For example, if we had a purely time-based system and the schedule says that Robot A will reach A3 at t=10 and therefore Robot B will wait at B2 until t=10, that would be fine if Robot A has no delays.
However, what if in real life Robot A is only just reaching A2 at t=10? The schedule would see that as a conflict and demand that the robots re-negotiate their routes. That renegotiation is a waste of effort if we can just tell the schedule that Robot B will wait at B2 until Robot A reaches A3 regardless of the precise timing. Then the schedule knows that delays in Robot A prior to A3 will not create any conflicts with Robot B after B2.
Algorithmically this means that when detecting traffic conflicts we can have the conflict detector ignore any “collisions” it detects between
- Robot B’s path that come after B2, and
- Robot A’s path that come before A3
We would still check for collisions that involve Robot B’s path before B2 or Robot A’s path that come after A3.
Posted by @mxgrey:
I think the best way to explain it is to share this slide.
For a short overview, a “traffic dependency” means that one robot intends to wait at a certain waypoint (let’s say B2 to match the slide) along its route until another robot has reached a certain checkpoint (let’s say A3 to match the slide). We encode that explicitly into the traffic schedule because if there is a significant delay in the robot that is being waited on, that could be interpreted as a traffic conflict. For example, if we had a purely time-based system and the schedule says that Robot A will reach A3 at t=10 and therefore Robot B will wait at B2 until t=10, that would be fine if Robot A has no delays.
However, what if in real life Robot A is only just reaching A2 at t=10? The schedule would see that as a conflict and demand that the robots re-negotiate their routes. That renegotiation is a waste of effort if we can just tell the schedule that Robot B will wait at B2 until Robot A reaches A3 regardless of the precise timing. Then the schedule knows that delays in Robot A prior to A3 will not create any conflicts with Robot B after B2.
Algorithmically this means that when detecting traffic conflicts we can have the conflict detector ignore any “collisions” it detects between
- Robot B’s path that come after B2, and
- Robot A’s path that come before A3
We would still check for collisions that involve Robot B’s path before B2 or Robot A’s path that come after A3.
This is the chosen answer.
Posted by @acf986:
Thanks very much for your elaboration!
Posted by @acf986:
And may I also check with you, the waiting logic is implemented in which part of the rmf? Just didn’t find them in rmf_traffic.
Posted by @mxgrey:
The main role of rmf_traffic is to implement the planning algorithms that are used by the system. It doesn’t take care of any details for executing the plan. However, the rmf_traffic::schedule::Viewer does provide a watch_dependency function which is used by downstream libraries to trigger a reaction when a robot reaches a checkpoint.
Since RMF is a highly distributed system there isn’t a single point to refer to and say “Here is where waiting is implemented” but perhaps the most relevant module would be the WaitForTraffic event in rmf_fleet_adapter which uses the watch_dependency function to manage the waiting behavior.
Edited by @mxgrey at 2022-09-18T17:11:09Z