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.53.0 (2026-09-29)

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

• fix(autoware_behavior_path_static_obstacle_avoidance_module): stop extending lanes forever on a looping road (#13330)

  * fix(autoware_behavior_path_static_obstacle_avoidance_module): stop extending lanes forever on a looping road getExtendLanes() walks getNextLanelets() until the lane sequence reaches forward_path_length ahead of the ego. On a road network that loops back on itself -- a city block, say -- that walk eventually returns a lanelet already in the sequence. Appending it makes the ego project onto the second lap, so the arc coordinate grows in step with the sequence, forward_length never reaches the threshold, and the loop extends the lanes forever: the node spins at 100% of a core inside its own timer callback and publishes no path at all, so planning and control go quiet and the vehicle never moves. Stop when the next lanelet is already in the sequence. There is nothing further ahead for it to reach that the sequence does not already cover, and the walk is now bounded by the number of lanelets it can visit. Found on a Lanelet2 map converted from a CARLA town, where every block loops: the module hung as soon as a route made a lane change possible next to the ego. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Claude-Session: https://claude.ai/code/session_01B5Gc9n8qQgHyNTd3gsow8z

  * test(autoware_behavior_path_static_obstacle_avoidance_module): cover getExtendLanes loop termination Add a regression test for the looping-road hang fixed in this PR. The fixture map test_data/loop_map.osm is a four-lanelet ring (1010 -> 1013 -> 1016 -> 1019 -> 1010) generated so getNextLanelets() forms a cycle; the ego is placed at the ring start, derived from the loaded geometry so the test does not depend on the map projection. With the guard, getExtendLanes() returns the four ring lanelets once. Without it the walk re-appends the ring until forward_path_length, so the assertions (no repeated lanelet id, sequence no longer than the loop) fail cleanly instead of hanging CI. Co-Authored-By: Claude Opus 4.8 (1M context) <<noreply@anthropic.com>>

  * style(pre-commit): autofix ---------Co-authored-by: Atrium Coding Agent <<agent@atrium.local>> Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: Masaya Kataoka <<cld-masaya.kataoka@tier4.jp>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>

• chore: update planning param.yaml comments (#13061) update planning param.yaml comments

• chore(planning): update package maintainers (#13186)

• chore(pre-commit): update clang-format to v22.1.5 (#13126)

  • chore(pre-commit): update clang-format to v22.1.5

  * style(pre-commit): autofix ---------

• fix(static_obstacle_avoidance): prevent crash on empty path in planCandidate (#13008)

  • handle empty path
  • update comment
  • style(pre-commit): autofix

  * doc: better comment ---------Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>

• Contributors: Kento Yabuuchi, Masaya Kataoka, Mete Fatih Cırıt, Ryohsuke Mitsudome, Satoshi OTA, Taeseung Sohn

0.52.0 (2026-06-30)

0.51.0 (2026-05-01)

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

• chore(behavior_path_planner): remove unused lanelet2_extension header (#12292) unused lanelet2_extension in bpp modules Co-authored-by: Mamoru Sobue <<hilo.soblin@gmail.com>>

• feat(static_obstacle_avoidance): implement 'stop_on_approval' policy for candidate path turn signals and add hold duration parameter (#12264)

  • feat(static_obstacle_avoidance): implement 'stop_on_approval' policy for candidate path turn signals and add hold duration

File truncated at 100 lines see the full file