map_based_prediction

Role

map_based_prediction is a module to predict the future paths (and their probabilities) of other vehicles and pedestrians according to the shape of the map and the surrounding environment.

Assumptions

• The following information about the target obstacle is needed
  • Label (type of person, car, etc.)
  • The object position in the current time and predicted position in the future time.
• The following information about the surrounding environment is needed
  • Road network information with Lanelet2 format

Inner-workings / Algorithms

Flow chart

Path prediction for road users

Remove old object history

Store time-series data of objects to determine the vehicle’s route and to detect lane change for several duration. Object Data contains the object’s position, speed, and time information.

Get current lanelet and update Object history

Search one or more lanelets satisfying the following conditions for each target object and store them in the ObjectData.

• The CoG of the object must be inside the lanelet.
• The centerline of the lanelet must have two or more points.
• The angle difference between the lanelet and the direction of the object must be within the threshold given by the parameters.
  • The angle flip is allowed, the condition is diff_yaw < threshold or diff_yaw > pi - threshold.
• The lanelet must be reachable from the lanelet recorded in the past history.

Get predicted reference path

• Get reference path:
  • Create a reference path for the object from the associated lanelet.
• Predict object maneuver:
  • Generate predicted paths for the object.
  • Assign probability to each maneuver of Lane Follow, Left Lane Change, and Right Lane Change based on the object history and the reference path obtained in the first step.
  • Lane change decision is based on two domains:
    • Geometric domain: the lateral distance between the center of gravity of the object and left/right boundaries of the lane.
    • Time domain: estimated time margin for the object to reach the left/right bound.

The conditions for left lane change detection are:

• Check if the distance to the left lane boundary is less than the distance to the right lane boundary.
• Check if the distance to the left lane boundary is less than a dist_threshold_to_bound_.
• Check if the lateral velocity direction is towards the left lane boundary.
• Check if the time to reach the left lane boundary is less than time_threshold_to_bound_.

Lane change logics is illustrated in the figure below.An example of how to tune the parameters is described later.

• Calculate object probability:
  • The path probability obtained above is calculated based on the current position and angle of the object.
• Refine predicted paths for smooth movement:
  • The generated predicted paths are recomputed to take the vehicle dynamics into account.
  • The path is calculated with minimum jerk trajectory implemented by 4th/5th order spline for lateral/longitudinal motion.

Undetected lane-change path suppression

• CCF (Collision Check Filter, a downstream planning module) follows a policy of not evaluating other vehicles’ lane-change (LC) paths; prediction omits undetected LC branches while retaining detected LC and lane-end LC needed to leave a terminating lane.
• Applies to car, truck, bus, trailer and motorcycle: LC candidates are suppressed per current lanelet, only when that lanelet has its own lane-follow candidate and its detected maneuver is lane-follow. A current lanelet without a lane-follow candidate keeps all of its candidates.
• History retains all future possible lanelets before suppression; surviving path confidences use the existing normalization.
• lane_change_path_suppression.enable (bool, default true): false restores the original behavior.
• lane_change_path_suppression.keep_when_lane_ends (bool, default true): retain LC if any following-only branch from the current lanelet ends without routing-graph followers within max(speed, 1.0 m/s) × lane_end_rescue_time_horizon, measured as the sum of centerline lengths minus the projected arc length on the current lanelet, independently of center-candidate acceptance; false disables this exception.
• lane_change_path_suppression.lane_end_rescue_time_horizon (double, default 5.0, minimum 0.0, seconds): independent rescue horizon; vehicle prediction horizon does not affect this limit. Urban maps can have following-only lanelet chains terminate after 100–200 m at intersections or disconnected map links. The 5.0 s default restricts rescue to nearby merges a few seconds ahead instead of those distant apparent ends.
• Routable lateral adjacency is not required: merge boundary/connectivity representations may lack a lane-change relation; requiring it would lose the rescue in those cases.
• DEBUG logs report each LC candidate decision (suppressed, kept_detected_lc, kept_lane_end, kept_no_center), object ID, current lanelet, and terminal distance in meters (-1 means no terminal found within the rescue bound, or rescue disabled). These are suppression-stage decisions; a later center-path rejection can still restore held LC paths.
• Suppressed LC candidates are held until pose conversion, starting-position search, prediction generation and lateral-acceleration checks finish. Held LC candidates are restored only for the current lanelets whose lane-follow prediction (from a reference path with two or more points) was not accepted; a one-point lane-follow reference still yields the straight path of the path generator as before. When every lanelet’s center survives, no second processing pass occurs.

Tuning lane change detection logic

Currently we provide three parameters to tune lane change detection:

