Start Planner design

Purpose / Role

This module generates and plans a path for safely merging from the shoulder lane or side of road lane into the center of the road lane.

Specifically, it includes the following features:

• Plan the path to automatically start from the shoulder lane or side of road lane to center of road lane.
• When parked vehicles are present on the shoulder lane, the module generates a path that allows for starting with a gap of a specified margin.
• If a collision with other traffic participants is detected while traveling on the generated path, it will stop as much as possible.

Use Cases

Give an typical example of how path generation is executed. Showing example of path generation starts from shoulder lane, but also from side of road lane can be generated.

Use Case 1: Shift pull out

In the shoulder lane, when there are no parked vehicles ahead and the shoulder lane is sufficiently long, a forward shift pull out path (a clothoid curve with consistent jerk) is generated.

Use Case 2: Geometric pull out

In the shoulder lane, when there are objects in front and the lane is not sufficiently long behind, a geometric pull out path is generated.

Use Case 3: Backward and shift pull out

In the shoulder lane, when there are parked vehicles ahead and the lane is sufficiently long behind, a path that involves reversing before generating a forward shift pull out path is created.

Use Case 4: Backward and geometric pull out

In the shoulder lane, when there is an object ahead and not enough space to reverse sufficiently, a path that involves reversing before making an geometric pull out is generated.

Use Case 5: Clothoid pull out

This method creates smooth paths using clothoid curves that provide continuous curvature transitions.

Use Case 6: Freespace pull out

If the map is annotated with the information that a free space path can be generated in situations where both shift and geometric pull out paths are impossible to create, a path based on the free space algorithm will be generated.

As a note, the patterns for generating these paths are based on default parameters, but as will be explained in the following sections, it is possible to control aspects such as making paths that involve reversing more likely to be generated, or making geometric paths more likely to be generated, by changing the path generation policy or adjusting the margin around static objects.

Limitations

Here are some notable limitations:

• If parked vehicles exist in front of, behind, or on both sides of the shoulder, and it’s not possible to maintain a specified distance from them, a stopping path will be generated, leading to a potential deadlock.
• In the default settings of the behavior_path_planner, an avoidance module operates in a later stage and attempts to avoid objects. However, it is not guaranteed that the start_planner module will output a path that can successfully navigate around obstacles. This means that if an unavoidable path is generated, it could result in a deadlock.
• The performance of safety check relies on the accuracy of the predicted paths generated by the map_based_prediction node. It’s important to note that, currently, predicted paths that consider acceleration are not generated, and paths for low-speed objects may not be accurately produced, which requires caution.
• Given the current specifications of the rule-based algorithms, there is a trade-off between the safety of a path and its naturalness to humans. While it’s possible to adjust parameters to manage this trade-off, improvements are necessary to better reconcile these aspects.

Start/End Conditions

Start Conditions

The StartPlannerModule is designed to initiate its execution based on specific criteria evaluated by the isExecutionRequested function. The module will not start under the following conditions:

1. Start pose on the middle of the road: The module will not initiate if the start pose of the vehicle is determined to be in the middle of the road. This ensures the planner starts from a roadside position.

2. Vehicle is far from start position: If the vehicle is far from the start position, the module will not execute. This prevents redundant execution when the new goal is given.

3. Vehicle reached goal: The module will not start if the vehicle has already reached its goal position, avoiding unnecessary execution when the destination is attained.

4. Vehicle in motion: If the vehicle is still moving, the module will defer starting. This ensures that planning occurs from a stable, stationary state for safety.

5. Goal behind in same route segment: The module will not initiate if the goal position is behind the ego vehicle within the same route segment. This condition is checked to avoid complications with planning routes that require the vehicle to move backward on its current path, which is currently not supported.

End Conditions

The StartPlannerModule terminates when specific conditions are met, depending on the type of planner being used. The canTransitSuccessState function determines whether the module should transition to the success state based on the following criteria:

When the Freespace Planner is active

File truncated at 100 lines see the full file

Changelog for package autoware_behavior_path_start_planner_module

0.53.0 (2026-09-29)

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

• chore(pre-commit): update clang-format to v22.1.5 (#13126)

  • chore(pre-commit): update clang-format to v22.1.5

  * style(pre-commit): autofix ---------

• Contributors: Mete Fatih Cırıt, Ryohsuke Mitsudome

0.52.0 (2026-06-30)

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

• feat(autoware_vehicle_info_utils): refactor to use createFootprint with base_pose (#12586)

  • refactor universe_utils to transform in createFootprint
  • refactor mission_universe_planner to transform in createFootprint
  • refactor path_optimizer to transform in createFootprint
  • common-evaluator refactor createFootprint to apply base_link internally
  • bpp refactor createFootprint to apply base_link internally

  * bvp refactor createFootprint to apply base_link internally ---------

• Contributors: Sarun MUKDAPITAK, github-actions

0.51.0 (2026-05-01)

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

• feat(planning): replace autoware_universe_utils with specific autoware_utils sub-packagesr (#12443)

• refactor(boundary_departure_checker): deprecate legacy rule-based boundary departure checker (#12420) refactor: separate bdp

• chore(behavior_path_planner): remove unused lanelet2_extension header (#12292) unused lanelet2_extension in bpp modules Co-authored-by: Mamoru Sobue <<hilo.soblin@gmail.com>>

• feat(lanelet2_extension): replace ported lanelet2_extension utilities functions (final) (#12173) Co-authored-by: Mamoru Sobue <<hilo.soblin@gmail.com>>

• feat(start_planner): turn signal at centerline (#12152)

  • fix: turn signal when enabling pull out in centerline
  • fix: revert initial blinker's state

  * Revert "docs: parameter description" This reverts commit 37a555d452e9348b1d99e3349a9a5b0b71496e8c.

  • fix: add parameters
  • docs: add description

  * revert changes ---------

• feat(start_planner): allow start planner to start from the centerline (#11986)

  • temp

  * Revert "temp" This reverts commit 2033ec3864005ff7206140e85a9a1bc473b515fa.

  • fix: consider vehicle speed and shift length when performing initial safety check
  • fix: shift length wrongly computed
  • fix: set epsilon when comparing distance between point
  • fix: ignore all object check when shift length less than threshold
  • fix: rename parameter
  • fix: move to start planner utils and add enable back check
  • fix: precommit
  • fix: cache object polygon
  • docs: parameter description

  * fix: parameter update ---------

File truncated at 100 lines see the full file