Planning component design#

The planning component makes the target trajectory (a path and a speed profile) that the vehicle follows. The trajectory must be safe, obey the traffic rules, and complete the mission.

This page has two parts. The first part gives the high-level requirements and design. The second part describes the reference implementation and the features that it supports.

Goals and non-goals#

Autoware is an "autonomous driving platform". Users extend the driving functions for their own needs. Autoware follows the microautonomy architecture concept: high extensibility, modular functions, and clearly defined interfaces.

For this reason, the planning component does not try to solve every complex driving scenario. Instead, it gives a planning development platform that you can customize and extend easily. With this platform, users can solve many complex use cases for their own needs.

Goals#

• The basic functions are provided, so that you can define a simple ODD. Before you extend the functions, the planning component must give the basic functions of autonomous driving. These functions include moving, stopping, and turning. They also include lane changes and obstacle avoidance in relatively safe and simple situations.
• The functions are modular, so that users can extend them. The system adapts to different operational design domains (ODDs) with extended functions. Modules work like plug-ins. You can build systems for different needs, for example Level 4 or Level 2 driving, public or private roads, large vehicles, or small robots.
  • You can also remove functions for a specific ODD, for example a private road with no obstacles. As a result, the system can use less power or fewer sensors.
• Human operators can extend the capability with their decisions. With operator assistance, the system can handle complex and difficult scenarios. This page does not define the type of operator. It can be a person in the vehicle during prototype development, or a remote operator who connects in an emergency during an autonomous driving service.

Non-goals#

Third-party modules can extend the planning component. As a result, these items are not goals of the planning component of Autoware:

• To give all the functions that users need by default.
• To give the complete functions and performance of an autonomous driving system.
• To give a performance that is always better than human drivers, or to guarantee absolute safety.

These non-goals come from the "platform" vision of Autoware. They do not apply to a typical planning component.

High-level design#

This diagram shows the high-level architecture of the planning component. It is an ideal design, and the current implementation is different in some areas. The reference implementation section describes the implementation.

The planning component follows the microautonomy architecture and uses a modular framework. Each planning function is a module, for example lane change, intersection, or crosswalk. You can add or remove modules statically or dynamically for each use case.

The planning component has these sub-components:

• Mission planning: calculates a route from the current position to the destination with the map data. It is similar to the route planning of a fleet management system (FMS) or a car navigation system.
• Planning modules: plan the behavior of the vehicle for the mission, for example the target trajectory and the turn signals. There are two types of modules:
  • Behavior: calculates a safe route that obeys the traffic rules. It decides on lane changes, on the entry into intersections, and on stops at stop lines.
  • Motion: works with the behavior modules to calculate the trajectory of the vehicle. It considers the vehicle motion and the ride comfort. It includes lateral planning (the path shape) and longitudinal planning (the speed).
• Validation: makes sure that the planned trajectory is safe and correct, and responds to emergencies. If a planned trajectory is not correct, it starts an emergency response or makes an alternative path.

Highlights#

Trade-offs of a separate planning component#

Autoware separates planning, perception, localization, and control into different components. This separation makes it easier to work with third-party modules. But there is a trade-off between performance and extensibility. For example, perception can process objects that planning does not need, because perception is separate from planning. Also, when planning is separate from control, it is difficult for planning to consider the vehicle dynamics. To decrease these problems, the interfaces can carry more information, or the components can do more computation.

Customize features#

The planning component can work with external modules. This diagram shows three ways to add external functions.

1. Add or replace modules#

You can add new modules to the planning component, or replace existing modules. This is the usual way to extend the functions. For example, you can add a function that your ODD needs, or simplify an existing function.

To do this, the module interfaces must be well organized. The current implementation does not have a fully modular system yet, so this approach has limits. For more information, see Customize features in the current implementation and how to enable or disable a planning module.

2. Replace a sub-component#

You can also work at the sub-component level. For example, you can replace mission planning with an existing FMS service. Or you can use a third-party trajectory generator together with the existing validation.

If you follow the internal interfaces of the planning component, you can extend planning at this level. Close coordination with the existing planning modules can be limited, but you can connect some planning functions with external modules.

