No version for distro humble. Known supported distros are highlighted in the buttons above.
No version for distro jazzy. Known supported distros are highlighted in the buttons above.
No version for distro rolling. Known supported distros are highlighted in the buttons above.

autoware_behavior_path_planner package from autoware_universe repo

autoware_adapi_specs autoware_agnocast_wrapper autoware_auto_common autoware_component_interface_specs_universe autoware_component_interface_tools autoware_component_interface_utils autoware_cuda_dependency_meta autoware_fake_test_node autoware_glog_component autoware_goal_distance_calculator autoware_grid_map_utils autoware_path_distance_calculator autoware_polar_grid autoware_time_utils autoware_traffic_light_recognition_marker_publisher autoware_traffic_light_utils autoware_universe_utils tier4_api_utils autoware_autonomous_emergency_braking autoware_collision_detector autoware_control_performance_analysis autoware_control_validator autoware_external_cmd_selector autoware_joy_controller autoware_lane_departure_checker autoware_mpc_lateral_controller autoware_obstacle_collision_checker autoware_operation_mode_transition_manager autoware_pid_longitudinal_controller autoware_predicted_path_checker autoware_pure_pursuit autoware_shift_decider autoware_smart_mpc_trajectory_follower autoware_trajectory_follower_base autoware_trajectory_follower_node autoware_vehicle_cmd_gate autoware_control_evaluator autoware_kinematic_evaluator autoware_localization_evaluator autoware_perception_online_evaluator autoware_planning_evaluator autoware_scenario_simulator_v2_adapter tier4_autoware_api_launch tier4_control_launch tier4_localization_launch tier4_map_launch tier4_perception_launch tier4_planning_launch tier4_sensing_launch tier4_simulator_launch tier4_system_launch tier4_vehicle_launch autoware_geo_pose_projector autoware_gyro_odometer autoware_ar_tag_based_localizer autoware_landmark_manager autoware_lidar_marker_localizer autoware_localization_error_monitor autoware_ndt_scan_matcher autoware_pose2twist autoware_pose_covariance_modifier autoware_pose_estimator_arbiter autoware_pose_initializer autoware_pose_instability_detector yabloc_common yabloc_image_processing yabloc_monitor yabloc_particle_filter yabloc_pose_initializer autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_tf_generator autoware_bytetrack autoware_cluster_merger autoware_compare_map_segmentation autoware_crosswalk_traffic_light_estimator autoware_detected_object_feature_remover autoware_detected_object_validation autoware_detection_by_tracker autoware_elevation_map_loader autoware_euclidean_cluster autoware_ground_segmentation autoware_image_projection_based_fusion autoware_lidar_apollo_instance_segmentation autoware_lidar_centerpoint autoware_lidar_transfusion autoware_map_based_prediction autoware_multi_object_tracker autoware_object_merger autoware_object_range_splitter autoware_object_velocity_splitter autoware_occupancy_grid_map_outlier_filter autoware_probabilistic_occupancy_grid_map autoware_radar_crossing_objects_noise_filter autoware_radar_fusion_to_detected_object autoware_radar_object_clustering autoware_radar_object_tracker autoware_radar_tracks_msgs_converter autoware_raindrop_cluster_filter autoware_shape_estimation autoware_simple_object_merger autoware_tensorrt_classifier autoware_tensorrt_common autoware_tensorrt_yolox autoware_tracking_object_merger autoware_traffic_light_arbiter autoware_traffic_light_category_merger autoware_traffic_light_classifier autoware_traffic_light_fine_detector autoware_traffic_light_map_based_detector autoware_traffic_light_multi_camera_fusion autoware_traffic_light_occlusion_predictor autoware_traffic_light_selector autoware_traffic_light_visualization perception_utils autoware_costmap_generator autoware_external_velocity_limit_selector autoware_freespace_planner autoware_freespace_planning_algorithms autoware_mission_planner_universe autoware_obstacle_cruise_planner autoware_obstacle_stop_planner autoware_path_optimizer autoware_path_smoother autoware_planning_validator autoware_remaining_distance_time_calculator autoware_rtc_interface autoware_scenario_selector autoware_surround_obstacle_checker autoware_behavior_path_avoidance_by_lane_change_module autoware_behavior_path_dynamic_obstacle_avoidance_module autoware_behavior_path_external_request_lane_change_module autoware_behavior_path_goal_planner_module autoware_behavior_path_lane_change_module autoware_behavior_path_planner autoware_behavior_path_planner_common autoware_behavior_path_sampling_planner_module autoware_behavior_path_side_shift_module autoware_behavior_path_start_planner_module autoware_behavior_path_static_obstacle_avoidance_module autoware_behavior_velocity_blind_spot_module autoware_behavior_velocity_crosswalk_module autoware_behavior_velocity_detection_area_module autoware_behavior_velocity_intersection_module autoware_behavior_velocity_no_drivable_lane_module autoware_behavior_velocity_no_stopping_area_module autoware_behavior_velocity_occlusion_spot_module autoware_behavior_velocity_rtc_interface autoware_behavior_velocity_run_out_module autoware_behavior_velocity_speed_bump_module autoware_behavior_velocity_template_module autoware_behavior_velocity_traffic_light_module autoware_behavior_velocity_virtual_traffic_light_module autoware_behavior_velocity_walkway_module autoware_motion_velocity_dynamic_obstacle_stop_module autoware_motion_velocity_obstacle_cruise_module autoware_motion_velocity_obstacle_slow_down_module autoware_motion_velocity_obstacle_velocity_limiter_module autoware_motion_velocity_out_of_lane_module autoware_bezier_sampler autoware_frenet_planner autoware_path_sampler autoware_sampler_common autoware_cuda_pointcloud_preprocessor autoware_cuda_utils autoware_image_diagnostics autoware_image_transport_decompressor autoware_imu_corrector autoware_pcl_extensions autoware_pointcloud_preprocessor autoware_radar_scan_to_pointcloud2 autoware_radar_static_pointcloud_filter autoware_radar_threshold_filter autoware_radar_tracks_noise_filter autoware_livox_tag_filter autoware_carla_interface autoware_dummy_perception_publisher autoware_fault_injection autoware_learning_based_vehicle_model autoware_simple_planning_simulator autoware_vehicle_door_simulator tier4_dummy_object_rviz_plugin autoware_bluetooth_monitor autoware_component_monitor autoware_component_state_monitor autoware_default_adapi autoware_adapi_adaptors autoware_adapi_visualizers autoware_automatic_pose_initializer autoware_diagnostic_graph_aggregator autoware_diagnostic_graph_utils autoware_dummy_diag_publisher autoware_dummy_infrastructure autoware_duplicated_node_checker autoware_hazard_status_converter autoware_mrm_comfortable_stop_operator autoware_mrm_emergency_stop_operator autoware_mrm_handler autoware_processing_time_checker autoware_system_diagnostic_monitor autoware_system_monitor autoware_topic_relay_controller autoware_topic_state_monitor autoware_velodyne_monitor reaction_analyzer autoware_accel_brake_map_calibrator autoware_external_cmd_converter autoware_raw_vehicle_cmd_converter autoware_steer_offset_estimator autoware_bag_time_manager_rviz_plugin autoware_mission_details_overlay_rviz_plugin autoware_overlay_rviz_plugin autoware_string_stamped_rviz_plugin autoware_perception_rviz_plugin tier4_adapi_rviz_plugin tier4_camera_view_rviz_plugin tier4_datetime_rviz_plugin tier4_localization_rviz_plugin tier4_planning_factor_rviz_plugin tier4_planning_rviz_plugin tier4_state_rviz_plugin tier4_system_rviz_plugin tier4_traffic_light_rviz_plugin tier4_vehicle_rviz_plugin

