search

averbraeck / opentrafficsim

Open Source Multi-Level Traffic Simulator
BSD 3-Clause "New" or "Revised" License
28 stars 8 forks source link

Dead-end deceleration vs. shoulder lane #108

Closed WJSchakel closed 4 months ago

WJSchakel commented 4 months ago

In the original LMRS model and simulation, when vehicles were not able to change lane in time, they were deleted. In order to preserve conservation of vehicles in OTS, deceleration towards a dead-end was implemented as part of the synchronization routine. This seems a minor adjustment, however, the deceleration towards a dead-end disturbs the synchronization and cooperation procedure precisely where it is most critical to operate. To show this, trajectories in the short merge demo were produced. With deceleration for a dead-end, the following trajectories result:

deadend

If we disable the deceleration for a dead-end, and instead force an instantaneous lane change whenever a vehicle reaches the end of the merge, these trajectories result:

forced

The total number of vehicles with a forced instantaneous lane change is 16 in the 1 hour simulation. As can be seen, the disturbances are much more severe with dead-end deceleration. This means that capacities will be significantly reduced relative to the original and calibrated LMRS. Therefore, a different approach is required. Forcing lane changes is a way to deal with this. Additionally, it would make sense to explicitly allow vehicles to extend over the shoulder lane.

Note that in both simulations the synchronization occurs slightly more intelligent than the original model. The maximum acceleration is applied regarding to two situations:

WJSchakel commented 4 months ago

The 'no traffic lane' concept has been removed. It is no longer a valid cross section element in XML. The Shoulder class is removed. Instead, the static Lane.noTrafficLane() has been renamed to Lane.shoulder(), and uses a fixed lane type for recognition. In this way, shoulders are lanes that can contain GTUs. They have no further information, and the speed limit is taken from an adjacent lane.

WJSchakel commented 4 months ago

GTUs will now extend on the shoulder if a lane change has not been made in time. However, from that point other GTUs will no longer cooperate as they are not aware of the GTU on the shoulder. This is due to an issue with the LaneStructure in perception that will not see shoulders laterally. This is because otherwise upstream of the merge, potentially cooperating vehicles will see the shoulder as their right hand lane, disabling all cooperation upstream of the merge. This is a structural issue in the LaneStructure that will need to be solved by improving the perception structure.

WJSchakel commented 4 months ago

The 'Lane.SHOULDER' LaneType has been removed. Instead there is now a class Shoulder that extends Lane with only minor changes. Now instanceof is used rather than checking the lane type. This is done because lane types should be fully customizable. So for example the conflict builder should not check lane type to consider what lanes to include for conflicts. Instead, it now skips lanes that are an instance of Shoulder.

The conflict builder did not have a check at all, which causes errors in simulations with conflicts and shoulders on the conflicts located on the shoulders as they lacked certain information. Conflicts are no longer generated on shoulders.