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.47.0 (2025-08-11)

• fix(static_obstacle_avoidance): fix coding error (#11106)

• style(pre-commit): update to clang-format-20 (#11088) Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

• fix(autoware_behavior_path_static_obstacle_avoidance_module): prevent chattering in avoidance decision (#11046) Revert "fix(autoware_behavior_path_static_obstacle_avoidance_module): prevent chattering in avoidance decision" This reverts commit 6b0d5865dc90add124c4f15c7d995ac3c95d9812. update

• fix(static_obstacle_avoidance): correct lane departure check during obstacle avoidance (#11032)

• fix(static_obstacle_avoidance): load missing unstable classification parameter (#11035) fix(static_obstacle_avoidance): load unstable_classification_time

• style(pre-commit): autofix (#10982) Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

• fix(behavior_path_static_obstacle_avoidance_module): fix isWithinLanes (#10948)

  • fix(behavior_path_static_obstacle_avoidance_module): fix isWithinLanes

  * Update planning/behavior_path_planner/autoware_behavior_path_static_obstacle_avoidance_module/src/utils.cpp Co-authored-by: Go Sakayori <<go-sakayori@users.noreply.github.com>> ---------Co-authored-by: Go Sakayori <<go-sakayori@users.noreply.github.com>>

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

  • fix: curvature based addtional margin
  • fix: calculate proper overhang point
  • fix: set offset to 0.0 when vehicle front overhangs beyond path end

  * fix: test ---------

• fix(static_obstacle_avoidance): planning factor publish condition and control points duplication (#10940)

  • fix planning factor publish condition and control points duplication

  * fix coding style and access method for vector ---------

• feat(static_obstacle_avoidance): add infomation to PlanningFactor topic (#10836)

  • feat(static_obstacle_avoidance): add planning factor test
  • feat(static_obstacle_avoidance): add infomation of planning_factor_interface_
  • delete unnecessary file for test.
  • refactor some variables.

  * fix planning factor test namespace ---------

• fix(static_obstacle_avoidance): fix coding error (#10890) fix error

• feat(static_obstacle_avoidance): support separate lateral jerk constraints for avoidance and return maneuvers (#10870)

  • feat(static_obstacle_avoidance): support separate lateral jerk constraints for avoidance and return maneuvers
  • chore: renaming function
  • chore: rewrite comment

  * fix: json ---------

• fix(static_obstacle_avoidance): fix filtering logic to avoid vehicle in T-intersection (#10865)

• Contributors: Kotakku, Mete Fatih Cırıt, Ryohsuke Mitsudome, Satoshi

File truncated at 100 lines see the full file