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

When other pull out methods cannot generate a safe path due to collision margins, a clothoid-based pull out path is generated as a fallback option. 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.
• The clothoid pull out method is only available as a fallback when backward search is disabled (enable_back is false), as safety validation for backward paths in clothoid planner is not yet implemented.

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:

File truncated at 100 lines see the full file

Changelog for package autoware_behavior_path_start_planner_module

0.46.0 (2025-06-20)

• Merge remote-tracking branch 'upstream/main' into tmp/TaikiYamada/bump_version_base

• feat(behavior_path_planner): organize a part of behavior path info/debug markers (#10729)

  • feat(behavior_path_planner): organize a part of behavior path info/debug markers

  * Update planning/behavior_path_planner/autoware_behavior_path_goal_planner_module/src/goal_planner_module.cpp Co-authored-by: Kosuke Takeuchi <<kosuke.tnp@gmail.com>>

  * Update planning/behavior_path_planner/autoware_behavior_path_goal_planner_module/src/util.cpp Co-authored-by: Kosuke Takeuchi <<kosuke.tnp@gmail.com>> ---------Co-authored-by: Kosuke Takeuchi <<kosuke.tnp@gmail.com>>

• feat!: remove obstacle_stop_planner and obstacle_cruise_planner (#10695)

  • feat: remove obstacle_stop_planner and obstacle_cruise_planner
  • update

  * fix

• Contributors: TaikiYamada4, Takayuki Murooka

0.45.0 (2025-05-22)

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

• refactor(departure_checker): move lane departure checker class to departure_checker (#10337)

  • RT1-9640: separate lane departure checker library
  • move back parameter
  • separating parameters
  • renamed to boundary departure checker
  • pre-commit
  • remove trajectory deviation
  • rename namespace
  • move boundary departure checker to common folder

  * rename class name ---------

• feat(start_planner): add virtual stop detail (#10573)

  * feat(start_planner_module): add isInsideLanelets method to check vehicle footprint within lanelets ---------

• Contributors: Kyoichi Sugahara, TaikiYamada4, Zulfaqar Azmi

0.44.2 (2025-06-10)

0.44.1 (2025-05-01)

0.44.0 (2025-04-18)

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

• fix(start_planner): use waypoints as centerline if available (#10238)

  • fix(start_planner): use waypoints as centerline if available
  • update function name

  * rename function name ---------

• fix(start_planner): fix segmentation fault when generating backward path (#10393)

  * feat(behavior_path_planner): handle empty backward path case ---------

• feat(start/goal_planner): use common max steer angle parameter from vehicle_info (#10321)

  • fix(autoware_behavior_path_start_planner_module): update parameter name for geometric pull out max steer angle
  • fix(docs): update unit for max_steer_angle_margin_scale in README

  * fix dead link ---------

• Contributors: Kyoichi Sugahara, Mehmet Dogru, Ryohsuke Mitsudome

0.43.0 (2025-03-21)

File truncated at 100 lines see the full file