Path Sampler

Purpose

This package implements a node that uses sampling based planning to generate a drivable trajectory.

Feature

This package is able to:

• make the trajectory smooth;
• keep the trajectory inside the drivable area;
• avoid static obstacles;
• stop if no valid trajectory can be generated.

Note that the velocity is just taken over from the input path.

Inputs / Outputs

input

output

Algorithm

Sampling based planning is decomposed into 3 successive steps:

1. Sampling: candidate trajectories are generated.
2. Pruning: invalid candidates are discarded.
3. Selection: the best remaining valid candidate is selected.

Sampling

Candidate trajectories are generated based on the current ego state and some target state. 2 sampling algorithms are currently implemented: sampling with bézier curves or with polynomials in the frenet frame.

Pruning

The validity of each candidate trajectory is checked using a set of hard constraints.

• collision: ensure no collision with static obstacles;
• curvature: ensure smooth curvature;
• drivable area: ensure the trajectory stays within the drivable area.

Selection

Among the valid candidate trajectories, the best one is determined using a set of soft constraints (i.e., objective functions).

• curvature: prefer smoother trajectories;
• length: prefer longer trajectories;
• lateral deviation: prefer trajectories close to the reference path.

Each soft constraint is associated with a weight to allow tuning of the preferences.

Limitations

The quality of the candidates generated with polynomials in frenet frame greatly depend on the reference path. If the reference path is not smooth, the resulting candidates will probably be undriveable.

Failure to find a valid trajectory current results in a suddenly stopping trajectory.

Comparison with the autoware_path_optimizer

The autoware_path_optimizer uses an optimization based approach, finding the optimal solution of a mathematical problem if it exists. When no solution can be found, it is often hard to identify the issue due to the intermediate mathematical representation of the problem.

In comparison, the sampling based approach cannot guarantee an optimal solution but is much more straightforward, making it easier to debug and tune.

How to Tune Parameters

The sampling based planner mostly offers a trade-off between the consistent quality of the trajectory and the computation time. To guarantee that a good trajectory is found requires generating many candidates which linearly increases the computation time.

TODO

Drivability in narrow roads

Computation time

Robustness

Other options

How To Debug

TODO

Changelog for package autoware_path_sampler

0.53.0 (2026-09-29)

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

• fix(design): align the planning node designs with the packages they describe (#13342)

  * fix(design): align the planning node designs with the packages they describe HazardLightsSelector registers as HazardLightsSelector, and its second input maps to input/system/hazard_lights_command and carries the MRM command, so the port is named system_hazard_lights_cmd. SurroundObstacleChecker publishes the migrated autoware_internal_planning_msgs velocity limit types, and creates neither stop_reasons nor no_start_reason. RemainingDistanceTimeCalculator takes its velocity limit input through the design graph; global: keeps a port out of it, since link_manager skips any connection whose target is a global input port and the exporter emits no remap. ExternalVelocityLimitSelector's api_limit is the reverse case: it is published only by AD API adaptors outside the design graph, so it keeps global: alongside its remap_target. #13165 unified the Modifier and Optimizer nodes into TrajectoryProcessor but left both old designs in place, naming plugins, executables and param files that no longer exist, and put the new design in common/autoware_universe_designs, a bare directory that is not a ROS package. The design moves into autoware_trajectory_processor per the convention set by #13102, and its processing_time_detail publisher carries ProcessingTimeTree.

  * feat(autoware_path_sampler): add the packaged path sampler parameter file The package had no config/ directory and its INSTALL_TO_SHARE was commented out, so the parameter file the node design points at lived only in autoware_launch. The file is copied into the package and installed, and the design declares the three shared param files the launcher also passes, which is where ego_nearest_dist_threshold and ego_nearest_yaw_threshold come from.

  * feat(design): add the planning factor publishers to the BehaviorPathPlanner node design The node publishes nine planning factor arrays under /planning/planning_factors that the design did not declare, so nothing could connect them to the evaluator. ---------

• refactor(planning): move node design files into each package (#13102) Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>

• Contributors: Ryohsuke Mitsudome, Taekjin LEE

0.52.0 (2026-06-30)

0.51.0 (2026-05-01)

0.50.0 (2026-02-14)

• Merge remote-tracking branch 'origin/main' into humble
• fix(path_sampler): avoid redundant matrix transpose (#11922)
• Contributors: Mete Fatih Cırıt, Ryohsuke Mitsudome

0.49.0 (2025-12-30)

0.48.0 (2025-11-18)

• Merge remote-tracking branch 'origin/main' into humble
• fix: tf2 uses hpp headers in rolling (and is backported) (#11620)
• Contributors: Ryohsuke Mitsudome, Tim Clephas

0.47.1 (2025-08-14)

0.47.0 (2025-08-11)

0.46.0 (2025-06-20)

0.45.0 (2025-05-22)

0.44.2 (2025-06-10)

0.44.1 (2025-05-01)

0.44.0 (2025-04-18)

0.43.0 (2025-03-21)

• Merge remote-tracking branch 'origin/main' into chore/bump-version-0.43
• chore: rename from [autoware.universe]{.title-ref} to [autoware_universe]{.title-ref} (#10306)
• Contributors: Hayato Mizushima, Yutaka Kondo

0.42.0 (2025-03-03)

File truncated at 100 lines see the full file