Package Summary
| Tags | No category tags. |
| Version | 0.48.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-12-03 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Tags | planner ros calibration self-driving-car autonomous-driving autonomous-vehicles ros2 3d-map autoware |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Takamasa Horibe
- Zulfaqar Azmi
- Satoshi Ota
- Fumiya Watanabe
- Kyoichi Sugahara
- Tomoya Kimura
- Shumpei Wakabayashi
- Tomohito Ando
- Go Sakayori
- Yukinari Hisaki
- Takumi Odashima
Authors
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.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 avoidance (#10902)"
- feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions
- Updated [calcEnvelopeOverhangDistance]{.title-ref} to include vehicle front and rear overhang parameters for more accurate obstacle avoidance.
- Introduced new utility functions for calculating lateral distances and filling midpoints of polygon edges.
- Improved the logic for determining overhang points based on the updated vehicle dimensions. This change aims to ensure better obstacle avoidance performance by considering the vehicle's physical characteristics.
- fix(test_utils): update overhang distance calculation in tests to include additional parameters
- Modified calls to [calcEnvelopeOverhangDistance]{.title-ref} in multiple test cases to include new parameters for improved accuracy.
- Ensured consistency in testing behavior for obstacle avoidance scenarios. This change aligns the test cases with the recent enhancements made to the overhang distance calculation logic.
- refactor(static_obstacle_avoidance): update utility function calls for lateral distance and midpoint calculations
- refactor(static_obstacle_avoidance): rename utility functions for consistency in naming conventions
- fix(test_utils): update expected output size and values in overhang distance tests
- Adjusted the expected output size from 5 to 8 in the [calcEnvelopeOverhangDistance]{.title-ref} test cases.
- Updated the expected values to reflect changes in the overhang distance calculations for improved accuracy. This change ensures that the tests align with the latest logic in the overhang distance calculations. ---------
-
feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles (#11464)
- feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles
- Introduced new object info for adjacent lane stop vehicles.
- Updated avoidance parameters to include policy for adjacent lane stop vehicles.
- Enhanced logic in helper functions to manage adjacent lane stop vehicle scenarios.
- Modified debug and utility functions to accommodate new conditions. This update improves the obstacle avoidance capabilities by considering vehicles stopped in adjacent lanes.
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_behavior_path_static_obstacle_avoidance_module at Robotics Stack Exchange
Package Summary
| Tags | No category tags. |
| Version | 0.48.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-12-03 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Tags | planner ros calibration self-driving-car autonomous-driving autonomous-vehicles ros2 3d-map autoware |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Takamasa Horibe
- Zulfaqar Azmi
- Satoshi Ota
- Fumiya Watanabe
- Kyoichi Sugahara
- Tomoya Kimura
- Shumpei Wakabayashi
- Tomohito Ando
- Go Sakayori
- Yukinari Hisaki
- Takumi Odashima
Authors
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.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 avoidance (#10902)"
- feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions
- Updated [calcEnvelopeOverhangDistance]{.title-ref} to include vehicle front and rear overhang parameters for more accurate obstacle avoidance.
- Introduced new utility functions for calculating lateral distances and filling midpoints of polygon edges.
- Improved the logic for determining overhang points based on the updated vehicle dimensions. This change aims to ensure better obstacle avoidance performance by considering the vehicle's physical characteristics.
- fix(test_utils): update overhang distance calculation in tests to include additional parameters
- Modified calls to [calcEnvelopeOverhangDistance]{.title-ref} in multiple test cases to include new parameters for improved accuracy.
- Ensured consistency in testing behavior for obstacle avoidance scenarios. This change aligns the test cases with the recent enhancements made to the overhang distance calculation logic.
- refactor(static_obstacle_avoidance): update utility function calls for lateral distance and midpoint calculations
- refactor(static_obstacle_avoidance): rename utility functions for consistency in naming conventions
- fix(test_utils): update expected output size and values in overhang distance tests
- Adjusted the expected output size from 5 to 8 in the [calcEnvelopeOverhangDistance]{.title-ref} test cases.
- Updated the expected values to reflect changes in the overhang distance calculations for improved accuracy. This change ensures that the tests align with the latest logic in the overhang distance calculations. ---------
-
feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles (#11464)
- feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles
- Introduced new object info for adjacent lane stop vehicles.
- Updated avoidance parameters to include policy for adjacent lane stop vehicles.
- Enhanced logic in helper functions to manage adjacent lane stop vehicle scenarios.
- Modified debug and utility functions to accommodate new conditions. This update improves the obstacle avoidance capabilities by considering vehicles stopped in adjacent lanes.
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_behavior_path_static_obstacle_avoidance_module at Robotics Stack Exchange
Package Summary
| Tags | No category tags. |
| Version | 0.48.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-12-03 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Tags | planner ros calibration self-driving-car autonomous-driving autonomous-vehicles ros2 3d-map autoware |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Takamasa Horibe
- Zulfaqar Azmi
- Satoshi Ota
- Fumiya Watanabe
- Kyoichi Sugahara
- Tomoya Kimura
- Shumpei Wakabayashi
- Tomohito Ando
- Go Sakayori
- Yukinari Hisaki
- Takumi Odashima
Authors
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.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 avoidance (#10902)"
- feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions
- Updated [calcEnvelopeOverhangDistance]{.title-ref} to include vehicle front and rear overhang parameters for more accurate obstacle avoidance.
- Introduced new utility functions for calculating lateral distances and filling midpoints of polygon edges.
- Improved the logic for determining overhang points based on the updated vehicle dimensions. This change aims to ensure better obstacle avoidance performance by considering the vehicle's physical characteristics.
- fix(test_utils): update overhang distance calculation in tests to include additional parameters
- Modified calls to [calcEnvelopeOverhangDistance]{.title-ref} in multiple test cases to include new parameters for improved accuracy.
- Ensured consistency in testing behavior for obstacle avoidance scenarios. This change aligns the test cases with the recent enhancements made to the overhang distance calculation logic.
- refactor(static_obstacle_avoidance): update utility function calls for lateral distance and midpoint calculations
- refactor(static_obstacle_avoidance): rename utility functions for consistency in naming conventions
- fix(test_utils): update expected output size and values in overhang distance tests
- Adjusted the expected output size from 5 to 8 in the [calcEnvelopeOverhangDistance]{.title-ref} test cases.
- Updated the expected values to reflect changes in the overhang distance calculations for improved accuracy. This change ensures that the tests align with the latest logic in the overhang distance calculations. ---------
-
feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles (#11464)
- feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles
- Introduced new object info for adjacent lane stop vehicles.
- Updated avoidance parameters to include policy for adjacent lane stop vehicles.
- Enhanced logic in helper functions to manage adjacent lane stop vehicle scenarios.
- Modified debug and utility functions to accommodate new conditions. This update improves the obstacle avoidance capabilities by considering vehicles stopped in adjacent lanes.
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_behavior_path_static_obstacle_avoidance_module at Robotics Stack Exchange
Package Summary
| Tags | No category tags. |
| Version | 0.48.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-12-03 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Tags | planner ros calibration self-driving-car autonomous-driving autonomous-vehicles ros2 3d-map autoware |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Takamasa Horibe
- Zulfaqar Azmi
- Satoshi Ota
- Fumiya Watanabe
- Kyoichi Sugahara
- Tomoya Kimura
- Shumpei Wakabayashi
- Tomohito Ando
- Go Sakayori
- Yukinari Hisaki
- Takumi Odashima
Authors
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.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 avoidance (#10902)"
- feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions
- Updated [calcEnvelopeOverhangDistance]{.title-ref} to include vehicle front and rear overhang parameters for more accurate obstacle avoidance.
- Introduced new utility functions for calculating lateral distances and filling midpoints of polygon edges.
- Improved the logic for determining overhang points based on the updated vehicle dimensions. This change aims to ensure better obstacle avoidance performance by considering the vehicle's physical characteristics.
- fix(test_utils): update overhang distance calculation in tests to include additional parameters
- Modified calls to [calcEnvelopeOverhangDistance]{.title-ref} in multiple test cases to include new parameters for improved accuracy.
- Ensured consistency in testing behavior for obstacle avoidance scenarios. This change aligns the test cases with the recent enhancements made to the overhang distance calculation logic.
- refactor(static_obstacle_avoidance): update utility function calls for lateral distance and midpoint calculations
- refactor(static_obstacle_avoidance): rename utility functions for consistency in naming conventions
- fix(test_utils): update expected output size and values in overhang distance tests
- Adjusted the expected output size from 5 to 8 in the [calcEnvelopeOverhangDistance]{.title-ref} test cases.
- Updated the expected values to reflect changes in the overhang distance calculations for improved accuracy. This change ensures that the tests align with the latest logic in the overhang distance calculations. ---------
-
feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles (#11464)
- feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles
- Introduced new object info for adjacent lane stop vehicles.
- Updated avoidance parameters to include policy for adjacent lane stop vehicles.
- Enhanced logic in helper functions to manage adjacent lane stop vehicle scenarios.
- Modified debug and utility functions to accommodate new conditions. This update improves the obstacle avoidance capabilities by considering vehicles stopped in adjacent lanes.
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_behavior_path_static_obstacle_avoidance_module at Robotics Stack Exchange
Package Summary
| Tags | No category tags. |
| Version | 0.48.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-12-03 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Tags | planner ros calibration self-driving-car autonomous-driving autonomous-vehicles ros2 3d-map autoware |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Takamasa Horibe
- Zulfaqar Azmi
- Satoshi Ota
- Fumiya Watanabe
- Kyoichi Sugahara
- Tomoya Kimura
- Shumpei Wakabayashi
- Tomohito Ando
- Go Sakayori
- Yukinari Hisaki
- Takumi Odashima
Authors
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.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 avoidance (#10902)"
- feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions
- Updated [calcEnvelopeOverhangDistance]{.title-ref} to include vehicle front and rear overhang parameters for more accurate obstacle avoidance.
- Introduced new utility functions for calculating lateral distances and filling midpoints of polygon edges.
- Improved the logic for determining overhang points based on the updated vehicle dimensions. This change aims to ensure better obstacle avoidance performance by considering the vehicle's physical characteristics.
- fix(test_utils): update overhang distance calculation in tests to include additional parameters
- Modified calls to [calcEnvelopeOverhangDistance]{.title-ref} in multiple test cases to include new parameters for improved accuracy.
- Ensured consistency in testing behavior for obstacle avoidance scenarios. This change aligns the test cases with the recent enhancements made to the overhang distance calculation logic.
- refactor(static_obstacle_avoidance): update utility function calls for lateral distance and midpoint calculations
- refactor(static_obstacle_avoidance): rename utility functions for consistency in naming conventions
- fix(test_utils): update expected output size and values in overhang distance tests
- Adjusted the expected output size from 5 to 8 in the [calcEnvelopeOverhangDistance]{.title-ref} test cases.
- Updated the expected values to reflect changes in the overhang distance calculations for improved accuracy. This change ensures that the tests align with the latest logic in the overhang distance calculations. ---------
-
feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles (#11464)
- feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles
- Introduced new object info for adjacent lane stop vehicles.
- Updated avoidance parameters to include policy for adjacent lane stop vehicles.
- Enhanced logic in helper functions to manage adjacent lane stop vehicle scenarios.
- Modified debug and utility functions to accommodate new conditions. This update improves the obstacle avoidance capabilities by considering vehicles stopped in adjacent lanes.
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_behavior_path_static_obstacle_avoidance_module at Robotics Stack Exchange
Package Summary
| Tags | No category tags. |
| Version | 0.48.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-12-03 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Tags | planner ros calibration self-driving-car autonomous-driving autonomous-vehicles ros2 3d-map autoware |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Takamasa Horibe
- Zulfaqar Azmi
- Satoshi Ota
- Fumiya Watanabe
- Kyoichi Sugahara
- Tomoya Kimura
- Shumpei Wakabayashi
- Tomohito Ando
- Go Sakayori
- Yukinari Hisaki
- Takumi Odashima
Authors
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.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 avoidance (#10902)"
- feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions
- Updated [calcEnvelopeOverhangDistance]{.title-ref} to include vehicle front and rear overhang parameters for more accurate obstacle avoidance.
- Introduced new utility functions for calculating lateral distances and filling midpoints of polygon edges.
- Improved the logic for determining overhang points based on the updated vehicle dimensions. This change aims to ensure better obstacle avoidance performance by considering the vehicle's physical characteristics.
- fix(test_utils): update overhang distance calculation in tests to include additional parameters
- Modified calls to [calcEnvelopeOverhangDistance]{.title-ref} in multiple test cases to include new parameters for improved accuracy.
- Ensured consistency in testing behavior for obstacle avoidance scenarios. This change aligns the test cases with the recent enhancements made to the overhang distance calculation logic.
- refactor(static_obstacle_avoidance): update utility function calls for lateral distance and midpoint calculations
- refactor(static_obstacle_avoidance): rename utility functions for consistency in naming conventions
- fix(test_utils): update expected output size and values in overhang distance tests
- Adjusted the expected output size from 5 to 8 in the [calcEnvelopeOverhangDistance]{.title-ref} test cases.
- Updated the expected values to reflect changes in the overhang distance calculations for improved accuracy. This change ensures that the tests align with the latest logic in the overhang distance calculations. ---------
-
feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles (#11464)
- feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles
- Introduced new object info for adjacent lane stop vehicles.
- Updated avoidance parameters to include policy for adjacent lane stop vehicles.
- Enhanced logic in helper functions to manage adjacent lane stop vehicle scenarios.
- Modified debug and utility functions to accommodate new conditions. This update improves the obstacle avoidance capabilities by considering vehicles stopped in adjacent lanes.
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_behavior_path_static_obstacle_avoidance_module at Robotics Stack Exchange
Package Summary
| Tags | No category tags. |
| Version | 0.48.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-12-03 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Tags | planner ros calibration self-driving-car autonomous-driving autonomous-vehicles ros2 3d-map autoware |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Takamasa Horibe
- Zulfaqar Azmi
- Satoshi Ota
- Fumiya Watanabe
- Kyoichi Sugahara
- Tomoya Kimura
- Shumpei Wakabayashi
- Tomohito Ando
- Go Sakayori
- Yukinari Hisaki
- Takumi Odashima
Authors
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.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 avoidance (#10902)"
- feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions
- Updated [calcEnvelopeOverhangDistance]{.title-ref} to include vehicle front and rear overhang parameters for more accurate obstacle avoidance.
- Introduced new utility functions for calculating lateral distances and filling midpoints of polygon edges.
- Improved the logic for determining overhang points based on the updated vehicle dimensions. This change aims to ensure better obstacle avoidance performance by considering the vehicle's physical characteristics.
- fix(test_utils): update overhang distance calculation in tests to include additional parameters
- Modified calls to [calcEnvelopeOverhangDistance]{.title-ref} in multiple test cases to include new parameters for improved accuracy.
- Ensured consistency in testing behavior for obstacle avoidance scenarios. This change aligns the test cases with the recent enhancements made to the overhang distance calculation logic.
- refactor(static_obstacle_avoidance): update utility function calls for lateral distance and midpoint calculations
- refactor(static_obstacle_avoidance): rename utility functions for consistency in naming conventions
- fix(test_utils): update expected output size and values in overhang distance tests
- Adjusted the expected output size from 5 to 8 in the [calcEnvelopeOverhangDistance]{.title-ref} test cases.
- Updated the expected values to reflect changes in the overhang distance calculations for improved accuracy. This change ensures that the tests align with the latest logic in the overhang distance calculations. ---------
-
feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles (#11464)
- feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles
- Introduced new object info for adjacent lane stop vehicles.
- Updated avoidance parameters to include policy for adjacent lane stop vehicles.
- Enhanced logic in helper functions to manage adjacent lane stop vehicle scenarios.
- Modified debug and utility functions to accommodate new conditions. This update improves the obstacle avoidance capabilities by considering vehicles stopped in adjacent lanes.
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_behavior_path_static_obstacle_avoidance_module at Robotics Stack Exchange
Package Summary
| Tags | No category tags. |
| Version | 0.48.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-12-03 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Tags | planner ros calibration self-driving-car autonomous-driving autonomous-vehicles ros2 3d-map autoware |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Takamasa Horibe
- Zulfaqar Azmi
- Satoshi Ota
- Fumiya Watanabe
- Kyoichi Sugahara
- Tomoya Kimura
- Shumpei Wakabayashi
- Tomohito Ando
- Go Sakayori
- Yukinari Hisaki
- Takumi Odashima
Authors
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.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 avoidance (#10902)"
- feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions
- Updated [calcEnvelopeOverhangDistance]{.title-ref} to include vehicle front and rear overhang parameters for more accurate obstacle avoidance.
- Introduced new utility functions for calculating lateral distances and filling midpoints of polygon edges.
- Improved the logic for determining overhang points based on the updated vehicle dimensions. This change aims to ensure better obstacle avoidance performance by considering the vehicle's physical characteristics.
- fix(test_utils): update overhang distance calculation in tests to include additional parameters
- Modified calls to [calcEnvelopeOverhangDistance]{.title-ref} in multiple test cases to include new parameters for improved accuracy.
- Ensured consistency in testing behavior for obstacle avoidance scenarios. This change aligns the test cases with the recent enhancements made to the overhang distance calculation logic.
- refactor(static_obstacle_avoidance): update utility function calls for lateral distance and midpoint calculations
- refactor(static_obstacle_avoidance): rename utility functions for consistency in naming conventions
- fix(test_utils): update expected output size and values in overhang distance tests
- Adjusted the expected output size from 5 to 8 in the [calcEnvelopeOverhangDistance]{.title-ref} test cases.
- Updated the expected values to reflect changes in the overhang distance calculations for improved accuracy. This change ensures that the tests align with the latest logic in the overhang distance calculations. ---------
-
feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles (#11464)
- feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles
- Introduced new object info for adjacent lane stop vehicles.
- Updated avoidance parameters to include policy for adjacent lane stop vehicles.
- Enhanced logic in helper functions to manage adjacent lane stop vehicle scenarios.
- Modified debug and utility functions to accommodate new conditions. This update improves the obstacle avoidance capabilities by considering vehicles stopped in adjacent lanes.
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_behavior_path_static_obstacle_avoidance_module at Robotics Stack Exchange
Package Summary
| Tags | No category tags. |
| Version | 0.48.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-12-03 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Tags | planner ros calibration self-driving-car autonomous-driving autonomous-vehicles ros2 3d-map autoware |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Takamasa Horibe
- Zulfaqar Azmi
- Satoshi Ota
- Fumiya Watanabe
- Kyoichi Sugahara
- Tomoya Kimura
- Shumpei Wakabayashi
- Tomohito Ando
- Go Sakayori
- Yukinari Hisaki
- Takumi Odashima
Authors
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.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 avoidance (#10902)"
- feat(static_obstacle_avoidance): enhance overhang distance calculation with vehicle dimensions
- Updated [calcEnvelopeOverhangDistance]{.title-ref} to include vehicle front and rear overhang parameters for more accurate obstacle avoidance.
- Introduced new utility functions for calculating lateral distances and filling midpoints of polygon edges.
- Improved the logic for determining overhang points based on the updated vehicle dimensions. This change aims to ensure better obstacle avoidance performance by considering the vehicle's physical characteristics.
- fix(test_utils): update overhang distance calculation in tests to include additional parameters
- Modified calls to [calcEnvelopeOverhangDistance]{.title-ref} in multiple test cases to include new parameters for improved accuracy.
- Ensured consistency in testing behavior for obstacle avoidance scenarios. This change aligns the test cases with the recent enhancements made to the overhang distance calculation logic.
- refactor(static_obstacle_avoidance): update utility function calls for lateral distance and midpoint calculations
- refactor(static_obstacle_avoidance): rename utility functions for consistency in naming conventions
- fix(test_utils): update expected output size and values in overhang distance tests
- Adjusted the expected output size from 5 to 8 in the [calcEnvelopeOverhangDistance]{.title-ref} test cases.
- Updated the expected values to reflect changes in the overhang distance calculations for improved accuracy. This change ensures that the tests align with the latest logic in the overhang distance calculations. ---------
-
feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles (#11464)
- feat(static_obstacle_avoidance): add handling for adjacent lane stop vehicles
- Introduced new object info for adjacent lane stop vehicles.
- Updated avoidance parameters to include policy for adjacent lane stop vehicles.
- Enhanced logic in helper functions to manage adjacent lane stop vehicle scenarios.
- Modified debug and utility functions to accommodate new conditions. This update improves the obstacle avoidance capabilities by considering vehicles stopped in adjacent lanes.
File truncated at 100 lines see the full file