Mission planning

Mission planning – definition

Mission planning in mobile robotics is the process of defining what a UGV should do, where it should go, in what order, and under what constraints. It sits above local motion control and typically above global path planning. In practice, it converts an operational objective into machine-executable tasks such as waypoint traversal, area coverage, inspection sequence, return-to-home, or conditional branching based on sensor events.

For a ground robot, mission planning is not only route selection. It also includes task sequencing, timing, safety rules, geofencing, map selection, payload actions, and recovery behavior. In ROS 2 systems, mission planning is commonly implemented as a composition of navigation goals, behavior trees, state machines, action servers, and mission-specific logic. The exact architecture depends on whether the robot operates in a known map, a GPS frame, or a partially unknown environment.

On UGV platforms such as Leo Rover and Raptor Rover, mission planning usually relies on lower layers that already provide localization, obstacle sensing, and motion control. Leo Rover supports ROS 2, typically on Raspberry Pi-class onboard compute, so mission logic must be efficient and aware of compute limits. Raptor Rover, with higher payload capacity, is better suited to larger sensor sets and more demanding autonomy stacks, but it still requires an integrated navigation pipeline rather than out-of-the-box autonomous driving.

Where mission planning fits in the autonomy stack

In a UGV software stack, mission planning is one of several decision layers. It should be separated from pure control loops and from perception modules. This separation improves testability and makes ROS 2 integration cleaner.

A simplified hierarchy for a ROS 2 ground robot looks like this:

Perception layer – LiDAR, camera, IMU, wheel odometry, GPS/RTK, obstacle detection, semantic triggers.
Localization and mapping – AMCL, SLAM Toolbox, robot_localization, map server, frame transforms.
Navigation layer – Nav2 global planner, local controller, costmaps, recovery behaviors.
Mission layer – waypoint order, task logic, event handling, timeout policies, geofences, mission completion criteria.
Supervisory and safety layer – E-stop, watchdogs, operator override, fault states.

In ROS terms, mission planning often orchestrates action interfaces rather than directly publishing velocity commands. For differential-drive UGVs such as Leo Rover, the mission layer usually sends navigation goals and monitors success, failure, or preemption. Velocity-level control remains in the navigation or controller layer.

How mission planning works in ROS 2

ROS 2 does not define a single mission planning standard. Instead, it provides reusable mechanisms. The most common are actions, lifecycle nodes, parameters, TF2 frames, and behavior-tree-based task execution. In mobile robotics, the most widely used navigation framework is Nav2, which uses behavior trees to coordinate planning, control, recovery, and goal handling.

Typical mission planning in ROS 2 uses these building blocks:

Actions – long-running tasks with feedback, such as navigation to pose or following waypoints.
Topics – status reporting, events, sensor triggers, mission state broadcast.
Services – map switching, parameter updates, reset commands.
Lifecycle nodes – managed startup and shutdown for navigation components.
Behavior trees or finite state machines – high-level task logic.

For waypoint missions in Nav2, the relevant action is commonly based on pose goals expressed in a global frame such as map. Frame naming should follow ROS conventions defined in REP 105 for coordinate frames and REP 103 for units and conventions.

ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose \
"{pose: {header: {frame_id: map}, pose: {position: {x: 4.0, y: 1.5, z: 0.0}, orientation: {w: 1.0}}}}"

For multi-step missions, a planner node can queue goals, wait for completion, and branch on feedback. On resource-constrained systems, this is often simpler than deploying a large orchestration framework.

Key interfaces, frames, and parameters

Mission planning depends on clean system interfaces. In ROS 2 mobile robotics, incorrect frame alignment or timestamping is a frequent cause of mission failure. The mission layer is therefore only as reliable as the localization and navigation stack below it.