• dist_threshold_to_bound_: maximum distance from lane boundary allowed for lane changing vehicle
• time_threshold_to_bound_: maximum time allowed for lane change vehicle to reach the boundary
• cutoff_freq_of_velocity_lpf_: cutoff frequency of low pass filter for lateral velocity

You can change these parameters in rosparam in the table below.

Tuning threshold parameters

Increasing these two parameters will slow down and stabilize the lane change estimation.

File truncated at 100 lines see the full file

Changelog for package autoware_map_based_prediction

0.53.0 (2026-09-29)

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

• perf(map_based_prediction): vru path-cut follow-up optimizations (#13238)

  * fix(map_based_prediction): cut at the earliest fence crossing The candidate loop stopped at the first crossed fence in R-tree order, so a different fence crossing earlier along the path was never examined and the cut landed too late. Collect every crossed fence; the segment loop already returns the earliest crossing. Co-Authored-By: Claude Fable 5 <<noreply@anthropic.com>>

  * perf(map_based_prediction): convert path-cut map geometry once at load Vegetation polygons are converted to boost polygons and validated when the map arrives; the per-cycle loops look the conversions up by id. A vegetation-free map leaves the layer null so queries short-circuit. Road boundaries are converted to 2D once per crossed boundary and crosswalk rings are cached at load. Bounds shared by two road-subtype lanelets are interior lane dividers and are dropped from the boundary layer: a path from outside the road always reaches an outer edge first. Co-Authored-By: Claude Fable 5 <<noreply@anthropic.com>>

  * perf(map_based_prediction): cheapen vegetation crossing tests Cylinder footprints sweep the centerline buffered by their radius, so segment-vs-polygon distance tests replace the per-segment convex hulls and are exact; box and polygon shapes keep the hulls but reuse each segment's end footprint as the next start. Candidates are gated by one centerline-to-polygon distance test in place of the N-footprint bounding box, and the R-tree query box is grown by the footprint radius so polygons reachable by the swept footprint are not missed. The road-boundary segment test resolves intersection points in a single sweep, keeping intersects() only as the collinear-overlap fallback. Co-Authored-By: Claude Fable 5 <<noreply@anthropic.com>>

  * perf(map_based_prediction): build each predicted-path linestring once The caller converts a path to a 2D linestring once and hands it to the fence and vegetation modules; the fence-cut prefix is reused for the vegetation cut. Fences crossed by a path are converted to 2D once instead of per segment, and the road-boundary module shares the utils conversion helper. Co-Authored-By: Claude Fable 5 <<noreply@anthropic.com>>

  * test(map_based_prediction): add VRU path-cut module tests Synthetic in-memory lanelet maps pin the behavior the modules must preserve: earliest-crossing cut index, the initial-overlap exemption, detection of polygons reachable only by the swept footprint, invalid map polygons skipped at load, interior lane dividers excluded from the boundary layer, the crosswalk signal exemption, and the can-stop gate. Co-Authored-By: Claude Fable 5 <<noreply@anthropic.com>> ---------Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

• feat(map_based_prediction): add vegetation path cutting (#13190)

  * feat(map_based_predictor): add vegitation path cut , (#3113) add path cut function by vegetation (cherry picked from commit 7be16b3d11cf67fd67fff0fecb482ed8157f3cd2)

  • chore(map_based_prediction): remove path cut debug

  * feat(map_based_prediction): judge vegetation path cut on path segments (#3221) Cherry-picked vegetation.cpp changes from tier4/autoware_universe#3221, excluding test_vegetation.cpp. (cherry picked from commit 2e365e13641e084f5d0f55194deb0a2577c751fe)

  • refactor(map_based_prediction): remove vegetation info precheck
  • perf(map_based_prediction): skip precise path cut checks by bbox
  • perf(map_based_prediction): skip vegetation cross checks by bbox
  • style(map_based_prediction): use at for indexed path access

  * fix(map_based_prediction): hold the vegetation layer as a const map vegetation_layer_ was a non-const LaneletMapUPtr, so polygonLayer.search() selected the non-const overload and returned std::vector<lanelet::Polygon3d>, which does not bind to the const lanelet::ConstPolygons3d & the crossing helpers take. The layer is only ever searched after being built, so hold it as a LaneletMapConstUPtr; search() then returns ConstPolygons3d directly and the call sites need no conversion. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>

  * fix(map_based_prediction): keep the path footprint polygon alive while iterating buildPathFootprintBBox() iterated over to_polygon2d(...).outer() directly. to_polygon2d() returns by value and outer() returns a reference into it, but in a range-for only the result of the range expression is lifetime-extended, so the Polygon2d temporary was destroyed before the loop body ran. GCC 13 reports the dangling access as -Werror=maybe-uninitialized, which broke the Jazzy CI build. Bind the footprint to a named local so it

File truncated at 100 lines see the full file