Mission Planner

Purpose

Mission Planner calculates a route that navigates from the current ego pose to the goal pose following the given check points. The route is made of a sequence of lanes on a static map. Dynamic objects (e.g. pedestrians and other vehicles) and dynamic map information (e.g. road construction which blocks some lanes) are not considered during route planning. Therefore, the output topic is only published when the goal pose or check points are given and will be latched until the new goal pose or check points are given.

The core implementation does not depend on a map format. Any planning algorithms can be added as plugin modules. In current Autoware Universe, only the plugin for Lanelet2 map format is supported.

Interfaces

Parameters

Services

Subscriptions

Publications

Route section

Route section, whose type is autoware_planning_msgs/LaneletSegment, is a “slice” of a road that bundles lane changeable lanes. Note that the most atomic unit of route is autoware_planning_msgs/LaneletPrimitive, which has the unique id of a lane in a vector map and its type. Therefore, route message does not contain geometric information about the lane since we did not want to have planning module’s message to have dependency on map data structure.

The ROS message of route section contains following three elements for each route section.

• preferred_primitive: Preferred lane to follow towards the goal.
• primitives: All neighbor lanes in the same direction including the preferred lane.

Goal Validation

The mission planner has control mechanism to validate the given goal pose and create a route. If goal pose angle between goal pose lanelet and goal pose’ yaw is greater than goal_angle_threshold parameter, the goal is rejected. Another control mechanism is the creation of a footprint of the goal pose according to the dimensions of the vehicle and checking whether this footprint is within the lanelets. If goal footprint exceeds lanelets, then the goal is rejected.

At the image below, there are sample goal pose validation cases.

Implementation

Mission Planner

Two callbacks (goal and check points) are a trigger for route planning. Routing graph, which plans route in Lanelet2, must be created before those callbacks, and this routing graph is created in vector map callback.

plan route is explained in detail in the following section.

```plantuml @startuml title goal callback start

:clear previously memorized check points;

:memorize ego and goal pose as check points;

if (routing graph is ready?) then (yes) else (no) stop endif

:plan route;

File truncated at 100 lines see the full file

Changelog for package autoware_mission_planner

1.1.0 (2025-05-01)

1.10.0 (2026-09-28)

• Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base

• refactor(autoware_mission_planner): decouple core planning logic from ROS 2 node (#1400)

  • refactor(autoware_mission_planner): decouple core logic
  • refactor(autoware_mission_planner): move MissionPlannerNode into mission_planner_node.cpp
  • refactor(autoware_mission_planner): rename planner_warning_message to warning_message

  * fix(autoware_mission_planner): guard optional access in MissionPlannerNode Fix bugprone-unchecked-optional-access errors reported by clang-tidy CI. Dereferences of InitializationCheckResult::waiting_message, SetLaneletRouteResult::route/route_marker, and SetWaypointRouteResult::route/route_marker were guarded by checks on unrelated fields (became_ready, status.success), which clang-tidy's dataflow analysis cannot connect to the optionals being dereferenced. Guard on the optionals themselves instead.

  * refactor(autoware_mission_planner): simplify check_initialization to return bool Return a plain bool from MissionPlanner::check_initialization() instead of InitializationCheckResult, and move the waiting-state info log to the node side with a unified message.

  • fix(autoware_mission_planner): update composable node plugin name to MissionPlannerNode
  • refactor(autoware_mission_planner): decouple error logging from route validity check

  * refactor(autoware_mission_planner): pass tf2::BufferCore into MissionPlanner Move the map-frame transform lookup for set_lanelet_route and set_waypoint_route from MissionPlannerNode into MissionPlanner itself, following the tf2::BufferCore injection pattern used in autowarefoundation/autoware_universe#13270. tf2::BufferCore has no ROS runtime dependency, so this keeps mission_planner.cpp free of rclcpp::Node/Logger while removing the duplicated try/catch lookup that previously lived in both service handlers. ---------Co-authored-by: Takahisa.Ishikawa <<takahisa.ishikawa@tier4.jp>>

• fix(planning): declare the dependencies these packages use (#1372) Each of these packages uses a package it never declares. Either it includes a header of that package, or it names a symbol of it while the header arrives through another dependency. Both build today only because some declared dependency re-exports the owner, so a change in an unrelated repository can break them without anything here changing. The tag follows where the dependency is used: a use in an installed header or in code compiled into the library takes <depend>, one reached only from test/ takes <test_depend>. System libraries are named by the rosdep key this workspace already prefers. A clean-context review of the pull request found five more direct uses with no manifest entry. Add one entry for each:

  • autoware_path_generator: tf2 (tf2::getYaw in src/utils.cpp)
  • autoware_motion_velocity_planner_common: tf2 (tf2::getYaw in src/planner_data.cpp and src/polygon_utils.cpp)
  • autoware_motion_velocity_obstacle_stop_module: autoware_planning_factor_interface (constructed in src/obstacle_stop_module.cpp)
  • autoware_behavior_velocity_stop_line_module: autoware_planning_factor_interface (used in src/experimental/scene.cpp)
  • autoware_velocity_smoother: rclcpp_components (register_node_macro.hpp in src/node.cpp)

• refactor(autoware_mission_planner): create endpoints through NodeAdaptor (#1327)

• refactor(autoware_mission_planner): remove pluginlib and decouple DefaultPlanner from rclcpp::Node (#1334)

  * refactor(autoware_mission_planner): remove pluginlib and construct DefaultPlanner directly DefaultPlanner was the only implementation of PlannerPlugin and its class name was hardcoded, so pluginlib's dynamic class loading added runtime overhead without providing runtime plugin selection.

  * refactor(autoware_mission_planner): remove PlannerPlugin abstract base class DefaultPlanner is now constructed directly instead of via pluginlib, so the PlannerPlugin interface no longer serves runtime polymorphism and had no other implementation.

  * refactor(autoware_mission_planner): remove unused initialize overload The initialize(node, msg) overload had no callers; fold initialize_common back into the single initialize(node).

File truncated at 100 lines see the full file