Element	Typical value	Why it matters
Global frame	`map` or `utm`	Mission goals must be expressed in a stable world reference.
Robot base frame	`base_link`	Used for goal tracking and controller outputs.
Localization update rate	10-50 Hz	Low rates reduce responsiveness and increase navigation error.
Costmap update rate	5-20 Hz	Affects obstacle reaction and mission robustness.
Waypoint tolerance	0.05-0.5 m	Determines when a task is considered complete.
Mission timeout	Task-dependent	Required for failure handling and supervisory logic.

When GPS or RTK is part of the system, mission planning may use geodetic waypoints. In that case, conversion to local Cartesian coordinates or direct use of a map projection is required. The robot_localization package is commonly used to fuse GNSS, IMU, and odometry into a consistent state estimate.

Mission planning patterns for UGVs

Different field tasks require different mission structures. A waypoint list is enough for many lab and inspection scenarios. Coverage or event-driven missions need more logic.

Sequential waypoint mission – visit points A, B, C in order.
Coverage mission – sweep a polygon or lanes with overlap constraints, common in agriculture and mapping.
Inspection mission – stop at checkpoints, trigger a camera or sensor payload, save metadata.
Conditional mission – branch when obstacle density, battery level, or payload output exceeds a threshold.
Return-to-home mission – abort current task and navigate to a safe known pose.

A useful abstraction is:

mission:
  frame_id: map
  waypoints:
    - id: wp1
      x: 1.2
      y: 0.5
      yaw: 0.0
      action: capture_image
    - id: wp2
      x: 3.8
      y: -1.1
      yaw: 1.57
      action: lidar_scan
  completion_tolerance_m: 0.20
  timeout_s: 120
  return_home_on_failure: true

Use on Leo Rover and Raptor Rover

On Leo Rover, mission planning is usually tied to compact research or educational deployments. The robot uses differential drive and ROS 2 support, so a common setup is Nav2 plus SLAM or localization, with mission logic implemented as a Python node, a behavior tree extension, or a small supervisory state machine. Because onboard compute is typically Raspberry Pi-based, heavy perception and mission analytics may need optimization or offloading.

Typical Leo Rover mission examples include:

indoor waypoint navigation using LiDAR and SLAM Toolbox,
greenhouse or corridor inspection with stop-and-scan logic,
education-focused experiments with geofencing and recovery behavior.

On Raptor Rover, mission planning is more often associated with larger payloads, wider outdoor coverage, and sensor fusion involving GNSS/RTK, LiDAR, and multiple cameras. The mission layer may include area coverage, terrain-dependent speed limits, and payload-specific task execution. Its larger scale does not remove the need for a proper autonomy stack. It only expands the feasible sensor and compute envelope.

Limitations and trade-offs

Mission planning does not guarantee autonomy by itself. If localization drifts, if costmaps are stale, or if the controller cannot track paths on loose terrain, the mission layer will still fail. This is important on outdoor UGVs where wheel slip, uneven ground, and GNSS outages are common.

Main engineering trade-offs include:

Simple waypoint logic vs. robust task orchestration – simpler systems are easier to debug but less flexible.
Reactive behavior vs. deterministic execution – more event handling improves resilience but complicates verification.
Onboard compute vs. remote supervision – onboard autonomy reduces network dependence but is constrained by hardware.
Map-based missions vs. GPS-based missions – map-based navigation is better indoors, GPS-based missions scale better outdoors but depend on positioning quality.

Normative references and standards

The term itself is broader than ROS, but its implementation in ROS 2 should follow official conventions. The most relevant references are:

REP 103 – Standard Units of Measure and Coordinate Conventions.
REP 105 – Coordinate Frames for Mobile Platforms.
ROS 2 documentation – nodes, topics, services, actions, lifecycle management.
Nav2 documentation – behavior trees, navigation actions, waypoint execution.
robot_localization documentation – state estimation and GNSS fusion.

For technical correctness, mission goals should always specify frame, timestamp policy, tolerances, and failure behavior. Without those elements, the term “mission planning” remains too vague for a deployable UGV system.