search

eclipse-sumo / sumo

Eclipse SUMO is an open source, highly portable, microscopic and continuous traffic simulation package designed to handle large networks. It allows for intermodal simulation including pedestrians and comes with a large set of tools for scenario creation.
https://eclipse.dev/sumo
Eclipse Public License 2.0
2.51k stars 1.42k forks source link

Lane change via TraCI moves to outermost sublane #12793

Open mpfist-no opened 1 year ago

mpfist-no commented 1 year ago

In my example, I have a vehicle driving on a three-lane road. The sublane model is active with a lateral resolution of 0.875m, dividing the lane into 4 equally sized sublanes. With the default settings, and confirmed in the SUMO gui, the latAlignment is set to "center".

However, when I trigger the lane change from TraCI via traci.vehicle.changeLaneRelative(VEHICLE_ID, 1, 10), the vehicle moves to the neighboring lane, but drives in the outermost sublane: sumo-vehicle-in-outermost-sublane

Only after a few seconds, depending on the duration argument of changeLaneRelative, it adjusts its lateral alignment to the center. Plotting the lateral offset illustrates this: sumo-lateral-offset-plot

Is this the expected behavior? If so, how can I make sure that a lane change results in a single smooth lateral movement until the configured lateral alignment is achieved?

A minimal reproducible example is attached: bugreport-lanechange.zip

SUMO-version: 1.15

operating system: Windows 10

namdre commented 1 year ago

the expected behavior is for the lanechange command to end as soon as the new lane is reached. After that a sublane change should start immediately to restore the desired alignment. It appears that the laneChange command stays active for the entire duration and blocks the beginning of the sublane change.

namdre commented 1 year ago

As a workaround you could use vehicle.changeSublane(vehID, 3.5) for changing smoothly to the left by one lane width.

mpfist-no commented 1 year ago

Thanks for your quick reply. This works as a temporary workaround but unfortunately, I do not have lanes of equal width all the time.

I have two more questions regarding the expected behavior of the lane change command:

  1. How does the lane change command react to bits 10 and 11 of the lane change mode (https://sumo.dlr.de/docs/TraCI/Change_Vehicle_State.html#lane_change_mode_0xb6)? Is it expected to have the vehicle return to the the configured lateral alignment after the lane change command in all three cases? Or only when the bits are 01 or 10?
  2. The meaning of the "duration" parameter of the lane change command is described differently in the web documentation and the Python documentation in the docstring (staying on the new lane for a given amount of time vs. trying to perform the lane change for the given amount of time. Which one is correct?
namdre commented 1 year ago
  1. you can make the workaround more robust with the help of traci.lane.getWidth
  2. here is the expected behavior for the different values of the 10th and 11th bit:
    • 00: no sublane change is performed by the model ever
    • 01: a sublane change should be performed if it goes in the same direction as an active TraCI request.
    • 10: a sublane change should always be performed (this could be another workaround for the bug at hand)
      1. Thanks for pointing this out. The web documentation was misleading. Both documentations have been clarified.
mpfist-no commented 1 year ago

Just a quick question (without intending to be pushy): Do you a have rough estimate when this issue may be fixed? I am currently investigating workarounds, but having a single smooth transition as reliable default behavior would be of great use for me!