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.48.0 (2025-11-18)

• Merge remote-tracking branch 'origin/main' into humble

• feat(autoware_lanelet2_utils): replace ported functions from autoware_lanelet2_extension (#11593) Co-authored-by: Mamoru Sobue <<hilo.soblin@gmail.com>>

• revert(start_planner): "ensure the pose is not behind the ego vehicle" (#11656)

• refactor(start_planner): remove redundant member variable and setting stop path pointer to null (#11637)

  • refactor(start_planner): remove redundant member variable and setting stop path pointer to null
  • refactoring

  * update prev_approved_path ---------

• fix: tf2 uses hpp headers in rolling (and is backported) (#11620)

• fix(start_planner): preventing RTC start value from publishing negative value (#11582) fix(start_planner): Preventing RTC start value from publishing negative value

• feat(start_planner): write document of the clothoid pull out (#11538)

  • docs: add path generation flow and diagram to README
  • add a figure of clothoid path generation flow
  • add limitation note of the clothoid pull out
  • add clothoid pullout overview figure

  * change number and fix typo ---------

• fix(start_planner): ensure the pose is not behind the ego vehicle (#11548)

• refactor(start_planner): use new function to simplify function (#11486)

• feat(start_planner): supprt rtc force approval to bypass safety check (#11482) feat(start_planner): rtc force approval

• feat(start planner): support transit from running state to waiting approval state when unsafe (#11477)

  • transit to waiting approval when unsafe

  * only works if ego is moving forward ---------

• feat(start planner): replace zero velocity with stop line on candidate path (#11476)

  • fix(start_planner): insert stop point on planWaitingApproval path
  • slight refactoring
  • remove empty space
  • fix value issue

  * fix test fail ---------

• fix(start_planner): keep blinker after switching from stop path to pull out path after engage (#11473)

• feat(start_planner): add plotting feature for the failed test cases. (#11403)

  • success to plot failed path, and increase the time out limit
  • disable the failed route, and organize the format
  • combine plot_and_seve_path method

  * refactor(start_planner_test_helper): optimize lanelet handling with emplace_back and const references ---------Co-authored-by: Kyoichi Sugahara <<kyoichi.sugahara@tier4.jp>>

• feat(start_planner): add plotting functionality for the test of geometric, clothoid, and freespace planner with additional yaml data (#11261)

  • update plot_and_save_path function to plot the lanelet of the start pose
  • enhance FreespacePullOut tests with YAML files and visualization
  • enhance Geometric and Clothoid pull out tests with YAML files and visualization

File truncated at 100 lines see the full file