Package Summary

Tags No category tags.
Version 0.43.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_universe.git
VCS Type git
VCS Version main
Last Updated 2025-04-03
Dev Status UNMAINTAINED
CI status No Continuous Integration
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Package Description

The behavior_path_planner package

Additional Links

No additional links.

Maintainers

  • Zulfaqar Azmi
  • Fumiya Watanabe
  • Kyoichi Sugahara
  • Tomoya Kimura
  • Shumpei Wakabayashi
  • Tomohito Ando
  • Takamasa Horibe
  • Satoshi Ota
  • Kosuke Takeuchi
  • Kyoichi Sugahara
  • Takayuki Murooka
  • Go Sakayori
  • Mamoru Sobue

Authors

  • Takamasa Horibe
  • Satoshi Ota
  • Fumiya Watanabe
  • Zulfaqar Azmi
  • Kosuke Takeuchi
  • Takayuki Murooka
  • Ryohsuke Mitsudome

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/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

Name Description Details
Lane Following This module generates a reference path from lanelet centerline. LINK
Static Obstacle Avoidance This module generates an avoidance path when there are objects that should be avoided. LINK
Dynamic Obstacle Avoidance WIP LINK
Avoidance By Lane Change This module generates a lane change path when there are objects that should be avoided. LINK
Lane Change This module is performed when it is necessary and a collision check with other vehicles is cleared. LINK
External Lane Change WIP LINK
Goal Planner This module is performed when the ego vehicle is in a driving lane and the goal is in the shoulder lane. The ego vehicle will stop at the goal. LINK
Start Planner This module is performed when the ego vehicle is stationary and the footprint of the ego vehicle is included in the shoulder lane. This module ends when the ego vehicle merges into the road. LINK
Side Shift This module shifts the path to the left or right based on external instructions, intended for remote control applications. LINK

!!! 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/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

