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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Launch files
Messages
Services
Plugins
Recent questions tagged autoware_planning_factor_interface at Robotics Stack Exchange
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
Maintainers
- Mamoru Sobue
Authors
- Satoshi Ota
autoware_planning_factor_interface
Overview
The PlanningFactorInterface is a C++ class designed to facilitate the addition and publication of planning factors.
Design
The PlanningFactorInterface class is designed to be lightweight and efficient, with the following key components:
-
Add: Methods to add planning factors to the interface.
-
Publisher: The class includes a publisher for
PlanningFactorArraymessages, which are used to distribute planning factors to other nodes in the system.
The design emphasizes flexibility and ease of use, allowing developers to quickly integrate new planning factors into autoware.
Usage
Including the Header
To use the PlanningFactorInterface, include the header file in your code:
#include <autoware/planning_factor_interface/planning_factor_interface.hpp>
Creating an Instance
Instantiate the PlanningFactorInterface by providing a node and a name for the factor module:
class AvoidancePlanner
{
public:
AvoidancePlanner(rclcpp::Node & node)
: planning_factor_interface_{std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner")}
You can also enable console output for debugging by setting the appropriate parameters:
// Enable console output with a 1000ms throttle duration
planning_factor_interface_ = std::make_unique<
autoware::planning_factor_interface::PlanningFactorInterface>(
&node, "avoidance_planner", true, 1000);
Adding Planning Factors
planning_factor_interface_->add(
traj_points, ego_pose, stop_pose,
autoware_internal_planning_msgs::msg::PlanningFactor::NONE,
autoware_internal_planning_msgs::msg::SafetyFactorArray{});
Publishing Factors
After adding planning factors, you can publish them by calling the publish method:
// Publish the added factors
planning_factor_interface_->publish();
Changelog for package autoware_planning_factor_interface
1.1.0 (2025-05-01)
1.10.0 (2026-09-28)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
chore: update package maintainer (#1384) chore: update package author metadata
-
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)
-
feat(PlanningFactorInterface): introduce node independent PlanningFactorInterfaceBase class (#1250)
- templatize PlanningFactorInterface
* test(autoware_planning_factor_interface): cover agnocast wrapper node in typed test Convert the publisher/subscriber test to a TYPED_TEST over rclcpp::Node and autoware::agnocast_wrapper::Node so PlanningFactorInterfaceT is exercised for both node instantiations, not only the rclcpp one.
- delete tests for rclcpp::Node
* specify node type ---------
-
Contributors: Koichi Imai, Mete Fatih Cırıt, Satoshi OTA, github-actions
1.9.0 (2026-06-24)
-
Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base
-
test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins (#1152)
* test(autoware_planning_factor_interface): add gtest suite and apply move-based perf wins Add the package's first gtest suite, wiring the missing BUILD_TESTING / ament_auto_add_gtest block in CMakeLists. The suite pins:
- single- and two-control-point add() ControlPoint/PlanningFactor field construction (pose, velocity, shift_length, distance, module name, behavior, detail, driving direction, safety factors),
- the templated add() overloads forwarding calcSignedArcLength results into ControlPoint.distance,
- factor accumulation across multiple add() calls in insertion order,
- the publish() contract: header.frame_id == 'map', factors forwarded into the PlanningFactorArray (verified via a test subscription), and factors_ cleared afterwards so the next cycle starts empty. Apply the low-risk, behavior-preserving perf wins flagged for this package: move the locally-built PlanningFactor into factors_ in both add() overloads, move factors_ into msg.factors in publish() (the buffer is cleared immediately after), and return factors_ by const reference from get_factors() to drop a deep copy per call. The publish() console gate now checks msg.factors (which holds the moved-from factors) so the output behavior is unchanged. Refs: autowarefoundation/autoware_core#1096
- style(pre-commit): autofix
* fix(autoware_planning_factor_interface): make factor non-const for real move A const-qualified factor caused std::move to bind to the copy constructor, silently degrading the intended move into
File truncated at 100 lines see the full file