Add new calcAngleOffset() with known isChangingLanes()-bug

[Domsall]

For this to work correctly:

1. isChangingLanes() in computeAngle() needs to be changed.
   --> Done, does not need to be changed. I checked, if this Code part changes any test and it does not.
2. isChangingLanes() in getBackPosition() needs to be changed. getBackPosition() uses LC-model-dependent function #12146
   --> Done
3. Update tests

See #11882 for reference. Part 3 of 3.

[namdre]

Some updates:

• getBackPos should now return sensible values throughout (getBackPosition() uses LC-model-dependent function #12146) - let me know if you still have a test where getBackPos returns bad things)
• I'm okay with having myPreviousAngleOffset in the code (the new computeAngle will actually make it easier to refactor this out. The old sublane angle computation makes it infeasible to move computeAngle to a point in the code where positional updates have been completed).

I'm looking at angle over time in lc_model/continuous_lanechange/basic and testing this with steplengt h1 and 0.2: (green is the old behavior):

My assumption would be that the curve keeps some kind of symmetry with respect to the midpoint of the maneuver.

The next plots are from sublane_model/speedGain/default with steplength 0.2 (plots are for the ego vehicle overtaking on the left and the non the right. (note: the blue is the old behavior here)

Again the new plots are less symmetrical (especially the second maneuver). The common feature for both tests seems to be that the new code produces a smooth start of the maneuver but a rather sharp angular change at the end of the maneuver. The smoothness looks like an improvement but the asymmetry makes me wonder whether there is still a bug somewhere.
To rule out that this is an artifact of the sublane model I also looked at lateral speed. It doesn't appear that the lateral speeds have an asymmetry around the midpoint of the maneuver:

I also looked at the test lcSigma case you provided in #8529 and the angle plots look indeed much better than before:

As a side not: The junction collision reported the #8529 test (when activating tracking) is rather due to an invalid internal junction position that can be fixed be saving the network in netedit again. Though I can image that the angle "flips" were causing all kinds of problems in other context.

[Domsall]

Thank you very much for extensively testing the new Code!

The first issue with the continuous lane change model comes from the way speedLat is calculated.
At the beginning of the lane change, speedLat is set to a specific value. This value stays constant until the lane change ends. The angle does not start changing back to its old value until the lane change is over and speedLat goes from the value back to zero.
2 solutions to change this behavior:

• change the lane change trajectory to something smoother, this would make speedLat change its value smoother (something similar to https://github.com/octavdragoi/sumo/tree/smooth-lane-change)
• add a "hack" that reduces the speedLat-value for the angle-calculation depending on the lane change completion value.

The asymmetry of the angle is a bit expected.
What happens now:

• When the lane change is over (latDist=0), the angle is already back to its old value.

Whats happens with the new Code, if I compare the first angle and last angle of a lane change:

It takes a bit longer to "straighten" out. I hope this makes sense.

[namdre]

If you look at the second picture, (lc_model/continuous_lanechange/basic with steplength 0.2) you can see that the weirdness is not something that happens in the last step of the lane change (the final part is nice and smooth). Instead it's somewhere in the "middle" of the maneuver where the angle starts to reverse direction. So frankly, I still don't understand the shape of the curve.

It's not really worse than the old behavior though and the lcSigma behavior is much better. So I don't really mind merging this.

any comments from your side @behrisch ?

[behrisch]

No, just go ahead

[Domsall]

If you look at the second picture, (lc_model/continuous_lanechange/basic with steplength 0.2) you can see that the weirdness is not something that happens in the last step of the lane change (the final part is nice and smooth). Instead it's somewhere in the "middle" of the maneuver where the angle starts to reverse direction. So frankly, I still don't understand the shape of the curve.

oh, you mean that part. I already tried to explain it here: #11882 (comment). The lane change shall be completed in gLaneChangeDuration seconds. This means: Different angles for the vehicle at low and high longitudinal speeds.
Here: At the beginning of the lane change, the vehicle has a lower velocity, which means that it needs to have a steeper angle to reach the new lane in gLaneChangeDuration seconds. During the lane change, the vehicle is still accelerating, which means that with this higher velocity (and still constant lateral speed), the angle of the vehicle changes.
You can compare it with a lane change on the highway and in a city. When both lane changes take the same amount of time, the lane change on the highway would be performed with less change in driving direction/angle than in the city.

2 solutions to change this behavior:

• change the lane change trajectory to something smoother, this would make speedLat change its value smoother (something similar to https://github.com/octavdragoi/sumo/tree/smooth-lane-change)
• add a "hack" that reduces the speedLat-value for the angle-calculation depending on the lane change completion value.

Should one of the suggested solutions be further pursued?