LaneChange Model

🔴DA DECIDERE🔴 La performPlatoonLaneChange e’ stubborn, non smette mai di provare ad arrivare alla requestedLane… facciamo un bel param duration come per tutte le altre traci.changeLane simili?

LG laneChange wishlist

• All PlexeControlled vehicles (being them platoon leaders or followers) suppress any internal laneChange reason and laneChange safety checks(laneChangeMode = 0). In fact, reasons and safety checks are demanded to dedicated plexe-sumo code that govern laneChanges via Libsumo, thus, raising external laneChange reasons.
• PlexeControlled vehicles with autoLaneChange=False never change lane spontaneously.
• 🔴IMPORTANT🔴 PlexeControlled vehicles SHOULD NOT obey to TraCi requests such as changeLane or changeLaneRelative.
• 🔴IMPORTANT🔴 PlexeControlled vehicles SHOULD instead favor a Plexe API dedicated to lane changes, e.g., performPlatoonLaneChange

Considerations on peformPlatoonLaneChange()

• The signature of peformPlatoonLaneChange may be:
  1. peformPlatoonLaneChange(laneIndexOffset $\in$ {-1, +1})
  2. peformPlatoonLaneChange(laneIndex)

Compared to the TraCi changeLaneRelative or changeLane we suppress the duration parameter and the platoon should immediately execute the laneChange action if not blocked, otherwise, the request is simply discarded and forgot if any of the platoon-member is blocked in the requested laneChange direction. ⚠️NB:⚠️ LG prefers option 1 with laneIndexOffset. Offset magnitude may also be grater than 1… to be considered.

• The laneChange action of a platoon should be coordinated by the leader.
• If this API is invoked on a member that is not a leader we have 2 options:
  • The request is always ignored by platoon-followers and thus takes no effect, the platoon will remain on its lane.
  • The request is forwarded to the leader.
• A leader that receives a peformPlatoonLaneChange request:

Leader handling a peformPlatoonLaneChange request

1. Computes the direction $d \in$ {RIGHT, LEFT} of the requested LaneChange
2. If all platoon-members are not $d$-BLOCKED (and all platoMembers are on a lane of an edge that allows to move in $d$), then the leader issues for all platoMembers a changeLaneRelative(duration=0) through Libsumo.
3. If any platoon-member is BLOCKED toward $d$ or is on a lane that makes impossible to move toward $d$, then all platoonMember remain on their current lane, i.e., the platoon discards the peformPlatoonLaneChange request.

⚠️WARNING⚠️ The conditions defining if a vehicle is BLOCKED depend on safety-gaps, that compared to the standard SUMO car-follow models are overridden by Plexe car-follow models. A platoon expected to obey but not actually obeying to a peformPlatoonLaneChange request may be stucked because of a poor definition of safety-gaps.

Consideration on AutoLaneChange

If the above recommendations are respected, a platoon never spontaneously changes lane, and a simulation controller must be implemented over traci to govern lane-change actions properly issuing peformPlatoonLaneChange requests.

An experimenter may decide to enable the autoLaneChange to let a platoon decide autonomously to change lane, without implementing a dedicated external controller.

• The autoLaneChange flag ($\in$ {True, False}) can be raised only on platoon-leaders.
• At every time-step, a platoon-leader with autoLaneChange=True decides its internal lane-change action according to the SUMO standard decision hierarchy
• If this internal lane-change action asks for a right or left movement, e.g, because of strategical/tactical/regulatory/speed-gain reasons, then the leader invokes a peformPlatoonLaneChange and, if all plato-members will be NON-BLOCKED, the platoon will fulfill the actions spontaneously computed by the platoon-leader.

⚠️TECH NOTE⚠️ a platoon continues to suppress internal/spontaneous lane-change reasons, but, if autoLaneChange is enabled (on a leader), the leader autonomously invokes peformPlatoonLaneChange every time an internal lane-change reason arises. In other terms, internal lane-change actions of the leader (always ignored) become candidate platoon-actions generated by libsumo. This mechanism works as long as

⚠️TECH NOTE⚠️ a PlexeVehicle that is leader of a “1-sized” platoon (i.e., it’s alone, actually is not a platoon, still, it’s a Plexe vehicle) by enabling the autoLaneChange option should, compare to a plain SUMO vehicle in the same scenario, perform the same and identical lane-change decisions. The only difference from the perspective of a laneChange-output is that the SUMO vehicles will report the usuale, default lane-change reasons in the log, while these reasons will become all traci | urgent in the Plexe vehicle since all decisions of Plexe vehicle are implemented via Libsumo.

Critical things

With respect to the 4 steps of the standard SUMO lane-change process architecture, the platoon-oriented code should be placed right after the 3rd step, especially for the leader, under the assumption that the leader is always the first vehicle of the platoon that computes internal change requests.

Tie-breaks between 2 platoons wishing to change to the same lane should be regulated after the choice from both to change to the same lane

Selected Notes from SUMO LaneChange Model documentation

Notes selected from: Springer-SUMOs_Lane_changing_model.pdf

Architecture

A vehicle may only change its lane if there is enough physical space on the target lane and if it neither comes to too close to the leader on the target lane nor to its immediate follower on the target lane (too close being defined by the car-following model). If either of these conditions is not met, the vehicle is said to have a blocking leader or a blocking follower.

During each simulation step, the following sub-steps are executed in order for every vehicle:

1. Computation of preferred successor lanes (called bestLanes)
2. Computation of safe velocities under the assumption of staying on the current lane and integration with lane-changing related speed requests from the previous simulation step
3. Lane-changing model computes change request (left, right, stay)
4. Either execute lane-changing maneuver or compute speed request for the next simulation step (involves planning ahead for multiple steps). Whether speed changes are requested depends on the urgency of the lane-changing request.

The sub-steps 3 and 4 are handled by a customizable software component the laneChangingModel. This gives a high amount of configurability within the bounds of the architecture.

Strategic Changes

In SUMO a data structure is computed which allows retrieving the following information necessary for subsequent computations:

1. For every lane on the current edge, a sequence of lanes that can be followed without lane changing up to the next dead-end or to a maximum distance (bestLanes).
2. For every lane on the current edge, the traffic density along the bestLanes (occupation)
3. For every lane on the current edge, the offset in lane index to the lane which is strategically advisable (bestLaneOffset)

A strategic change is deemed urgent if the following relation holds true:

$d - o < lookAheadSpeed \times abs(bestLaneOffset) \times f$

Where the $d$ is the distance to the end of the dead lane, $o$ is a discount due to occupation and $f$ is a factor that encodes the time typically needed to perform a successful change maneuver set to 10 for changing to the left and 20 for changing to the right.

A hierarchy of lane-changing motivations

The four motivations discussed above are considered in a hierarchical fashion as described by the following decision schema. The first statement which applies determines the vehicles change request. In every simulation step, each vehicle first considers changing to the right, and if no change to the right is performed, a change to the left is considered as well. Accordingly, the currently considered direction d is either right (-1) or left (1) according to the resulting change in lane index.

1. Urgent strategic change to d needed: change (strategic)
2. Change to d would create an urgent situation: stay (strategic)
3. Vehicle is a blocking follower for another vehicle with urgent strategic change request: change (cooperative)
4. speedGainProbability above threshold and its sign matches d: change (tactical)
5. keepRightProbability above threshold and d = -1: change (regulatory)
6. non-urgent strategic change to d needed: change (strategic

---