3. Replace the whole planning component#

Companies and research groups that develop their own planning system can use it with the perception and control components of Autoware. To do this, replace the whole planning component and follow the stable interfaces between the components. In this case, you cannot coordinate directly with the existing planning modules.

Component interface#

This section describes the inputs and outputs of the planning component and of its sub-components. The topics are the defaults of the reference implementation. The planning component interface page gives more details.

Inputs#

Outputs#

Internal interfaces#

Supported features#

This section lists the features of the reference implementation. Each feature names the module that implements it and the map data or other input that it needs. The reference implementation section lists all modules and the launch arguments that enable them.

The drawings use these conventions:

• The blue vehicle is the ego vehicle. Traffic keeps to the left.
• The green line with an arrow is the planned path.
• A cyan area is a section where the ego vehicle slows down.
• A red area is a section that the ego vehicle must not enter yet. A red line across the lane is a stop point.
• A red vehicle, person, or cone is an object that causes the planning behavior. A grey vehicle is another vehicle.

Route and path planning#

Route planning#

Plan a route from the position of the ego vehicle to the destination.

• Module: Mission Planner (autoware_mission_planner_universe). Autoware Core also has the autoware_mission_planner package.
• Needs: Lanelet map (driving lanelets).

Path planning from the route#

Plan the path that the vehicle follows on the route (lane following).

• Module: Behavior Path Planner. As an alternative, the Path Generator of Autoware Core makes a path without the behavior path modules (behavior_path_planner_type:=path_generator).
• Needs: Lanelet map (driving lanelets).

Lane change#

Plan a path that changes lanes to reach the destination.

• Module: Lane Change. Launch arguments: launch_lane_change_right_module, launch_lane_change_left_module.
• Needs: Object information and Lanelet map (adjacent lanes, where the type of the line between the lanes permits a lane change).
• Demonstration: lane change video (2023).

Obstacle avoidance#

Plan a path that steers around obstacles.

• Modules: Static Obstacle Avoidance (launch argument launch_static_obstacle_avoidance) and Path Optimizer (launch argument motion_path_planner_type:=path_optimizer, the default).
• Needs: Object information and Lanelet map (the ego lane, and the adjacent lanes that the use_lane_type parameter permits).
• Demonstration: avoidance video (2023, when the module had the name Avoidance).

Path smoothing#

Plan a path for smooth steering.

• Modules: Elastic Band Smoother (launch argument motion_path_smoother_type:=elastic_band, the default) and Path Optimizer.
• Needs: Nothing. The smoother uses only the path from the Behavior Path Planner and the ego odometry.
• Demonstration: path smoothing video (2024).

Narrow space driving#

Plan a path inside the drivable area. If the vehicle cannot stay inside the drivable area, stop the vehicle before it leaves the area.

• Module: Path Optimizer. The parameter enable_outside_drivable_area_stop enables the stop.
• Needs: Lanelet map (high-precision lane boundaries).
• Demonstration: narrow space video (2024).

Pull over#

Plan a path that pulls over to park on the road shoulder.

• Module: Goal Planner. Launch argument: launch_goal_planner_module.
• Needs: Object information and Lanelet map (lanelets with the subtype road_shoulder, or a BusStopArea regulatory element when use_bus_stop_area is true).
• Demonstrations (2023): simple pull over video, arc forward pull over video, and arc backward pull over video.

Pull out#

Plan a path that pulls out from the road shoulder to start driving.

• Module: Start Planner. Launch argument: launch_start_planner_module.
• Needs: Object information and Lanelet map (a lanelet with the subtype road_shoulder, or the side of a road lane).
• Demonstrations (2023): simple pull out video and backward pull out video.

Path shift#

Shift the path sideways because of an external instruction.

• Module: Side Shift. Launch argument: launch_side_shift_module.
• Needs: A lateral offset request on the lateral_offset input of the Behavior Path Planner.

Velocity planning for obstacles and road shape#

Obstacle stop#

Plan the velocity to stop for an obstacle on the path.

