ROS index logo ROS Index
Package List
Repository List
System Dependencies
  1. Home
  2. Packages
  3. autoware_behavior_velocity_planner
 
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
jazzy

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro kilted showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro lyrical showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro rolling showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro ardent showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro bouncy showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro crystal showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro eloquent showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro dashing showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro galactic showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro foxy showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro iron showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code
No version for distro lunar showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code
Wiki

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code Wiki
No version for distro jade showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code
Wiki

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code Wiki
No version for distro indigo showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code
Wiki

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code Wiki
No version for distro hydro showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code
Wiki

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code Wiki
No version for distro kinetic showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code
Wiki

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code Wiki
No version for distro melodic showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code
Wiki

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code Wiki
No version for distro noetic showing humble. Known supported distros are highlighted in the buttons above.
Package symbol

autoware_behavior_velocity_planner package from autoware_core repo

autoware_adapi_adaptors autoware_adapi_specs autoware_core_api autoware_default_adapi autoware_core autoware_agnocast_wrapper autoware_component_interface_admission autoware_component_interface_specs autoware_component_interface_utils autoware_geography_utils autoware_global_parameter_loader autoware_interface_spec_lint autoware_interpolation autoware_kalman_filter autoware_lanelet2_utils autoware_marker_utils autoware_motion_utils autoware_node autoware_object_recognition_utils autoware_osqp_interface autoware_point_types autoware_qos_utils autoware_qp_interface autoware_signal_processing autoware_trajectory autoware_vehicle_info_utils autoware_command_gate autoware_core_control autoware_simple_pure_pursuit autoware_awsim_sensor_kit_description autoware_sample_sensor_kit_description autoware_sample_vehicle_description autoware_core_localization autoware_ekf_localizer autoware_gyro_odometer autoware_localization_util autoware_ndt_scan_matcher autoware_pose_initializer autoware_stop_filter autoware_twist2accel autoware_core_map autoware_lanelet2_map_visualizer autoware_map_height_fitter autoware_map_loader autoware_map_projection_loader autoware_core_perception autoware_euclidean_cluster_object_detector autoware_ground_filter autoware_perception_objects_converter autoware_core_planning autoware_mission_planner autoware_objects_of_interest_marker_interface autoware_path_generator autoware_planning_factor_interface autoware_planning_test_manager autoware_planning_topic_converter autoware_route_handler autoware_velocity_smoother autoware_behavior_velocity_planner autoware_behavior_velocity_planner_common autoware_behavior_velocity_stop_line_module autoware_motion_velocity_obstacle_stop_module autoware_motion_velocity_planner autoware_motion_velocity_planner_common autoware_core_sensing autoware_crop_box_filter autoware_downsample_filters autoware_gnss_poser autoware_vehicle_velocity_converter autoware_pyplot autoware_test_node autoware_test_utils autoware_testing autoware_core_vehicle

ROS Distro
humble

API Docs
Browse Code
Wiki

Package Summary

Version 1.10.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/autowarefoundation/autoware_core.git
VCS Type git
VCS Version main
Last Updated 2026-10-07
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

The autoware_behavior_velocity_planner package

Maintainers

  • Zulfaqar Azmi
  • Mamoru Sobue
  • Takumi Odashima

Authors

  • Taiki Tanaka
  • Mamoru Sobue
  • Satoshi Ota
  • Kyoichi Sugahara
  • Kosuke Takeuchi
  • Yutaka Shimizu
  • Tomohito Ando
  • Yukihiro Saito
planning/behavior_velocity_planner/autoware_behavior_velocity_planner/README.md

Behavior Velocity Planner

Overview

behavior_velocity_planner is a planner that adjust velocity based on the traffic rules. It loads modules as plugins. Please refer to the links listed below for detail on each module.

Architecture

When each module plans velocity, it considers based on base_link(center of rear-wheel axis) pose. So for example, in order to stop at a stop line with the vehicles’ front on the stop line, it calculates base_link position from the distance between base_link to front and modifies path velocity from the base_link position.

set_stop_velocity

Input topics

Name Type Description
~input/path_with_lane_id autoware_internal_planning_msgs::msg::PathWithLaneId path with lane_id
~input/vector_map autoware_map_msgs::msg::LaneletMapBin vector map
~input/vehicle_odometry nav_msgs::msg::Odometry vehicle velocity
~input/dynamic_objects autoware_perception_msgs::msg::PredictedObjects dynamic objects
~input/no_ground_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud
~/input/compare_map_filtered_pointcloud sensor_msgs::msg::PointCloud2 obstacle pointcloud filtered by compare map. Note that this is used only when the detection method of run out module is Points.
~input/traffic_signals autoware_perception_msgs::msg::TrafficLightGroupArray traffic light states

Output topics

Name Type Description
~output/path autoware_planning_msgs::msg::Path path to be followed
~output/stop_reasons tier4_planning_msgs::msg::StopReasonArray reasons that cause the vehicle to stop

Node parameters

Parameter Type Description
launch_modules vector<string> module names to launch
forward_path_length double forward path length
backward_path_length double backward path length
max_accel double (to be a global parameter) max acceleration of the vehicle
system_delay double (to be a global parameter) delay time until output control command
delay_response_time double (to be a global parameter) delay time of the vehicle’s response to control commands