Name Required? Type Description
~/input/odometry nav_msgs::msg::Odometry For ego velocity
~/input/accel geometry_msgs::msg::AccelWithCovarianceStamped For ego acceleration
~/input/objects autoware_perception_msgs::msg::PredictedObjects Dynamic objects from the perception module
~/input/occupancy_grid_map nav_msgs::msg::OccupancyGrid Occupancy grid map from the perception module. This is used for only the Goal Planner module
~/input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray Traffic signal information from the perception module
~/input/vector_map autoware_map_msgs::msg::LaneletMapBin Vector map information
~/input/route autoware_planning_msgs::msg::LaneletRoute Current route from start to goal
~/input/scenario autoware_internal_planning_msgs::msg::Scenario Launches Behavior Path Planner if current scenario == Scenario:LaneDriving
~/input/lateral_offset tier4_planning_msgs::msg::LateralOffset Lateral offset to trigger side shift
~/system/operation_mode/state autoware_adapi_v1_msgs::msg::OperationModeState Allows the planning module to know if vehicle is in autonomous mode or if it can be controlledref
  • ○ Mandatory: The planning module would not work if anyone of these were not present.
  • △ Optional: Some modules would not work, but the planning module can still be operated.

Output

Name Type Description QoS Durability
~/output/path autoware_internal_planning_msgs::msg::PathWithLaneId The path generated by modules volatile
~/output/turn_indicators_cmd autoware_vehicle_msgs::msg::TurnIndicatorsCommand Turn indicators command volatile
~/output/hazard_lights_cmd autoware_vehicle_msgs::msg::HazardLightsCommand Hazard lights command volatile
~/output/modified_goal autoware_planning_msgs::msg::PoseWithUuidStamped Output modified goal commands transient_local
~/output/reroute_availability tier4_planning_msgs::msg::RerouteAvailability The path the module is about to take. To be executed as soon as external approval is obtained volatile

Debug