• Module: Obstacle Stop in the Motion Velocity Planner. Launch argument: launch_obstacle_stop_module.
• Needs: Object information.
• Demonstration: obstacle stop video (2023, recorded before this function moved to the Motion Velocity Planner in 2025).

Obstacle deceleration#

Plan the velocity to slow down for an obstacle near the path.

• Module: Obstacle Slow Down in the Motion Velocity Planner. Launch argument: launch_obstacle_slow_down_module.
• Needs: Object information.
• Demonstration: obstacle deceleration video (2023, recorded before this function moved to the Motion Velocity Planner in 2025).

Adaptive cruise control#

Plan the velocity to follow the vehicle in front of the ego vehicle.

• Module: Obstacle Cruise in the Motion Velocity Planner. Launch argument: launch_obstacle_cruise_module.
• Needs: Object information.

Deceleration for cut-in vehicles#

Plan the velocity to reduce the risk from a vehicle that cuts in to the ego lane.

• Module: Obstacle Cruise in the Motion Velocity Planner.
• Needs: Object information.

Surround check at start#

Plan the velocity to keep the vehicle stopped while an obstacle is near the vehicle. It works only when the vehicle is stopped.

• Module: Surround Obstacle Checker. Launch argument: launch_surround_obstacle_checker (false in the default preset).
• Needs: Object information.
• Demonstration: surround obstacle checker video (2023).

Run-out check#

Plan the velocity to slow down or stop for objects that can run out into the path.

• Module: Run Out in the Motion Velocity Planner. Launch argument: launch_run_out_module.
• Needs: Object information.
• Demonstration: run out video (2023). It shows the earlier Run Out module of the Behavior Velocity Planner, which Autoware removed in 2025.

Collision check when the vehicle leaves its lane#

Plan the velocity to prevent a collision with vehicles in another lane when the ego vehicle goes out of its own lane, for example when a large vehicle takes a narrow turn.

• Module: Out of Lane in the Motion Velocity Planner. Launch argument: launch_out_of_lane_module.
• Needs: Object information and Lanelet map (driving lanes).

Curve deceleration#

Plan the velocity to slow down in a curve.

• Module: Velocity Smoother. It limits the lateral acceleration with the parameter lateral_acceleration_limits.
• Needs: Nothing.

Curve deceleration for obstacles#

Plan the velocity to slow down in a curve when an obstacle near the path can cause a collision.

• Module: Obstacle Velocity Limiter in the Motion Velocity Planner. Launch argument: launch_obstacle_velocity_limiter_module.
• Needs: Lanelet map (line strings with a type from the static_map_tags parameter, guard_rail by default). The parameter obstacles.dynamic_source can add the point cloud or the occupancy grid as obstacle sources (static_only by default).
• Demonstration: obstacle velocity limiter video (2023, when the function was a separate node).

Traffic rules#

Crosswalk#

Plan the velocity to stop or slow down for pedestrians who approach or walk on a crosswalk.

• Module: Crosswalk in the Behavior Velocity Planner. Launch argument: launch_crosswalk_module.
• Needs: Object information and Lanelet map (pedestrian crossing).
• Demonstration: crosswalk video (2023).

Stop line#

Plan the velocity to stop at a stop line.

• Module: Stop Line in the Behavior Velocity Planner (Autoware Core). Launch argument: launch_stop_line_module.
• Needs: Lanelet map (a traffic sign regulatory element with a stop line).
• Demonstration: stop line video (2023).

Traffic light#

Plan the velocity at an intersection from the traffic light signal.

• Module: Traffic Light in the Behavior Velocity Planner. Launch argument: launch_traffic_light_module.
• Needs: Traffic light state information and Lanelet map (traffic light regulatory elements with stop lines).
• Demonstration: traffic light video (2023).

Intersection: oncoming vehicle check#

Plan the velocity for a right or left turn at an intersection, to prevent a collision with oncoming vehicles.

• Module: Intersection in the Behavior Velocity Planner. Launch argument: launch_intersection_module.
• Needs: Object information and Lanelet map (intersection lanes with the turn_direction tag, and right_of_way regulatory elements with yield lanes).
• Demonstration: intersection video (2023).

