Behavior Path Planner

The Behavior Path Planner’s main objective is to significantly enhance the safety of autonomous vehicles by minimizing the risk of accidents. It improves driving efficiency through time conservation and underpins reliability with its rule-based approach. Additionally, it allows users to integrate their own custom behavior modules or use it with different types of vehicles, such as cars, buses, and delivery robots, as well as in various environments, from busy urban streets to open highways.

The module begins by thoroughly analyzing the ego vehicle’s current situation, including its position, speed, and surrounding environment. This analysis leads to essential driving decisions about lane changes or stopping and subsequently generates a path that is both safe and efficient. It considers road geometry, traffic rules, and dynamic conditions while also incorporating obstacle avoidance to respond to static and dynamic obstacles such as other vehicles, pedestrians, or unexpected roadblocks, ensuring safe navigation.

Moreover, the planner responds to the behavior of other traffic participants, predicting their actions and accordingly adjusting the vehicle’s path. This ensures not only the safety of the autonomous vehicle but also contributes to smooth traffic flow. Its adherence to traffic laws, including speed limits and compliance with traffic signals, further guarantees lawful and predictable driving behavior. The planner is also designed to minimize sudden or abrupt maneuvers, aiming for a comfortable and natural driving experience.

!!! note

The [Planning Component Design](https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-architecture-v1/components/planning/) documentation outlines the foundational philosophy guiding the design and future development of the Behavior Path Planner module. We strongly encourage readers to consult this document to understand the rationale behind its current configuration and the direction of its ongoing development.

Purpose / Use Cases

Essentially, the module has three primary responsibilities:

1. Creating a path based on the traffic situation.
2. Generating drivable area, i.e. the area within which the vehicle can maneuver.
3. Generating turn signal commands to be relayed to the vehicle interface.

Features

Supported Scene Modules

Behavior Path Planner has the following scene modules

!!! Note

Click on the following images to view videos of their execution

<div align="center">
    <table>
        <tr>
            <td><img src="./image/supported_module_lane_following.svg" alt="Lane Following Module" width="300"></td>
            <td><a href="https://www.youtube.com/watch?v=A_V9yvfKZ4E"><img src="./image/supported_module_avoidance.svg" alt="Avoidance Module" width="300"></a></td>
            <td><img src="./image/supported_module_avoidance_by_lane_change.svg" alt="Avoidance by Lane Change Module" width="300"></td>
        </tr>
        <tr>
            <td><a href="https://www.youtube.com/watch?v=0jRDGQ84cD4"><img src="./image/supported_module_lane_change.svg" alt="Lane Change Module" width="300"></a></td>
            <td><a href="https://www.youtube.com/watch?v=xOjnPqoHup4"><img src="./image/supported_module_start_planner.svg" alt="Start Planner Module" width="300"></a></td>
            <td><a href="https://www.youtube.com/watch?v=ornbzkWxRWU"><img src="./image/supported_module_goal_planner.svg" alt="Goal Planner Module" width="300"></a></td>
        </tr>
    </table>
</div>

!!! Note

