AdaptToLeader calculates leaveSpeed depending on one time step

[Domsall]

In the following example, vehicle_0 is on a minor link and would like to drive onto the junction 2927559855.
The gap between vehicle_2 and vehicle_3 should be large enough for vehicle_0 to do this, but vehicle_0 actually waits for vehicle_3 to pass.

What I found out when debugging:

• When the vehicle in front (vehicle_1) does not exist, vehicle_0 has not problem crossing the junction.
• The leaveSpeed calculation without a leader results in a well estimated value and is done here: https://github.com/eclipse/sumo/blob/31b2a739c7a6751f50a8718222ffb22869243f05/src/microsim/MSVehicle.cpp#L2710
• When we have a leader on the next lane, the while-loop runs a second time and updates leaveSpeed in adaptToLeader with a value from followSpeed:
  https://github.com/eclipse/sumo/blob/31b2a739c7a6751f50a8718222ffb22869243f05/src/microsim/MSVehicle.cpp#L2929

This issue probably only gets exposed in subsecond simulations.

A test case showing this issue: AdaptToLeader_LeaveSpeed.zip

SUMO-version: 1.13.0 and 1.10.0

operating system: Windows 10

[Domsall]

I actually uploaded a test as zip in the previous comment :)

[namdre]

The problem is described in #11265 (comment)

[Domsall]

The issue was unfortunately not resolved for my use case.

The calculated estimatedLeaveSpeed (in the above example Line 2710) is approx. 6 m/s. This is used when vehicle_1 does not exist. Result: vehicle_0 drives over the junction.

The calculated futureVSafe (or the old vsafeLeader in Line 2929) uses the current speed or the speed after one time step to update LeaveSpeed, which is approx. 0.25/0.5 m/s. Result: vehicle_0 does not drive over the junction (because of high leaveTime in MSLink::blockedByFoe).

[namdre]

Even test test I added for this issue still shows the problem (though many other tests show improved traffic).