Intersection: blind spot check#

Plan the velocity for a right or left turn at an intersection, to prevent a collision with vehicles, motorcycles, or bicycles that come from behind in the blind spot.

• Module: Blind Spot in the Behavior Velocity Planner. Launch argument: launch_blind_spot_module.
• Needs: Object information and Lanelet map (intersection lanes with the turn_direction tag).
• Demonstration: blind spot video (2024).

Intersection: occlusion check#

Plan the velocity for a right or left turn at an intersection, to reduce the risk from vehicles that can come out of an occluded area.

• Module: Intersection in the Behavior Velocity Planner.
• Needs: Object information, the occupancy grid map, and Lanelet map (intersection lanes with the turn_direction tag).
• Demonstration: intersection occlusion video (2024).

Intersection: traffic jam detection#

Plan the velocity so that the vehicle does not enter an intersection when a vehicle is stopped after it because of a traffic jam.

• Module: Intersection in the Behavior Velocity Planner.
• Needs: Object information and Lanelet map (intersection lanes with the turn_direction tag).
• Demonstration: intersection traffic jam video (2024).

Merge from a private area to a public road#

Plan the velocity to enter a public road from a private area, to prevent a collision with pedestrians or other vehicles.

• Module: the merge from private road function of the Intersection module. Launch argument: launch_merge_from_private_module (false in the default preset).
• Needs: Lanelet map (an intersection lane with the turn_direction tag and the location=private tag, which leads to a lane that does not have the location=private tag). The function stops the vehicle once at the stop line. It does not read object information. The Intersection module checks the other vehicles.

No stopping area#

Plan the velocity so that the vehicle does not stop in an area where stopping is not permitted, for example in front of the exit of a fire station.

• Module: No Stopping Area in the Behavior Velocity Planner. Launch argument: launch_no_stopping_area_module.
• Needs: Object information (stopped vehicles after the area) and Lanelet map (a no_stopping_area regulatory element).

Detection area#

Plan the velocity to stop at the stop line of a detection area when an object is in the area.

• Module: Detection Area in the Behavior Velocity Planner. Launch argument: launch_detection_area_module.
• Needs: Lanelet map (a detection_area regulatory element) and the obstacle point cloud. The target_filtering parameters can also select object classes from the object information (none by default).
• Demonstration: detection area video (2023).

Speed bump#

Plan the velocity to slow down for a speed bump.

• Module: Speed Bump in the Behavior Velocity Planner. Launch argument: launch_speed_bump_module (false in the default preset).
• Needs: Lanelet map (a speed_bump regulatory element).
• Demonstration: speed bump video (2024).

No drivable lane#

Plan the velocity to stop before a lane that is outside the operational design domain (ODD). If autonomous mode starts in such a lane, stop the vehicle.

• Module: No Drivable Lane in the Behavior Velocity Planner. Launch argument: launch_no_drivable_lane_module (false in the default preset).
• Needs: Lanelet map (lanelets with the no_drivable_lane=yes tag).

Occlusion spot check#

Plan the velocity to slow down for objects that can come out of an occluded area, for example from behind a building or a large vehicle.

• Module: Occlusion Spot in the Behavior Velocity Planner. Launch argument: launch_occlusion_spot_module (false in the default preset).
• Needs: The occupancy grid map (detection_method: occupancy_grid, the default) or object information (detection_method: predicted_object). The occupancy grid method also uses object information. With use_partition_lanelet (the default), it also uses Lanelet map line strings of the types guard_rail, fence, and wall.
• Demonstration: occlusion spot video (2024).

Parking#

Parking#

Plan the path and the velocity to a goal in a parking area.

• Modules: Freespace Planner and Costmap Generator. Launch argument: launch_parking_module.
• Needs: Object information and Lanelet map (parking area).
• Demonstration: free space parking video (2023).

Safety#

Trajectory validation#

Make sure that the planned trajectory is safe. If it is not safe, take an action: for example, change the trajectory, stop sending it, or report the problem to the autonomous driving system.

• Module: Planning Validator with its checker plugins.
• Needs: Nothing.