Users can refer to [Planning component design](https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-architecture-v1/components/planning/#supported-functions) for some additional behavior.

How to add or implement new module

All scene modules are implemented by inheriting the base class scene_module_interface.hpp.

!!! Warning

The remainder of this subsection is a work in progress (WIP).

Planner Manager

The Planner Manager’s responsibilities include:

1. Activating the relevant scene module in response to the specific situation faced by the autonomous vehicle. For example, when a parked vehicle blocks the ego vehicle’s driving lane, the manager would engage the avoidance module.
2. Managing the execution order when multiple modules are running simultaneously. For instance, if both the lane-changing and avoidance modules are operational, the manager decides which should take precedence.
3. Merging paths from multiple modules when they are activated simultaneously and each generates its own path, thereby creating a single functional path.

!!! note

To check the scene module's transition – i.e., registered, approved and candidate modules – set `verbose: true` in the [Behavior Path Planner configuration file](https://github.com/autowarefoundation/autoware_launch/blob/0cd5d891a36ac34a32a417205905c109f2bafe7b/autoware_launch/config/planning/scenario_planning/lane_driving/behavior_planning/behavior_path_planner/behavior_path_planner.param.yaml#L3).

![Scene module's transition table](./image/checking_module_transition.png)

!!! note

For more in-depth information, refer to the [Manager design](./docs/behavior_path_planner_manager_design.md) document.

Inputs / Outputs / API

Input

File truncated at 100 lines see the full file

Changelog for package autoware_behavior_path_planner

0.53.0 (2026-09-29)

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

• fix(design): align the planning node designs with the packages they describe (#13342)

  * fix(design): align the planning node designs with the packages they describe HazardLightsSelector registers as HazardLightsSelector, and its second input maps to input/system/hazard_lights_command and carries the MRM command, so the port is named system_hazard_lights_cmd. SurroundObstacleChecker publishes the migrated autoware_internal_planning_msgs velocity limit types, and creates neither stop_reasons nor no_start_reason. RemainingDistanceTimeCalculator takes its velocity limit input through the design graph; global: keeps a port out of it, since link_manager skips any connection whose target is a global input port and the exporter emits no remap. ExternalVelocityLimitSelector's api_limit is the reverse case: it is published only by AD API adaptors outside the design graph, so it keeps global: alongside its remap_target. #13165 unified the Modifier and Optimizer nodes into TrajectoryProcessor but left both old designs in place, naming plugins, executables and param files that no longer exist, and put the new design in common/autoware_universe_designs, a bare directory that is not a ROS package. The design moves into autoware_trajectory_processor per the convention set by #13102, and its processing_time_detail publisher carries ProcessingTimeTree.

  * feat(autoware_path_sampler): add the packaged path sampler parameter file The package had no config/ directory and its INSTALL_TO_SHARE was commented out, so the parameter file the node design points at lived only in autoware_launch. The file is copied into the package and installed, and the design declares the three shared param files the launcher also passes, which is where ego_nearest_dist_threshold and ego_nearest_yaw_threshold come from.

  * feat(design): add the planning factor publishers to the BehaviorPathPlanner node design The node publishes nine planning factor arrays under /planning/planning_factors that the design did not declare, so nothing could connect them to the evaluator. ---------

• fix(planning, control): point design param_files at the packages that install them (#13219) BehaviorPathPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. PlanningValidator referenced its checker plugins' param files under the host package with a planning_validator_ filename prefix the plugins do not use. TrajectoryFollower referenced config/ where the package installs param/, and controller files that exist per controller type (mpc, pid). ManualLaneChangeHandler declared a param file that does not exist; the node declares no parameters. The run_out module ships a config directory that ament_auto_package() did not install. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

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

• refactor(planning): move node design files into each package (#13102) Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>

• 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(pre-commit): update pre-commit-hooks-ros to v0.10.3 and adapt include guards (#13083)

  • chore: sync files

  * fix(pre-commit): adapt include guards to pre-commit-hooks-ros v0.10.3 ros-include-guard v0.10.3 only recognises an include guard when #endif is the last non-empty line of the file, so that feature test macros are no longer mistaken for guards. 29 headers failed that check. 25 headers wrap the guard in "// clang-format off" / "// clang-format on" because the #endif comment plus its // NOLINT exceeds the 100 column limit. Drop only the trailing "on" marker; the "off" marker then runs to end of file and still protects the line from being wrapped. 3 CUDA headers ended with "/* INDENT-ON /". Move it above the #endif so it stays paired with the "/ INDENT-OFF */" near the top of the file. autoware_behavior_path_planner/test/input.hpp closed its guard immediately after opening it, leaving the entire body unguarded. Move the #endif to the end. Also hold clang-format at v21.1.8.

File truncated at 100 lines see the full file