DrivingCorridor - Computation & Meaning

Hello all,
I used Commonroad Reach to analyze driving scenarios.
Through DrivingCorridors (DC) I want to map all possible connected trajectories. In the following picture you can see a DC. Why is this considered one even though the area splits into two parts. Shouldn’t these be two single DC’s each? By the temporal backward propagation two paths should be formed.

I would be very grateful for feedback and more detailed information about the calculation of the DCs.

Best regards
Sven Tarlowski

PS:own scenario for explanation purposes, included id’s of Nodes for Debuging

Hi Sven, yes, in this case, it should be two driving corridors. @gerald_w could you or other colleagues have a look at this?

Hi Sven,

I’m quite a bit late to the party, but was investigating the corridors myself and decided to leave my findings here for others to find as well. Edmond, Gerald, please correct me if anything is wrong.

Generally

The documentation states the DrivingCorridorExtractor can extract both longitudinal and, based on them, lateral driving corridors. Longitudinal corridors are defined as a temporal sequence of connected components. In your example there is indeed only one connected component. Lateral corridors have the extra constraint to provide a unique passing side.

If you are using extract_driving_corridors.py, this one only seems to extract longitudinal driving corridors by default. Similarly, if you are using ReachableSetInterface.extract_driving_corridors only once, without corridor_lon and list_p_lon, it would only extract longitudinal driving corridors.

If I understand correctly, the general workflow is to first extract a longitudinal driving corridor, then plan a longitudinal trajectory. Using this trajectory, one can then extract a lateral driving corridor and finally plan laterally.

Examples

I used the commented out code in extract_driving_corridors.py to find both longitudinal and lateral driving corridors for two scenarios. This code is quite naive as it takes the middle longitudinal value of each step as a longitudinal trajectory for the extraction of lateral corridors, which naturally doesn’t always work.

1. Scenario – single longitudinal corridor (similar to the one in question)

Reachable sets
1-reachsets

1. longitudinal driving corridor

1-longitudinal-corridor

1. corresponding lateral driving corridor

Note how the sets are often very small/invisible. That’s because we are now only using those reachable sets that contain the longitudinal positions from the naive longitudinal trajectory. As long as we are able to find any, that’s OK, as we are now only interested in lateral bounds to finish the planning.

1-lateral-corridor

2. Scenario – multiple longitudinal corridors (one shown)

That’s the scenario ZAM_Zip-1_6_T-1.xml available in CommonRoad-Reach.

Reachable sets

Notice how it matters whether the ego vehicle merges before or after the first vehicle, resulting in at least two driving corridors. Also note that we are dealing with many small reachable sets, which can create all sorts of weird connected components. Therefore, I was actually able to extract 12 longitudinal corridors. I believe there is a threshold in the implementation, so there could potentially be more. This is, of course, all heavily dependent on the used configuration.

2-reachsets

A longitudinal driving corridor

2-longitudinal-corridor

Below is another, weirder one. I believe such corridors can be avoided by setting a higher threshold for the minimal size of reachable sets, which would exclude such tiny passages. However, I can’t really say I entirely understand the method, so maybe the authors can say more.

2-weird-longitudinal-corridor

A lateral driving corridor?

Nope, wasn’t able to compute one with the trivial longitudinal trajectory.

References

See Using Reachable Sets for Trajectory Planning of Automated Vehicles.