The Behavior Path Planner

The vehicle knows where it is. It knows what is around it. Now it must decide where to go.¹ That decision belongs to the planner, and the planner reads the Lanelet2 map directly.

Autoware’s planning stack is layered. The behavior path planner sits at the top, making tactical decisions: stay in lane, change lanes, avoid an obstacle, stop at a goal. The motion planner sits below it, turning those decisions into a smooth trajectory with velocities and accelerations. Within the behavior layer, a companion velocity planner handles the other half of the decision: not where to drive, but how fast, stopping at stop lines, slowing for crosswalks, and obeying speed limits. This chapter focuses on the behavior layer, because it is the layer that reads the map you built. Every lanelet boundary, every speed limit, every regulatory element, every topological edge you authored enters the planner through a single structure and constrains every decision the planner makes.

The planner manager

The behavior path planner is organized around a manager that coordinates a set of scene modules. Each module handles one kind of maneuver. Lane Following generates a reference path from the lanelet centerline. Static Obstacle Avoidance shifts that path laterally around parked vehicles and barriers. Lane Change moves the vehicle from one lane to another when the route requires it. Goal Planner handles the final approach when the destination is in a shoulder lane. Start Planner handles merging from a shoulder lane back into a driving lane.

The manager’s job is to decide which modules run and in what order. It does this through a two-stack execution model. Modules that have been approved via the Request to Cooperate (RTC) protocol run on the approved stack, in series, each receiving the previous module’s output path. Modules requesting execution but not yet approved run on the candidate stack, in parallel, and their outputs are held until RTC approval arrives. This gating ensures that a lane change, which shifts the vehicle into an adjacent lane, cannot execute until the safety check confirms the target lane is clear.

Each cycle, the manager runs the approved modules to produce a path, feeds that path to every registered module to see which ones request modification, selects the requesting modules that are compatible with the current approved stack, and runs the candidates sorted by priority. Priority is a static configuration value per module type: the smaller the number, the earlier the module runs. If the highest-priority candidate is still waiting for approval, the cycle returns the approved path without the unapproved modification.

Priority matters when two modules request in the same cycle. Picture the tug approaching the Harbor Yard gate: the route requires a lane change from the loop lane into the exit lane, and a parked flatbed blocks half the loop lane just before the branch. Lane Change and Static Obstacle Avoidance both request. Avoidance carries the smaller priority number, so it runs first, and its laterally shifted path becomes the input Lane Change plans over: the tug clears the flatbed first, then changes lanes from the shifted path. Had the order been reversed, Lane Change would have committed to a maneuver whose starting position Avoidance was about to move, and the two modules would have spent the cycle planning against a path neither would actually drive.

How the map feeds planning

The map enters this process through PlannerData, a structure the manager populates each cycle from the Lanelet2 map and the current route. PlannerData carries the lanelet the vehicle is currently in, the reference centerline for that lanelet, the lanelet boundaries, the speed limit, the successors in the topology graph, and any regulatory elements attached to the current lanelet chain. Every scene module receives PlannerData and uses it to constrain its output.

The Lane Following module takes the lanelet centerline as its reference path. The Avoidance module reads the lanelet boundaries and will not shift the path beyond them, because the map says nothing drivable exists outside the lanelet. The Lane Change module reads the topology graph to find lanelets adjacent to the current one and checks whether a lane change is legal there. The Goal Planner reads the lanelet type to determine whether the goal is in a driving lane or a shoulder lane, and behaves differently for each.

Each map element you author becomes a constraint the planner works within. A lanelet boundary is a lateral constraint: the path stays inside it. A speed limit on a lanelet is a longitudinal constraint: the path obeys it. A stop line regulatory element is a behavioral constraint: the path reaches zero velocity at the refline. Topology is a routing constraint: the only lanelets the planner will transition into are the ones declared as successors.

A cycle in the life of a lanelet

Consider the loop road at Harbor Yard. The vehicle enters lanelet L7, a 25-meter straight segment with a speed limit of 5 mph and two successors: L8 (the loop continues) and LD1 (the dock access branch). The route says the vehicle is heading to the loading dock, so the planner knows LD1 is the target successor. A parked cargo tug sits in L7, blocking the right half of the lane.

The Lane Following module generates a reference path down the centerline of L7. The Avoidance module sees the parked tug in the PlannerData obstacle list, computes a lateral shift that moves the path left by 1.2 meters, checks that the shifted path stays within the L7 lanelet boundaries, and requests RTC approval. The manager runs Lane Following on the approved stack and Avoidance on the candidate stack. When Avoidance is approved, it joins the approved stack and its shifted path becomes the output.

None of this requires the modules to know what a cargo tug is. The Avoidance module sees an occupied region in the lanelet, computes a path around it, and verifies the path does not leave the lanelet. The lanelet boundary you traced is the fence the path cannot cross. The centerline you drew is the nominal path the path returns to after the obstacle is cleared. Every decision the planner made was framed by map elements you authored.

Control: executing the plan

The planner produces a trajectory. The control component turns it into steering, throttle, and brake commands. Planning asks “where should I go?” Control answers “how do I make the vehicle do that?”

Autoware’s control stack has two modules. The trajectory follower computes the control commands needed to track the planned trajectory: a target steering angle, a target speed, and a target acceleration. The vehicle command gate sits between the follower and the vehicle, filtering out command values that exceed safe limits and arbitrating among competing sources. If the trajectory follower issues a command that would exceed the vehicle’s physical capabilities, the gate clamps it. If the system enters a minimal risk maneuver, the gate switches to the emergency command source.

The trajectory follower works with generic quantities: steering angle in radians, speed in meters per second, acceleration in meters per second squared. It never issues brake pressure or pedal position. Those are vehicle-specific, and the control component deliberately stays vehicle-agnostic. A dedicated vehicle adapter converts the generic commands into the drive-by-wire interface for the specific vehicle: pedal position and brake pressure for a Lexus, EPS voltage and hydraulic pressure for a GSM8, yaw rate for a golf cart. The adapter also compensates for known delays in the drivetrain response, applies slope compensation using the map gradient or the chassis pitch sensor, and corrects for steering zero-point drift.

Control does not read the map. It reads the trajectory that the planner generated from the map. But every constraint the planner encoded from the map flows through as a physical command. The lanelet centerline set the reference path. The speed limit constrained the velocity. The stop line regulatory element forced a zero-velocity waypoint. The lanelet boundary you traced a hundred meters ago is now a steering correction keeping the vehicle 30 centimeters from the curb. The map is not in the control loop. Its consequences are in every loop iteration.

Try this

[10 min] Trace three map elements through the planner and identify the constraint each imposes.

1. Pick the speed limit on the Harbor Yard loop road (5 mph). Find it in the Lanelet2 file. In PlannerData, it arrives as a longitudinal constraint on the lanelet chain. In the Lane Following module, it caps the velocity on the reference path. The 5 mph you typed into the editor is the 5 mph the planner will not exceed.
2. Pick the gatehouse stop line. In PlannerData, it is a regulatory element with a refline. In the planner, it is a zero-velocity constraint at that refline. The stop line you traced and the regElem you attached become a hard stop the planner cannot override.
3. Pick the successor topology from L7 to LD1. In PlannerData, it is the list of legal next lanelets. In the Lane Change and routing logic, it is the only place the planner is allowed to go. Without that edge, the dock access road is invisible to the planner even though the geometry touches.

Footnotes

1. Strictly speaking, the behavior planner does not choose the destination. A mission planner computes the route from the vehicle’s current position to its goal once, the moment the goal is set; everything in this chapter then runs along that route, every cycle, for the rest of the trip. ↩