autoware_in_lane_mrm_planner

MRM in-lane stop trajectory planner (Phase1).

Design

See docs/design_phase1.md and docs/implementation_plan_phase1.md.

Build

From pilot-auto.x2.v4.3.2 repository root (after workspace dependencies are installed):

./cmd_helper.sh --build_ccache --packages-select autoware_in_lane_mrm_planner

Do not run package builds in parallel with a full workspace build.

Launch

ros2 launch autoware_in_lane_mrm_planner in_lane_mrm_planner.launch.xml

In-lane stop trigger

The planner subscribes the trigger published by autoware_mrm_in_lane_stop_operator directly (the former mrm_trigger_relay node was removed).

The trigger only selects a deceleration profile; the constraint values are owned by the planner (mrm_velocity.profiles.<name>).

• Every cycle while unlatched, the path is planned once and a velocity profile is filled for every profile (moderate, emergency). The moderate candidate is published as the hot-standby output.
• trigger: true latches the candidate of the requested profile (the one planned in the previous cycle). If no candidate of that profile exists yet (e.g. the planner started after the trigger), the latch is retried every cycle.
• A profile change while triggered (e.g. moderate -> emergency) re-plans from the current state and re-latches the new profile. Only a candidate planned in that cycle is re-latched; if planning fails the current latch is kept and the re-latch is retried.
• trigger: false unlatches (and releases the latched objects).
• An unknown profile value (e.g. PROFILE_UNKNOWN) with trigger: true is treated as moderate and reported with a throttled error log.

Parameters: MRM stop velocity

Split parameter files per operation class if different constraint values are needed.

Road border stop (Phase2)

MrmRoadBorderStopPlanner (applied inside the trajectory modifier right after the obstacle stop) sweeps the vehicle footprint along the candidate trajectory from the ego nearest point and inserts a stop point road_border_stop.stop_margin before the first interference with a map road border. Boundaries are the lanelet2 linestrings whose type attribute is listed in road_border_stop.boundary_types_to_detect (default ["road_border"]); their segments are indexed in an R-tree that is rebuilt only when the map instance changes. The contact arc length is refined by bisection between the last non-interfering and the first interfering trajectory point. The stop point is never placed behind the ego. Deceleration feasibility is left to MrmStopVelocityPlanner, which relaxes deceleration / jerk of each profile up to mrm_velocity.profiles.<profile>.max_*_relaxation when the stop point is close.

The footprint sweep starts at the ego pose itself and then continues over the trajectory points ahead of the ego, so a border behind the vehicle is never reported.

Outputs:

The debug marker topic is relative to the node name, so with the default launch it resolves to /in_lane_mrm_planner/road_border_stop/debug/marker (not /planning/...). It contains the contact footprint, the contact segment / point and a stop virtual wall. The wall is drawn at the stop pose shifted by the vehicle front (max_longitudinal_offset), i.e. where the vehicle front will be when stopped.

While the trigger is latched the candidates are not re-planned. The planning factor and the

File truncated at 100 lines see the full file

Changelog for package autoware_in_lane_mrm_planner

0.53.0 (2026-09-29)

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

• feat(autoware_in_lane_mrm_planner): keep publishing road border stop reason while latched (#13432)

  * feat(autoware_in_lane_mrm_planner): keep publishing road border stop reason while latched While the in-lane stop trigger is latched the candidates are not re-planned, so the road border stop planning factor and debug markers stopped being published at the trigger and the stop reason disappeared from rviz during the MRM. Re-publish the contact the latched trajectory was planned with (debug markers and the planning factor, whose distance is measured from the current ego pose) until the trigger is released. The stop pose is kept with the contact since the latched trajectory may be resampled afterwards. Co-Authored-By: Claude Opus 5.5 (1M context) <<noreply@anthropic.com>>

  * refactor(autoware_in_lane_mrm_planner): remove unused RoadBorderContact::stop_index The stop point is now referenced by stop_pose only. Co-Authored-By: Claude Opus 5.5 <<noreply@anthropic.com>> ---------Co-authored-by: Claude Opus 5.5 (1M context) <<noreply@anthropic.com>>

• feat(autoware_in_lane_mrm_planner): add road border stop (#13430)

  * feat(autoware_in_lane_mrm_planner): add road border stop Insert a stop point before the vehicle footprint interferes with a map road border (REQ-003 of the in-lane stop planning design, Phase2). Ported from mkuri/autoware.universe feat/in-lane-mrm-planner-road-border-stop (69bc5ef3a, reviewed as TetsuKawa/autoware_universe#13) onto the InLaneStopTrigger / per-profile planner.

  - Add MrmRoadBorderStopPlanner: sweeps the footprint along the candidate trajectory from the ego nearest point, queries lanelet2 linestring segments of the configured types (default road_border) through an R-tree rebuilt only when the map instance changes, refines the contact arc length by bisection and inserts a stop point stop_margin before the contact, never behind the ego. Segments outside ego z +/- vehicle height are ignored.

  - Apply it in the trajectory modifier right after the obstacle stop, once per cycle on the shared base trajectory; the stop point reaches MrmStopVelocityPlanner as a zero velocity constraint for every profile, so deceleration relaxation (per profile) stays in one place.

  - Publish PlanningFactor (STOP) under in_lane_mrm_road_border_stop and debug markers (contact footprint / segment / point, stop virtual wall).

  • Add road_border_stop parameters (yaml, config, schema) and README section.

  - Add 11 unit tests with a synthetic lanelet map. Co-Authored-By: Claude Opus 5.5 (1M context) <<noreply@anthropic.com>>

  * fix(autoware_in_lane_mrm_planner): start road border contact search at the ego pose The sweep started at the trajectory point returned by findNearestSegmentIndex, i.e. the start of the segment the ego is on, up to one point interval behind base_link. A border just behind the ego rear could therefore be reported as a contact at the ego (stop at ego), and the debug contact footprint was drawn behind the vehicle.

  - Evaluate the ego footprint first, then only trajectory points ahead of the ego; the bisection refines between the ego pose and the first interfering point.

  - Keep the refined contact pose in RoadBorderContact and draw the debug contact footprint there (the contact index shifts when the stop point is inserted).

  - Add tests for a border behind the ego footprint and a contact refined from an ego pose between trajectory points. Co-Authored-By: Claude Opus 5.5 (1M context) <<noreply@anthropic.com>>

  * docs(autoware_in_lane_mrm_planner): document road border stop output topics The debug marker topic [~/road_border_stop/debug/marker]{.title-ref} is node-relative and resolves to [/in_lane_mrm_planner/road_border_stop/debug/marker]{.title-ref} with the default launch, not [/planning/...]{.title-ref} as assumed in verification procedures. List the planning factor and marker topics explicitly and describe the stop wall position and the ego-first footprint sweep. Co-Authored-By: Claude Opus 5.5 (1M context) <<noreply@anthropic.com>>

  • refactor(autoware_in_lane_mrm_planner): remove unused road border stop members

  - Remove the unused debug_footprints_ member and RoadBorderContact::contact_index (the stop point is based on

File truncated at 100 lines see the full file