Traffic Light Handling in sim/real

The handling of traffic light information varies depending on the usage. In the below table, the traffic signal topic element for the corresponding lane is denoted as info, and if info is not available, it is denoted as null.

module \ case info is null info is not null
intersection_occlusion(is_simulation = *) <ul> <li>info is the latest non-null information</li></ul> GO(occlusion is ignored) intersection_occlusion uses the latest non UNKNOWN observation in the queue up to present.<ul><li>If info is GREEN or UNKNOWN, occlusion is cared</li><li>If info is RED or YELLOW, occlusion is ignored(GO) </li> <li> NOTE: Currently timeout is not considered</li> </ul>
traffic_light(sim, is_simulation = true) <ul> <li>info is current information</li></ul> GO traffic_light uses the perceived traffic light information at present directly. <ul><li>If info is timeout, STOP whatever the color is</li> <li>If info is not timeout, then act according to the color. If info is UNKNOWN, STOP</li></ul> {: rowspan=2}
traffic_light(real, is_simulation = false) <ul> <li>info is current information</li></ul> STOP &#8288 {: style=”padding:0”}
crosswalk with Traffic Light(is_simulation = *) <ul> <li>info is current information</li></ul> default <ul> <li>If disable_yield_for_new_stopped_object is true, each sub scene_module ignore newly detected pedestrians after module instantiation.</li> <li>If ignore_with_traffic_light is true, occlusion detection is skipped.</li></ul>
map_based_prediction(is_simulation = *) <ul> <li>info is current information</li></ul> default If a pedestrian traffic light is<ul> <li>RED, surrounding pedestrians are not predicted.</li> <li>GREEN, stopped pedestrians are not predicted.</li></ul>
CHANGELOG

Changelog for package autoware_behavior_velocity_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

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

  • fix(design): align the autoware_core node designs with the packages they describe (#1416)

    * fix(autoware_velocity_smoother): correct the velocity limit message type in the node design The node publishes current_velocity_limit_mps as autoware_internal_planning_msgs/msg/VelocityLimit (node.hpp), while the design declared the pre-migration tier4_planning_msgs type, failing the connection check against downstream ports.

    • fix(autoware_motion_velocity_planner): correct the velocity limit message types and drop absent publishers in the node design

    * fix(autoware_path_generator): correct the path publisher message type in the node design The node publishes autoware_internal_planning_msgs/msg/PathWithLaneId on ~/output/path (node.hpp:84), not autoware_planning_msgs/msg/Path.

    * fix(autoware_velocity_smoother): declare the kinematic state subscriber in the node design The node polls /localization/kinematic_state for the ego odometry (node.hpp:94-97); the design did not list the input at all.

    * fix(autoware_motion_velocity_planner): name the module-side subscriber topics in the node design The boundary departure prevention module subscribes on absolute topic names, so the default ~/input/<name> remap targets addressed topics the node never opens and the module connections resolved to nothing. Declare the real names and add the steering status input the module also takes.

    * fix(autoware_gnss_poser): declare the map projector info subscriber in the node design The node blocks pose conversion until /map/map_projector_info arrives (gnss_poser_node.cpp:43); the design did not list the input at all.

    * fix(autoware_behavior_velocity_planner): add additional planning factors to publishers in the node design ---------

  • fix(planning): point design param_files at the packages that install them (#1387) BehaviorVelocityPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. MotionVelocityPlanner referenced the module packages with a _module suffix the installed filenames do not have. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

    • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
    • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
    • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
    • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
    • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

  • refactor: migrate node design files from autoware_universe (#1381) Node design files for packages that moved to autoware_core, placed at the in-package convention <package>/design/<Name>.node.yaml. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

  • Contributors: Mete Fatih Cırıt, Taekjin LEE, github-actions

1.9.0 (2026-06-24)

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

  • refactor(autoware_behavior_velocity_planner): extract node-agnostic data-ingestion helpers

File truncated at 100 lines see the full file

Launch files

  • launch/behavior_velocity_planner.launch.xml
      • common_param_path
      • vehicle_param_file
      • nearest_search_param_path
      • behavior_velocity_planner_launch_modules
      • behavior_velocity_config_path
      • behavior_velocity_smoother_type_param_path
      • behavior_velocity_planner_param_path
      • behavior_velocity_planner_common_param_path
      • behavior_velocity_planner_blind_spot_module_param_path
      • behavior_velocity_planner_crosswalk_module_param_path
      • behavior_velocity_planner_walkway_module_param_path
      • behavior_velocity_planner_detection_area_module_param_path
      • behavior_velocity_planner_intersection_module_param_path
      • behavior_velocity_planner_roundabout_module_param_path
      • behavior_velocity_planner_stop_line_module_param_path
      • behavior_velocity_planner_traffic_light_module_param_path
      • behavior_velocity_planner_virtual_traffic_light_module_param_path
      • behavior_velocity_planner_occlusion_spot_module_param_path
      • behavior_velocity_planner_no_stopping_area_module_param_path
      • behavior_velocity_planner_speed_bump_module_param_path
      • behavior_velocity_planner_no_drivable_lane_module_param_path

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged autoware_behavior_velocity_planner at Robotics Stack Exchange

API Docs Browse Code Wiki