Name Type Description QoS Durability
~/debug/avoidance_debug_message_array tier4_planning_msgs::msg::AvoidanceDebugMsgArray Debug message for avoidance. Notifies users of reasons avoidance path cannot be generated volatile
~/debug/lane_change_debug_message_array tier4_planning_msgs::msg::LaneChangeDebugMsgArray Debug message for lane change. Notifies users of unsafe conditions during lane-changing process volatile
~/debug/maximum_drivable_area visualization_msgs::msg::MarkerArray Shows maximum static drivable area volatile
~/debug/turn_signal_info visualization_msgs::msg::MarkerArray TBA volatile
~/debug/bound visualization_msgs::msg::MarkerArray Debug for static drivable area volatile
~/planning/path_candidate/* autoware_planning_msgs::msg::Path The path before approval volatile
~/planning/path_reference/* autoware_planning_msgs::msg::Path Reference path generated by each module volatile

!!! note

For specific information about which topics are being subscribed to and published, refer to [behavior_path_planner.xml](https://github.com/autowarefoundation/autoware_universe/blob/9000f430c937764c14e43109539302f1f878ed70/planning/behavior_path_planner/launch/behavior_path_planner.launch.xml#L36-L49).

How to Enable or Disable Modules

Enabling and disabling the modules in the Behavior Path Planner is primarily managed through two key files: default_preset.yaml and behavior_path_planner.launch.xml.

The default_preset.yaml file acts as a configuration file for enabling or disabling specific modules within the planner. It contains a series of arguments which represent the Behavior Path Planner’s modules or features. For example:

  • launch_static_obstacle_avoidance_module: Set to true to enable the avoidance module, or false to disable it.

!!! note

Click [here](https://github.com/autowarefoundation/autoware_launch/blob/main/autoware_launch/config/planning/preset/default_preset.yaml) to view the `default_preset.yaml`.

The behavior_path_planner.launch.xml file references the settings defined in default_preset.yaml to apply the configurations when the Behavior Path Planner’s node is running. For instance, the parameter static_obstacle_avoidance.enable_module in the following segment corresponds to launch_static_obstacle_avoidance_module from default_preset.yaml:

<param name="static_obstacle_avoidance.enable_module" value="$(var launch_static_obstacle_avoidance_module)"/>

Therefore, to enable or disable a module, simply set the corresponding module in default_preset.yaml to true or false. These changes will be applied upon the next launch of Autoware.

Generating Path

A sophisticated methodology is used for path generation, particularly focusing on maneuvers like lane changes and avoidance. At the core of this design is the smooth lateral shifting of the reference path, achieved through a constant-jerk profile. This approach ensures a consistent rate of change in acceleration, facilitating smooth transitions and minimizing abrupt changes in lateral dynamics, crucial for passenger comfort and safety.

The design involves complex mathematical formulations for calculating the lateral shift of the vehicle’s path over time. These calculations include determining lateral displacement, velocity, and acceleration, while considering the vehicle’s lateral acceleration and velocity limits. This is essential for ensuring that the vehicle’s movements remain safe and manageable.

The ShiftLine struct (as seen here) is utilized to represent points along the path where the lateral shift starts and ends. It includes details like the start and end points in absolute coordinates, the relative shift lengths at these points compared to the reference path, and the associated indexes on the reference path. This struct is integral to managing the path shifts, as it allows the path planner to dynamically adjust the trajectory based on the vehicle’s current position and planned maneuver.

Furthermore, the design and its implementation incorporate various equations and mathematical models to calculate essential parameters for the path shift. These include the total distance of the lateral shift, the maximum allowable lateral acceleration and jerk, and the total time required for the shift. Practical considerations are also noted, such as simplifying assumptions in the absence of a specific time interval for most lane change and avoidance cases.

The shifted path generation logic enables the Behavior Path Planner to dynamically generate safe and efficient paths, precisely controlling the vehicle’s lateral movements to ensure the smooth execution of lane changes and avoidance maneuvers. This careful planning and execution adhere to the vehicle’s dynamic capabilities and safety constraints, maximizing efficiency and safety in autonomous vehicle navigation.

!!! note

If you're a math lover, refer to [Path Generation Design](../autoware_behavior_path_planner_common/docs/behavior_path_planner_path_generation_design.md) for the nitty-gritty.

Collision Assessment / Safety Check

The purpose of the collision assessment function in the Behavior Path Planner is to evaluate the potential for collisions with target objects across all modules. It is utilized in two scenarios:

  1. During candidate path generation, to ensure that the generated candidate path is collision-free.
  2. When the path is approved by the manager, and the ego vehicle is executing the current module. If the current situation is deemed unsafe, depending on each module’s requirements, the planner will either cancel the execution or opt to execute another module.

The safety check process involves several steps. Initially, it obtains the pose of the target object at a specific time, typically through interpolation of the predicted path. It then checks for any overlap between the ego vehicle and the target object at this time. If an overlap is detected, the path is deemed unsafe. The function also identifies which vehicle is in front by using the arc length along the given path. The function operates under the assumption that accurate data on the position, velocity, and shape of both the ego vehicle (the autonomous vehicle) and any target objects are available. It also relies on the yaw angle of each point in the predicted paths of these objects, which is expected to point towards the next path point.

A critical part of the safety check is the calculation of the RSS (Responsibility-Sensitive Safety) distance-inspired algorithm. This algorithm considers factors such as reaction time, safety time margin, and the velocities and decelerations of both vehicles. Extended object polygons are created for both the ego and target vehicles. Notably, the rear object’s polygon is extended by the RSS distance longitudinally and by a lateral margin. The function finally checks for overlap between this extended rear object polygon and the front object polygon. Any overlap indicates a potential unsafe situation.

However, the module does have a limitation concerning the yaw angle of each point in the predicted paths of target objects, which may not always accurately point to the next point, leading to potential inaccuracies in some edge cases.

!!! note

For further reading on the collision assessment  method, please refer to [Safety check utils](../autoware_behavior_path_planner_common/docs/behavior_path_planner_safety_check.md)

Generating Drivable Area

Static Drivable Area logic

The drivable area is used to determine the area in which the ego vehicle can travel. The primary goal of static drivable area expansion is to ensure safe travel by generating an area that encompasses only the necessary spaces for the vehicle’s current behavior, while excluding non-essential areas. For example, while avoidance module is running, the drivable area includes additional space needed for maneuvers around obstacles, and it limits the behavior by not extending the avoidance path outside of lanelet areas.

Before expansion
After expansion

Static drivable area expansion operates under assumptions about the correct arrangement of lanes and the coverage of both the front and rear of the vehicle within the left and right boundaries. Key parameters for drivable area generation include extra footprint offsets for the ego vehicle, the handling of dynamic objects, maximum expansion distance, and specific methods for expansion. Additionally, since each module generates its own drivable area, before passing it as the input to generate the next running module’s drivable area, or before generating a unified drivable area, the system sorts drivable lanes based on the vehicle’s passage order. This ensures the correct definition of the lanes used in drivable area generation.

!!! note

Further details can be found in [Drivable Area Design](../autoware_behavior_path_planner_common/docs/behavior_path_planner_drivable_area_design.md).

Dynamic Drivable Area Logic

Large vehicles require much more space, which sometimes causes them to veer out of their current lane. A typical example being a bus making a turn at a corner. In such cases, relying on a static drivable area is insufficient, since the static method depends on lane information provided by high-definition maps. To overcome the limitations of the static approach, the dynamic drivable area expansion algorithm adjusts the navigable space for an autonomous vehicle in real-time. It conserves computational power by reusing previously calculated path data, updating only when there is a significant change in the vehicle’s position. The system evaluates the minimum lane width necessary to accommodate the vehicle’s turning radius and other dynamic factors. It then calculates the optimal expansion of the drivable area’s boundaries to ensure there is adequate space for safe maneuvering, taking into account the vehicle’s path curvature. The rate at which these boundaries can expand or contract is moderated to maintain stability in the vehicle’s navigation. The algorithm aims to maximize the drivable space while avoiding fixed obstacles and adhering to legal driving limits. Finally, it applies these boundary adjustments and smooths out the path curvature calculations to ensure a safe and legally compliant navigable path is maintained throughout the vehicle’s operation.

!!! note

The feature can be enabled in the [drivable_area_expansion.param.yaml](https://github.com/autowarefoundation/autoware_launch/blob/0cd5d891a36ac34a32a417205905c109f2bafe7b/autoware_launch/config/planning/scenario_planning/lane_driving/behavior_planning/behavior_path_planner/drivable_area_expansion.param.yaml#L10).

Generating Turn Signal

The Behavior Path Planner module uses the autoware_vehicle_msgs::msg::TurnIndicatorsCommand to output turn signal commands (see TurnIndicatorsCommand.idl). The system evaluates the driving context and determines when to activate turn signals based on its maneuver planning—like turning, lane changing, or obstacle avoidance.

Within this framework, the system differentiates between desired and required blinker activations. Desired activations are those recommended by traffic laws for typical driving scenarios, such as signaling before a lane change or turn. Required activations are those that are deemed mandatory for safety reasons, like signaling an abrupt lane change to avoid an obstacle.

The TurnIndicatorsCommand message structure has a command field that can take one of several constants: NO_COMMAND indicates no signal is necessary, DISABLE to deactivate signals, ENABLE_LEFT to signal a left turn, and ENABLE_RIGHT to signal a right turn. The Behavior Path Planner sends these commands at the appropriate times, based on its rules-based system that considers both the desired and required scenarios for blinker activation.

!!! note

For more in-depth information, refer to [Turn Signal Design](../autoware_behavior_path_planner_common/docs/behavior_path_planner_turn_signal_design.md) document.

Rerouting

!!! warning

The rerouting feature is under development. Further information will be included at a later date.

Parameters and Configuration

The configuration files are organized in a hierarchical directory structure for ease of navigation and management. Each subdirectory contains specific configuration files relevant to its module. The root directory holds general configuration files that apply to the overall behavior of the planner. The following is an overview of the directory structure with the respective configuration files.

behavior_path_planner
├── behavior_path_planner.param.yaml
├── drivable_area_expansion.param.yaml
├── scene_module_manager.param.yaml
├── static_obstacle_avoidance
│   └── static_obstacle_avoidance.param.yaml
├── avoidance_by_lc
│   └── avoidance_by_lc.param.yaml
├── dynamic_obstacle_avoidance
│   └── dynamic_obstacle_avoidance.param.yaml
├── goal_planner
│   └── goal_planner.param.yaml
├── lane_change
│   └── lane_change.param.yaml
├── side_shift
│   └── side_shift.param.yaml
└── start_planner
    └── start_planner.param.yaml

Similarly, the common directory contains configuration files that are used across various modules, providing shared parameters and settings essential for the functioning of the Behavior Path Planner:

common
├── common.param.yaml
├── costmap_generator.param.yaml
└── nearest_search.param.yaml

The preset directory contains the configurations for managing the operational state of various modules. It includes the default_preset.yaml file, which specifically caters to enabling and disabling modules within the system.

preset
└── default_preset.yaml

Limitations & Future Work

  1. The Goal Planner module cannot be simultaneously executed together with other modules.
  2. The module is not designed as a plugin. Integrating a custom module is not straightforward. Users have to modify part of the Behavior Path Planner’s main code.
CHANGELOG

Changelog for package autoware_behavior_path_planner

0.43.0 (2025-03-21)

  • Merge remote-tracking branch 'origin/main' into chore/bump-version-0.43
  • chore: rename from [autoware.universe]{.title-ref} to [autoware_universe]{.title-ref} (#10306)
  • feat!: replace VelocityLimit messages with autoware_internal_planning_msgs (#10273)
  • feat: adaption to ROS nodes guidelines about directory structure (#10268)
  • feat(behavior_path_planner_common): modify drivable area expansion to be able to avoid static objects (#10220)
    • modify drivable area expansion to avoid static objects
    • rename parameters and update drivable area design md

    * Update planning/behavior_path_planner/autoware_behavior_path_planner_common/docs/behavior_path_planner_drivable_area_design.md Co-authored-by: Maxime CLEMENT <<78338830+maxime-clem@users.noreply.github.com>> * correct parameters description ---------Co-authored-by: Maxime CLEMENT <<78338830+maxime-clem@users.noreply.github.com>>

  • fix(planning, control): reuse stamp of subscribed topic to measure component latency (#10201)
    • fix(behavior_velocity_planner): reuse timestamp of recieved path
    • fix(behavior_path_planner): check timestamp first in timer driven callback
    • fix(trajectory_follower_node): check timestamp first in timer driven callback

    * fix(vehicle_cmd_gate): reuse timestamp of recieved path ---------

  • Contributors: Hayato Mizushima, NorahXiong, Ryohsuke Mitsudome, Satoshi OTA, Yutaka Kondo, mkquda

0.42.0 (2025-03-03)

  • Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
  • feat(autoware_utils): replace autoware_universe_utils with autoware_utils (#10191)
  • feat!: replace scenario msg from tier4_planning_msgs to autoware_internal_planning_msgs (#10180)
  • feat!: replace tier4_planning_msgs/PathWithLaneId with autoware_internal_planning_msgs/PathWithLaneId (#10023)
  • feat(planning_test_manager): abstract message-specific functions (#9882)
    • abstract message-specific functions
    • include necessary header
    • adapt velocity_smoother to new test manager
    • adapt behavior_velocity_planner to new test manager
    • adapt path_optimizer to new test manager
    • fix output subscription
    • adapt behavior_path_planner to new test manager
    • adapt scenario_selector to new test manager
    • adapt freespace_planner to new test manager
    • adapt planning_validator to new test manager
    • adapt obstacle_stop_planner to new test manager
    • adapt obstacle_cruise_planner to new test manager
    • disable test for freespace_planner
    • adapt behavior_velocity_crosswalk_module to new test manager
    • adapt behavior_path_lane_change_module to new test manager
    • adapt behavior_path_avoidance_by_lane_change_module to new test manager
    • adapt behavior_path_dynamic_obstacle_avoidance_module to new test manager
    • adapt behavior_path_external_request_lane_change_module to new test manager
    • adapt behavior_path_side_shift_module to new test manager
    • adapt behavior_path_static_obstacle_avoidance_module to new test manager
    • adapt path_smoother to new test manager
    • adapt behavior_velocity_blind_spot_module to new test manager
    • adapt behavior_velocity_detection_area_module to new test manager
    • adapt behavior_velocity_intersection_module to new test manager
    • adapt behavior_velocity_no_stopping_area_module to new test manager
    • adapt behavior_velocity_run_out_module to new test manager
    • adapt behavior_velocity_stop_line_module to new test manager
    • adapt behavior_velocity_traffic_light_module to new test manager
    • adapt behavior_velocity_virtual_traffic_light_module to new test manager
    • adapt behavior_velocity_walkway_module to new test manager
    • adapt motion_velocity_planner_node_universe to new test manager
    • include necessary headers

    * Odometries -> Odometry ---------Co-authored-by: Takayuki Murooka <<takayuki5168@gmail.com>>

  • Contributors: Fumiya Watanabe, Mitsuhiro Sakamoto, Ryohsuke Mitsudome, 心刚

0.41.2 (2025-02-19)

  • chore: bump version to 0.41.1 (#10088)
  • Contributors: Ryohsuke Mitsudome

0.41.1 (2025-02-10)

0.41.0 (2025-01-29)

  • Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
  • feat(start_planner): visualize planner evaluation table in rviz (#10029) visualize planner evaluation table in rviz
  • feat(autoware_planning_test_manager): remove dependency of tier4_planning_msgs::msg::LateralOffset (#9967)
    • feat(autoware_planning_test_manager): remove dependency of tier4_planning_msgs::msg::LateralOffset

    * fix

  • refactor(behavior_path_planner): common test functions (#9963)
    • feat: common test code in behavior_path_planner
    • deal with other modules
    • fix typo

    * update

  • chore(planning): move package directory for planning factor interface (#9948)
    • chore: add new package for planning factor interface
    • chore(surround_obstacle_checker): update include file
    • chore(obstacle_stop_planner): update include file
    • chore(obstacle_cruise_planner): update include file
    • chore(motion_velocity_planner): update include file
    • chore(bpp): update include file
    • chore(bvp-common): update include file
    • chore(blind_spot): update include file
    • chore(crosswalk): update include file
    • chore(detection_area): update include file
    • chore(intersection): update include file
    • chore(no_drivable_area): update include file
    • chore(no_stopping_area): update include file
    • chore(occlusion_spot): update include file
    • chore(run_out): update include file
    • chore(speed_bump): update include file
    • chore(stop_line): update include file
    • chore(template_module): update include file
    • chore(traffic_light): update include file
    • chore(vtl): update include file
    • chore(walkway): update include file

    * chore(motion_utils): remove factor interface ---------

  • feat(planning_factor)!: remove velocity_factor, steering_factor and introduce planning_factor (#9927) Co-authored-by: Satoshi OTA <<44889564+satoshi-ota@users.noreply.github.com>> Co-authored-by: Ryohsuke Mitsudome <<43976834+mitsudome-r@users.noreply.github.com>> Co-authored-by: satoshi-ota <<satoshi.ota928@gmail.com>>
  • fix(planning): text revisions (#9886)
    • fix(planning): text revisions

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

  • docs(bpp): revise explanation for Failure modules (#9863)
  • feat(behavior_path_planner): use autoware internal stamped messages (#9750)
    • feat(behavior_path_planner): use autoware internal stamped messages

    * fix universe_utils ---------

  • Contributors: Atto Armoo, Fumiya Watanabe, Kyoichi Sugahara, Mamoru Sobue, Satoshi OTA, Takayuki Murooka, Zulfaqar Azmi

0.40.0 (2024-12-12)

  • Merge branch 'main' into release-0.40.0
  • Revert "chore(package.xml): bump version to 0.39.0 (#9587)" This reverts commit c9f0f2688c57b0f657f5c1f28f036a970682e7f5.
  • fix: fix ticket links in CHANGELOG.rst (#9588)
  • chore(package.xml): bump version to 0.39.0 (#9587)
    • chore(package.xml): bump version to 0.39.0
    • fix: fix ticket links in CHANGELOG.rst

    * fix: remove unnecessary diff ---------Co-authored-by: Yutaka Kondo <<yutaka.kondo@youtalk.jp>>

  • fix: fix ticket links in CHANGELOG.rst (#9588)
  • fix(cpplint): include what you use - planning (#9570)
  • fix(bpp)!: remove stop reason (#9449) fix(bpp): remove stop reason
  • 0.39.0
  • update changelog
  • fix: fix ticket links to point to https://github.com/autowarefoundation/autoware_universe (#9304)
  • feat(bpp): add velocity interface (#9344)
    • feat(bpp): add velocity interface

    * fix(adapi): subscribe additional velocity factors ---------

  • refactor(factor): move steering factor interface to motion utils (#9337)
  • refactor(bpp): rework steering factor interface (#9325)
    • refactor(bpp): rework steering factor interface
    • refactor(soa): rework steering factor interface
    • refactor(AbLC): rework steering factor interface
    • refactor(doa): rework steering factor interface
    • refactor(lc): rework steering factor interface
    • refactor(gp): rework steering factor interface
    • refactor(sp): rework steering factor interface
    • refactor(sbp): rework steering factor interface

    * refactor(ss): rework steering factor interface ---------

  • fix: fix ticket links to point to https://github.com/autowarefoundation/autoware_universe (#9304)
  • chore(package.xml): bump version to 0.38.0 (#9266) (#9284)
    • unify package.xml version to 0.37.0
    • remove system_monitor/CHANGELOG.rst
    • add changelog

    * 0.38.0

  • Contributors: Esteve Fernandez, Fumiya Watanabe, M. Fatih Cırıt, Ryohsuke Mitsudome, Satoshi OTA, Yutaka Kondo

0.39.0 (2024-11-25)

0.38.0 (2024-11-08)

  • unify package.xml version to 0.37.0
  • fix(autoware_behavior_path_planner): fix cppcheck unusedVariable (#9193)
  • fix(behavior_path_planner): suppress reseting root lanelet (#9129) fix(behavior_path_planner): suppress resseting root lanelet
  • refactor(object_recognition_utils): add autoware prefix to object_recognition_utils (#8946)
  • test(bpp_common): add test for object related functions (#9062)
    • add test for object related functions
    • use EXPECT_DOUBLE_EQ instead of EXPECT_NEAR

    * fix build error ---------

  • refactor(autoware_interpolation): prefix package and namespace with autoware (#8088) Co-authored-by: kosuke55 <<kosuke.tnp@gmail.com>>
  • refactor(signal_processing): prefix package and namespace with autoware (#8541)
  • chore(planning): consistent parameters with autoware_launch (#8915)
    • chore(planning): consistent parameters with autoware_launch
    • update

    * fix json schema ---------

  • fix(autoware_behavior_path_planner): fix syntaxError (#8834) fix:syntaxError
  • fix(autoware_behavior_path_planner): align the parameters with launcher (#8790) parameters in behavior_path_planner aligned
  • refactor(behavior_path_planner): planner data parameter initializer function (#8767)
  • chore(autoware_default_adapi)!: prefix autoware to package name (#8533)
  • fix(docs): fix dead links in behavior path planner manager (#8309)
    • fix dead links

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

  • fix(behavior_path_planner, spellchecks): spell checks in behavior path planner (#8307)
    • fix spell checks in behavior path planner

    * try re-routable ---------

  • feat(behavior_path _planner): divide planner manager modules into dependent slots (#8117)
  • fix(behavior_path_planner_common): fix dynamic drivable area expansion with few input bound points (#8136)
  • refactor(autoware_universe_utils): changed the API to be more intuitive and added documentation (#7443)
    • refactor(tier4_autoware_utils): Changed the API to be more intuitive and added documentation.
    • use raw shared ptr in PollingPolicy::NEWEST
    • update
    • fix

    * Update evaluator/autoware_control_evaluator/include/autoware/control_evaluator/control_evaluator_node.hpp Co-authored-by: danielsanchezaran <<daniel.sanchez@tier4.jp>> ---------Co-authored-by: danielsanchezaran <<daniel.sanchez@tier4.jp>>

  • feat(autoware_behavior_path_planner): prevent infinite loop in approving scene module process (#7881)
    • prevent infinite loop
    • calculate max_iteration_num from number of scene modules

    * add doxygen explanation for calculateMaxIterationNum ---------

  • feat(autoware_behavior_path_planner_common,autoware_behavior_path_lane_change_module): add time_keeper to bpp (#8004)
    • feat(autoware_behavior_path_planner_common,autoware_behavior_path_lane_change_module): add time_keeper to bpp

    * update

  • feat(autoware_behavior_path_planner): remove max_module_size param (#7764) * feat(behavior_path_planner): remove max_module_size param The max_module_size param has been removed from the behavior_path_planner scene_module_manager.param.yaml file. This param was unnecessary and has been removed to simplify the configuration. ---------

  • feat: add [autoware_]{.title-ref} prefix to [lanelet2_extension]{.title-ref} (#7640)
  • refactor(universe_utils/motion_utils)!: add autoware namespace (#7594)
  • refactor(motion_utils)!: add autoware prefix and include dir (#7539) refactor(motion_utils): add autoware prefix and include dir
  • feat(autoware_universe_utils)!: rename from tier4_autoware_utils (#7538) Co-authored-by: kosuke55 <<kosuke.tnp@gmail.com>>
  • refactor(behaivor_path_planner)!: rename to include/autoware/{package_name} (#7522)
    • refactor(behavior_path_planner)!: make autoware dir in include
    • refactor(start_planner): make autoware include dir
    • refactor(goal_planner): make autoware include dir
    • sampling planner module
    • fix sampling planner build
    • dynamic_avoidance
    • lc
    • side shift
    • autoware_behavior_path_static_obstacle_avoidance_module
    • autoware_behavior_path_planner_common
    • make behavior_path dir
    • pre-commit
    • fix pre-commit

    * fix build ---------

  • Contributors: Esteve Fernandez, Go Sakayori, Kosuke Takeuchi, Kyoichi Sugahara, Mamoru Sobue, Maxime CLEMENT, Ryuta Kambe, Takagi, Isamu, Takayuki Murooka, Yukinari Hisaki, Yutaka Kondo, Yuxuan Liu, Zhe Shen, kobayu858

0.26.0 (2024-04-03)

Wiki Tutorials

This package does not provide any links to tutorials in it's rosindex metadata. You can check on the ROS Wiki Tutorials page for the package.

Launch files

  • launch/behavior_path_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_path_planner_launch_modules
      • behavior_path_config_path
      • behavior_path_planner_common_param_path
      • behavior_path_planner_scene_module_manager_param_path
      • behavior_path_planner_side_shift_module_param_path
      • behavior_path_planner_avoidance_module_param_path
      • behavior_path_planner_avoidance_by_lc_module_param_path
      • behavior_path_planner_dynamic_avoidance_module_param_path
      • behavior_path_planner_lane_change_module_param_path
      • behavior_path_planner_goal_planner_module_param_path
      • behavior_path_planner_start_planner_module_param_path
      • behavior_path_planner_sampling_planner_module_param_path
      • behavior_path_planner_drivable_area_expansion_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_path_planner at Robotics Stack Exchange

No version for distro noetic. Known supported distros are highlighted in the buttons above.
No version for distro ardent. Known supported distros are highlighted in the buttons above.
No version for distro bouncy. Known supported distros are highlighted in the buttons above.
No version for distro crystal. Known supported distros are highlighted in the buttons above.
No version for distro eloquent. Known supported distros are highlighted in the buttons above.
No version for distro dashing. Known supported distros are highlighted in the buttons above.
No version for distro galactic. Known supported distros are highlighted in the buttons above.
No version for distro foxy. Known supported distros are highlighted in the buttons above.
No version for distro iron. Known supported distros are highlighted in the buttons above.
No version for distro lunar. Known supported distros are highlighted in the buttons above.
No version for distro jade. Known supported distros are highlighted in the buttons above.
No version for distro indigo. Known supported distros are highlighted in the buttons above.
No version for distro hydro. Known supported distros are highlighted in the buttons above.
No version for distro kinetic. Known supported distros are highlighted in the buttons above.
No version for distro melodic. Known supported distros are highlighted in the buttons above.