Avoidance module for static objects

Purpose/Role

This is a rule-based avoidance module, which runs based on perception output data, HDMap, current path and route. This module is designed to create avoidance paths for static (=stopped) objects in simple situations. Currently, this module doesn’t support dynamic (=moving) objects.

This module has an RTC interface, and the user can select operation mode from MANUAL/AUTO depending on the performance of the vehicle’s sensors. If the user selects MANUAL mode, this module outputs a candidate avoidance path and awaits operator approval. In the case where the sensor/perception performance is insufficient and false positives occur, we recommend MANUAL mode to prevent unnecessary avoidance maneuvers.

If the user selects AUTO mode, this module modifies the current following path without operator approval. If the sensor/perception performance is sufficient, use AUTO mode.

Limitations

This module allows developers to design vehicle behavior in avoidance planning using specific rules. Due to the property of rule-based planning, the algorithm cannot compensate for not colliding with obstacles in complex cases. This is a trade-off between “be intuitive and easy to design” and “be hard to tune but can handle many cases”. This module adopts the former policy and therefore this output should be checked more strictly in the later stage. In the .iv reference implementation, there is another avoidance module in the motion planning module that uses optimization to handle the avoidance in complex cases. (Note that, the motion planner needs to be adjusted so that the behavior result will not be changed much in the simple case and this is a typical challenge for the behavior-motion hierarchical architecture.)

Why is avoidance in behavior module?

This module executes avoidance over lanes, and the decision requires the lane structure information to take care of traffic rules (e.g. it needs to send an indicator signal when the vehicle crosses a lane). The difference between the motion and behavior modules in the planning stack is whether the planner takes traffic rules into account, which is why this avoidance module exists in the behavior module.

If you would like to know the overview rather than the detail, please skip the next section and refer to FAQ.

Inner workings/Algorithms

This module mainly has two parts, target filtering and path generation. At first, all objects are filtered by several conditions. In this step, the module checks avoidance feasibility and necessity. After that, this module generates avoidance path outline, which we call shift line, based on filtered objects. The shift lines are set into path shifter, which is a library for path generation, to create a smooth shift path. Additionally, this module has a feature to check non-target objects so that the ego can avoid target objects safely. This feature receives a generated avoidance path and surrounding objects, and judges the current situation. Lastly, this module updates current ego behavior.

```plantuml @startuml skinparam monochrome true

title Overall flowchart start

partition updateData() { partition fillFundamentalData() { :update fundamental data; note right

• reference pose
• reference path: generated by spline interpolation of centerline path with dense interval
• current lanelets
• drivable bounds
• avoidance start point calculate the point where the ego should start avoidance maneuver depending on traffic signal.
• avoidance return point calculate the point where the ego should return original lane depending on traffic signal and goal position. end note

:fillAvoidanceTargetObjects(); note right This module checks the following conditions:

• target object type
• being stopped
• being around the ego-driving lane
• being on the edge of the lane
• … end note

:updateRegisteredObject();

:compensateDetectionLost(); }

partition fillShiftLine() { :generate shift line;

:create candidate path;

:check candidate path; note right This module checks following conditions:

• is there enough distance between surrounding moving vehicles and ego path to avoid target safely?
• is the path jerky?
• is the path within drivable area? end note }

partition fillEgoStatus() { :getCurrentModuleState(); note right This module has following status:

• RUNNING: target object is still remaining. Or, the ego hasn’t returned to original lane.
• CANCEL: target object has gone. And, the ego hasn’t initiated avoidance maneuver.
• SUCCEEDED: the ego finishes avoiding all objects and returns to original lane. end note

if (canYieldManeuver()) then (yes) if (Is the avoidance path safe?) then (yes) else (no) :transit yield maneuver; note right Check current situation. This module can transit yield maneuver only when the ego hasn’t initiated avoidance maneuver.

File truncated at 100 lines see the full file

Changelog for package autoware_behavior_path_static_obstacle_avoidance_module

0.50.0 (2026-02-14)

• Merge remote-tracking branch 'origin/main' into humble

• refactor(behavior_path_planner node, common, sampling_planner): replace getClosesetLanelet to handle invalid value (#12017)

• refactor(lane_change, static_obstacle_avoidance): replace getClosesetLanelet, fix undefined behavior for default-initialized Lanelet (#12010)

• fix(behavior_path_static_obstacle_avoidance_module): use polygon intersection (#11939)

• fix(behavior_path_static_obstacle_avoidance_module): intersection no inline (#11928)

• fix(behavior_path_static_obstacle_avoidance_module): avoid dangling pointers (#11927)

• feat(static_obstacle_avoidance): turn signal during yield maneuver (#11778)

  • fix(avoidance): refactor reference path
  • feat(avoidance): enable signaling while avoidance yield
  • feat(avoidance): add parameter for signalling during yield

  * style(pre-commit): autofix ---------Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>

• Contributors: Mamoru Sobue, Mehmet Dogru, Mete Fatih Cırıt, Ryohsuke Mitsudome

0.49.0 (2025-12-30)

• Merge remote-tracking branch 'origin/main' into prepare-0.49.0-changelog

• fix(autoware_behavior_path_static_obstacle_avoidance): remove unnecessary postProcess (#11668)

  • fix(autoware_behavior_path_static_obstacle_avoidance): remove unnecessary postProcess

  * fix turn signal logic ---------

• Contributors: Ryohsuke Mitsudome, Yukinari Hisaki

0.48.0 (2025-11-18)

• Merge remote-tracking branch 'origin/main' into humble

• feat(autoware_lanelet2_utils): replace ported functions from autoware_lanelet2_extension (#11593) Co-authored-by: Mamoru Sobue <<hilo.soblin@gmail.com>>

• fix(staitc_obstacle_avoidance): fix crashes due to an exception (#11591) fix exception

• fix(static_obstacle_avoidance): fix parking violation detection (#11561)

  • fix parking violation detection
  • fix comment

  * fix avoidance condition ---------

• refactor(static_obstacle_avoidance): revert PR #10865 (#11557)

  * Revert "fix(static_obstacle_avoidance): fix filtering logic to avoid vehicle in T-intersection (#10865)" This reverts commit 261e13f6e081734d9373b26c0609ba0da52f53f6.

  * Remove debug output for unknown type object map size Removed debug output for map size in the unknown type object handling.

• fix(static_obstacle_avoidance): fill object info in appropriate location (#11521)

• feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions (#11487)

  • Revert "fix(static_obstacle_avoidance): ensure sufficient avoidance margin on high-curvature paths for parked vehicle

File truncated at 100 lines see the full file