Autonomous emergency braking (AEB)#

Do an emergency stop if a collision with an object ahead is predicted. This function is the last safety layer. It must work even when localization or perception fails.

• Module: Autonomous Emergency Braking in the control component. Launch argument: launch_autonomous_emergency_braking (control preset).
• Needs: Primitive objects (point clouds).

Minimum risk maneuver (MRM)#

Give the correct minimum risk maneuver when a hazardous event occurs. For example, when a sensor fails, send an instruction for an emergency stop, a comfortable stop, or a pull over to the shoulder, for the severity of the situation.

• Modules: the MRM Handler in the system component selects the MRM. Operators such as the MRM Emergency Stop Operator and the MRM Comfortable Stop Operator do it.
• Needs: The system state.

Map tools#

Running lane map generation#

Make a lane map from the localization data that you record during manual driving.

• Tool: bag2lanelet in autoware_tools.
• Needs: A rosbag with the /tf topic, recorded while you drive the route.

Running lane optimization#

Optimize the centerline (the reference path) of the map, so that it is smooth for the vehicle kinematics.

• Tool: Static Centerline Generator in autoware_tools.
• Needs: Lanelet map (driving lanes).

Reference implementation#

This diagram shows the reference implementation of the planning component. You can add new modules or extend the functions to support different ODDs.

The implementation does not follow the high-level architecture in some areas, because of implementation difficulties. These areas need an update.

The launch files are in autoware_planning_launch in autoware_launch. A module preset selects the modules that launch. The default preset is default_preset.yaml in autoware_planning_config. To use another preset, set the planning_module_preset launch argument. For more information, see how to enable or disable a planning module.

Nodes#

Autoware Core also has a minimal planning pipeline in autoware_core_planning: the mission planner, the path generator, the behavior velocity planner, the motion velocity planner, and the velocity smoother.

Behavior path planner modules#

Lane following is not a separate module. The behavior path planner itself makes the reference path from the lane centerline.

Behavior velocity planner modules#

Motion velocity planner modules#

Planning validator checkers#

Important information in the current implementation#

The current implementation has two important differences from the high-level design: the scenario layer, and the clear separation of behavior and motion. The current performance and implementation difficulties are the reasons for these differences. It is still open whether to add them to the high-level design or to change the implementation.

The scenario planning layer#

Driving in structured lanes and driving in free space, for example a parking lot, need different interfaces. For example, lane driving can use a route of map IDs, but planning in free space cannot. The scenario layer switches the planning sub-components for each scenario (lane driving, parking, and others). This gives a flexible interface design. But it is difficult to use the same modules in different scenarios.

Separation of behavior and motion#

A classic approach divides planning into "behavior", which decides the action, and "motion", which calculates the final movement. But this separation decreases the performance, and the performance decreases more when the separation increases. For example, behavior makes decisions without the result of the motion calculation, so its decisions are usually conservative. If behavior and motion are one part, the motion performance and the decisions depend on each other. Then it is difficult to extend only the decisions, for example for the traffic rules of a region.

This earlier design discussion gives more background.

Customize features in the current implementation#

You can add functions at the module level in the current implementation. But not all functions have a common interface. This section describes how to extend the current implementation at the module level.

Add a module to a planner node#

The behavior path planner, the behavior velocity planner, and the motion velocity planner load their modules as plugins. The planning validator loads its checkers as plugins too. If you write a module that follows the module interface of the node, the node can load and unload it. The documentation of each package explains how to add a module. For example, the template module is a starting point for a new behavior velocity module.

Add a ROS node to the planning component#

You can also add a function as a ROS node in motion planning. Each node in the current pipeline adds information to the trajectory that the nodes before it calculated. A new node in this pipeline can extend the functions.

Add or replace a scenario#

The current implementation switches between scenarios. With this switch, you can change many modules together. You can also add a new scenario, for example highway driving.

To add a scenario, make it a ROS node and connect it to the scenario_selector node. A new scenario can add large new functions without an effect on the other scenarios, for example lane driving. But scenarios coordinate only through the scenario switch. They cannot coordinate with the existing planning modules.