Lane Change design

The Lane Change module is activated when lane change is needed (Ego is not on preferred lane), and activation requirements are satisfied.

Lane Change Requirements

Prerequisites

The type of lane boundary in the HD map has to be one of the following:

• Dashed lane marking: Lane changes are permitted in both directions.
• Dashed marking on the left and solid on the right: Lane changes are allowed from left to right.
• Dashed marking on the right and solid on the left: Lane changes are allowed from right to left.
• allow_lane_change tags is set as true

Activation Conditions

The lane change module will activate under the following conditions :

• The ego-vehicle is NOT on a preferred_lane.
• Distance to start of target_lane is less than maximum_prepare_length
• The ego-vehicle is NOT close to a regulatory element:
  • Distance to next regulatory element is greater than maximum_prepare_length.
  • Considers distance to traffic light. (If param regulation.traffic_light is enabled)
  • Considers distance to crosswalk. (If param regulation.crosswalk is enabled)
  • Considers distance to intersection. (If param regulation.intersection is enabled)

!!! warning

If ego vehicle is stuck, lane change will be enabled near crosswalk/intersection. Ego is considered stuck if it stops more than `stuck_detection.stop_time`. Ego is considered to be stopping if its velocity is smaller than `stuck_detection.velocity`.

The following figure illustrates the logic for checking if lane change is required:

@startuml
skinparam defaultTextAlignment center
skinparam backgroundColor #WHITE

start

if (Is data available AND lanes available) then (no)
  #LightPink:False;
  stop
else (yes)
endif

:Get distance to target lane start;

if (Is dist to target lane start < max prepare dist) then (no)
  #LightPink:False;
  stop
else (yes)
endif

:Get distance to next regulatory element;

if (Is dist to next regulatory element < max prepare dist) then (yes)
  #LightPink:False;
  stop
else (no)
end if

#LightGreen:True;
stop

@enduml

Ready Conditions

• Valid lane change path is found.
• Lane change path is safe; does not collide with other dynamic objects.
• Lane change candidate path is approved by an operator.

Implementation

Lane change module uses a sampling based approach for generating a valid and safe lane changing trajectory. The process for generating the trajectory includes object filtering, metrics sampling, candidate paths generation, and lastly candidate paths evaluation. Additionally the lane change module is responsible for turn signal activation when appropriate, and inserting a stop point when necessary.

Global Flowchart

The following diagram, illustrates the overall flow of the lane change module implementation.

```plantuml @startuml

start

#LightBlue:Update lane change data; #LightBlue:Filter detected objects; if (Is lane change required?) then (yes) #LightBlue:Activate turn signal; #LightBlue:Generate metrics samples; if (Is valid metrics available) then (yes) While (Can generate new candidate path?) is (TRUE) if (Candidate path is valid & safe?) then (yes) #LightBlue:Generate drivable area; #LightBlue:Execute lane change path; while (Can module transit to success state?) is (False) if (Can module trasit to failure state?) then (yes)

File truncated at 100 lines see the full file

Changelog for package autoware_behavior_path_lane_change_module

0.46.0 (2025-06-20)

• Merge remote-tracking branch 'upstream/main' into tmp/TaikiYamada/bump_version_base

• fix(lane_change, behavior_path_planner): fix failure to do lane change (#10694)

  * chore(sync-files.yaml): not synchronize [github-release.yaml]{.title-ref} (#1776) not sync github-release

  • set initial state of LC module to waiting approval, update RTC status when no valid path
  • store deleted modules ptrs in vector
  • revert unnecessary changes

  * Revert "chore(sync-files.yaml): not synchronize [github-release.yaml]{.title-ref} (#1776)" This reverts commit 871a8540ade845c7c9a193029d407b411a4d685b.

  • fix format

  * Update planning/behavior_path_planner/autoware_behavior_path_planner/src/planner_manager.cpp ---------Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>> Co-authored-by: GitHub Action <<action@github.com>> Co-authored-by: Mamoru Sobue <<mamoru.sobue@tier4.jp>>

• feat!: remove obstacle_stop_planner and obstacle_cruise_planner (#10695)

  • feat: remove obstacle_stop_planner and obstacle_cruise_planner
  • update

  * fix

• Contributors: TaikiYamada4, Takayuki Murooka, mkquda

0.45.0 (2025-05-22)

0.44.2 (2025-06-10)

0.44.1 (2025-05-01)

0.44.0 (2025-04-18)

• Merge remote-tracking branch 'origin/main' into humble
• fix(lane_change): set safety factor properly (#10308)
• Contributors: Ryohsuke Mitsudome, Satoshi OTA

0.43.0 (2025-03-21)

• Merge remote-tracking branch 'origin/main' into chore/bump-version-0.43

• chore: rename from [autoware.universe]{.title-ref} to [autoware_universe]{.title-ref} (#10306)

• fix(lane_change_module): fix planning factor issue (#10244)

  • when computing target lanes, don't include preceding lanes of lane change lane
  • dont insert stop point on target lane if next lc dist buffer is zero
  • return previous module output if LC module status is IDLE

  * disable faulty test ---------

• Contributors: Hayato Mizushima, Yutaka Kondo, mkquda

0.42.0 (2025-03-03)

• Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base

• feat(autoware_utils): replace autoware_universe_utils with autoware_utils (#10191)

• chore(lane_change, QC): remove unused function (#10188) chore(lane_change): remove unused function

• fix(lane_change): remove string literals from stopwatch toc (#10121)

• feat(lane_change): improve the calculation of the target lateral velocity in Frenet frame (#10078)

File truncated at 100 lines see the full file