Trajectory Follower Nodes

Purpose

Generate control commands to follow a given Trajectory.

Design

This is a node of the functionalities implemented in the controller class derived from autoware_trajectory_follower_base package. It has instances of those functionalities, gives them input data to perform calculations, and publishes control commands.

By default, the controller instance with the Controller class as follows is used.

@startuml
package autoware_trajectory_follower_base {
abstract class LateralControllerBase {

    virtual isReady(InputData)
    virtual run(InputData)

}
abstract class LongitudinalControllerInterface {

    virtual run(InputData, stamp, LateralSyncData)

}

struct InputData {
trajectory
odometry
steering
accel
}
struct LateralSyncData {
is_steer_converged
}
}

package autoware_mpc_lateral_controller {
class MPCLateralController {
isReady(InputData) override
run(InputData) override
}
}
package pure_pursuit {
class PurePursuitLateralController {
isReady(InputData) override
run(InputData) override
}
}
package pid_longitudinal_controller {
class PIDLongitudinalController {
run(InputData, stamp, LateralSyncData) override
}
}

package autoware_trajectory_follower_node {
class Controller {
longitudinal_controller_
lateral_controller_
onTimer()
createInputData(): InputData
}
}

MPCLateralController --|> LateralControllerBase
PurePursuitLateralController --|> LateralControllerBase
PIDLongitudinalController --|> LongitudinalControllerInterface

LateralSyncData ..> LongitudinalControllerInterface
InputData ..> LateralControllerBase
InputData ..> LongitudinalControllerInterface

LateralControllerBase --o Controller
LongitudinalControllerInterface --o Controller
InputData ..> Controller
@enduml

The process flow of Controller class is as follows.

```cpp // 1. create input data const auto input_data = createInputData(*get_clock()); if (!input_data) { return; }

// 2. check if the lateral controller is ready if (!lateral_controller_->isReady(*input_data)) { return; }

// 3. run controllers const auto lat_out = lateral_controller_->run(input_data); const auto lon_result = longitudinal_controller_->run(input_data, stamp, previous_lateral_sync_data_);

// 4. keep the lateral result for the longitudinal controller of the next cycle previous_lateral_sync_data_ = lat_out.sync_data;

File truncated at 100 lines see the full file

Changelog for package autoware_trajectory_follower_node

0.53.0 (2026-09-29)

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

• fix(design): align the control node designs with the packages they describe (#13340)

  * fix(design): align the control node designs with the packages they describe ControlCommandGate and the operation mode transition manager name a plugin class and pin publishers that do not match the built package: the registered component is ControlCmdGate, and the transition flags belong on the design graph rather than on global: pins that link_manager skips. TrajectoryFollower declares three debug publishers with message types the node never publishes and a stop_reason publisher it does not create at all. VehicleCmdGate keeps gate_mode and engage on their official topic names through remap_target: alone, so the two inputs are connected through the design.

  * fix(autoware_operation_mode_transition_manager): declare the system and legacy interfaces as remap targets The operation mode state publisher, the two operation mode change services and the legacy engage and gate mode publishers are node-side fixed names. Declaring them as remap targets puts them on the design graph; a port pinned with global: is skipped by link_manager and the exporter emits no remap for it. ---------

• fix(planning, control): point design param_files at the packages that install them (#13219) BehaviorPathPlanner listed its plugin modules' param files as relative paths, resolving against the host node package; each module package installs its own config. PlanningValidator referenced its checker plugins' param files under the host package with a planning_validator_ filename prefix the plugins do not use. TrajectoryFollower referenced config/ where the package installs param/, and controller files that exist per controller type (mpc, pid). ManualLaneChangeHandler declared a param file that does not exist; the node declares no parameters. The run_out module ships a config directory that ament_auto_package() did not install. Co-authored-by: Claude Fable 5 <<noreply@anthropic.com>>

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

• refactor(pid_logitudinal_controller): extract core logic (#13029)

  * refactor(autoware_pid_longitudinal_controller): extract PidLongitudinalControllerConfig logic Collect the scattered parameter member variables of PidLongitudinalController into a single PidLongitudinalControllerConfig struct, in preparation for extracting the core control logic from ROS 2 node concerns.

  * refactor(autoware_pid_longitudinal_controller): include PID/smooth-stop/lpf gains in config Move the remaining declare_parameter-based fields (PID gains and limits, smooth stop params, and the vel/acc/pitch lowpass filter gains) into PidLongitudinalControllerConfig so every ROS parameter feeding the control algorithm lives in one struct, ahead of extracting the core logic from rclcpp::Node.

  * refactor(autoware_pid_longitudinal_controller): extract core logic from PidLongitudinalController Split the ROS 2 node concerns out of PidLongitudinalController into a new PidLongitudinalControllerNode wrapper (declared in pid_longitudinal_controller_node.hpp, defined alongside the core logic in pid_longitudinal_controller.cpp to keep the diff close to the original file). The core class no longer depends on rclcpp::Node/rclcpp::Logger/publishers/ diagnostic_updater: it takes a PidLongitudinalControllerConfig, exposes run()/setConfig()/getDebugValues(), and returns the control state and error causes (control_state, received_invalid_trajectory, emergency_stop_reason) via PidLongitudinalControllerResult instead of a separate getControlState() getter or logging directly. The Node builds the config from parameters, owns the publishers/diagnostics/parameter callback, and turns the returned causes into actual RCLCPP_* log calls. autoware_trajectory_follower_node/src/controller_node.cpp now instantiates PidLongitudinalControllerNode instead of the (now core-only) PidLongitudinalController.

  * refactor(autoware_pid_longitudinal_controller): move Node functions into pid_longitudinal_controller_node.cpp; drop unused includes Move create_config() and all PidLongitudinalControllerNode method implementations (ctor, paramCallback, isReady, run, emitLogs, publishDebugData, publishVirtualWallMarker, setupDiagnosticUpdater, checkControlState) out of pid_longitudinal_controller.cpp into a new pid_longitudinal_controller_node.cpp, matching the extract-core-logic naming convention of <package>.cpp for core logic and <package>_node.cpp for the ROS 2 node wrapper. Also remove autoware_utils/ros/marker_helper.hpp and autoware_utils/geometry/ normalization.hpp includes that were unused (pre-existing dead includes, unrelated to the

File truncated at 100 lines see the full file