Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 11, 2022

Conversation

Domsall
Copy link
Contributor

@Domsall Domsall commented Dec 1, 2022

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
Copy link
Contributor

namdre commented Dec 2, 2022

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):

step1
step0 2

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)

figure_1

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:

speedLat0 2

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

sigma

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
Copy link
Contributor Author

Domsall commented Dec 2, 2022

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:

image

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

@namdre
Copy link
Contributor

namdre commented Dec 6, 2022

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
Copy link
Contributor

behrisch commented Dec 7, 2022

No, just go ahead

@Domsall
Copy link
Contributor Author

Domsall commented Dec 7, 2022

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?

@namdre namdre merged commit c751163 into eclipse-sumo:main Dec 11, 2022
namdre added a commit that referenced this pull request Dec 11, 2022
namdre added a commit that referenced this pull request Dec 12, 2022
@Domsall Domsall deleted the calcAngleOffset branch December 12, 2022 12:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants