autoware_mrm_in_lane_stop_operator

Overview

The autoware_mrm_in_lane_stop_operator is a ROS 2 node that implements a Minimum Risk Maneuver (MRM) operator specifically designed for in-lane stop functionality. It acts as a bridge between the driving mode manager and the in-lane stop execution modules (e.g., in_lane_mrm_planner).

System Role

In the MRM decision flow:

1. Driving Mode Manager detects an emergency or fallback condition and issues a driving mode request for in-lane stop MRM
2. MrmInLaneStopOperator receives the activation request and:
   • Validates the requested mode against configured modes
   • Communicates with the relay controller to enable the in-lane stop trigger topic
   • Publishes InLaneStopTrigger messages to signal the in-lane stop planner to execute the maneuver with the mode’s configured profile
   • Tracks MRM state transitions (UNKNOWN → NORMAL/OPERATING → SUCCEEDED)
   • Detects when the vehicle has come to a complete stop
3. In-lane Stop Execution Modules (e.g., in_lane_mrm_planner) receive the trigger and execute the controlled deceleration trajectory

Key Characteristics

• Operates at a higher level than motion control; focuses on mode lifecycle management and relay coordination
• Relies on polling-based vehicle stop detection for robust state confirmation
• Ensures relay service availability before committing to mode activation (fail-safe behavior)
• Publishes both MRM state and per-mode DrivingModeActive flags for system-wide visibility

Features

• Flexible Driving Mode Management: Support for multiple configurable driving modes with per-mode deceleration profiles
• Relay Service Control: Seamlessly switches between normal operation and MRM mode via topic relay control
• MRM State Machine: Tracks MRM operation state (UNKNOWN → NORMAL/OPERATING → SUCCEEDED)
• Vehicle Stop Detection: Polls kinematic state to detect when the vehicle has come to a complete stop
• Driving Mode Active Flags: Per-mode publication of DrivingModeActive flags for external monitoring
• Configurable Launch Parameters: All topic and service endpoints can be remapped via launch arguments

Architecture

Input/Output

Subscriptions

• /localization/kinematic_state (nav_msgs/Odometry)
  • Vehicle odometry used for stop detection (polling, not callback-based)
• ~/input/driving_mode_request (tier4_system_msgs/DrivingModeRequest)
  • Requests to activate/deactivate driving modes
• ~/input/driving_mode_info (tier4_system_msgs/DrivingModeInfo)
  • Current driving mode status information

Publishers

• ~/output/mrm_state (tier4_system_msgs/DrivingModeMrmState)
  • MRM operation state (UNKNOWN, NORMAL, OPERATING, SUCCEEDED)
• ~/output/in_lane_stop_trigger (tier4_system_msgs/InLaneStopTrigger)
  • Trigger signal (with deceleration profile) for the in-lane stop planner when MRM is active
• ~/output/driving_mode_active (tier4_system_msgs/DrivingModeFlag)
  • Flags indicating active status for each configured driving mode

Service Clients

• ~/input/relay_service (tier4_system_msgs/ChangeTopicRelayControl)
  • Relay control of the topic that the MRM trajectory takes over (default: /system/topic_relay_controller_pose_with_covariance/operate)

MRM State Machine

┌─────────┐
│ UNKNOWN │  (initial state)
└────┬────┘
     │
     ├─ [mode requested inactive] → NORMAL
     │
     ├─ [mode requested active] → OPERATING
     │                  ↓
     │          [vehicle stopped] → SUCCEEDED
     │
     └─ [any error] → remains in current state

State Descriptions:

• UNKNOWN: Initial state before any mode request
• NORMAL: Mode is inactive (requested_mode_id is not set)
• OPERATING: Mode is active and vehicle is still moving
• SUCCEEDED: Mode is active and vehicle has stopped (abs(velocity) < 0.001 m/s)

Mode Transitions

on_request() decides what to do based on the requested mode’s deceleration profile, not its mode id:

• If the requested mode is not one of the configured modes, the currently active mode (if any) is cancelled.
• If the requested mode resolves to the same profile as the currently active mode, nothing happens, even if the mode id itself changed (a log message notes this case).
• If the profile differs, the node switches straight to the new mode without cancelling the previous one first.

Relay Service Integration

File truncated at 100 lines see the full file

Changelog for package autoware_mrm_in_lane_stop_operator

0.53.0 (2026-09-29)

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

• feat(autoware_mrm_in_lane_stop_operator): add node (#13332)

  • feat: add node
  • style(pre-commit): autofix
  • fix: refactor
  • fix: refactor
  • fix: spelling

  * feat(autoware_mrm_in_lane_stop_operator): switch trigger to InLaneStopTrigger with profile-based config Replace ConstantJerkDecelerationTrigger/target_acceleration/target_jerk with tier4_system_msgs/InLaneStopTrigger and a named deceleration profile (moderate/emergency) per mode. Extract ModeConfig into its own file with a profile_from_name() helper, and extract mode lookup/binding into a ModeTable class to keep the mode-name/id and profile-name/value associations in one place.

  * fix(autoware_mrm_in_lane_stop_operator): send mode's profile on cancel publish_trigger(false, ...) was passing PROFILE_UNKNOWN on cancel instead of the mode's own profile.

  • style(pre-commit): autofix

  * fix(autoware_mrm_in_lane_stop_operator): add missing includes for cpplint Add <utility> for std::move in mode_table.hpp and <string> in mode_config.cpp/mode_table.cpp, per cpplint's build/include_what_you_use.

  * feat(autoware_mrm_in_lane_stop_operator): use reliable + transient_local QoS for trigger topic Late-joining subscribers (e.g. the in-lane stop planner starting after this node) now receive the last published InLaneStopTrigger instead of missing it.

  * fix(autoware_mrm_in_lane_stop_operator): decouple skip_relay_call from trigger publish execute()/cancel() were only reached when skip_relay_call was false, due to short-circuit evaluation in on_request()'s condition and an early return in cancel_active_mode(). This meant InLaneStopTrigger was never published while skip_relay_call was true. skip_relay_call should only control whether the relay service is called; it must not affect whether or what gets published on the trigger topic. Move the flag check inside execute()/cancel() so the trigger is always published, and only the relay service call is skipped.

  * feat(autoware_mrm_in_lane_stop_operator): switch mode transitions on profile, not mode id Previously, requesting a different mode id always cancelled the current mode before activating the new one, even when both modes carried the same deceleration profile. Now:

  - If the newly requested mode resolves to the same profile as the currently active mode, do nothing, even if the mode id differs.

  - If the profile differs, switch straight to the new mode without an intermediate cancel.

  - Cancel only happens when the request is unhandled (not one of our configured modes) or when the requested mode's own profile is PROFILE_UNKNOWN.

  * feat(autoware_mrm_in_lane_stop_operator): log when mode changes but profile does not Makes the no-op path in on_request() observable when a different mode id is requested but resolves to the same profile as the currently active mode.

  * docs(autoware_mrm_in_lane_stop_operator): document profile-based mode transitions Explain on_request()'s no-op-on-same-profile and skip-cancel-on-profile-change behavior, and when cancellation actually happens. ---------Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>

• Contributors: Ryohsuke Mitsudome, Tetsuhiro Kawaguchi