Design an Autonomous Mission

A good autonomous mission has more than a success path.

It defines what happens when expected events do not happen.

Mission: move a part between stations

Break the mission into states:

READY
  ↓ start
NAVIGATE_TO_PICKUP
  ↓ arrival
ACQUIRE
  ↓ confirmed
NAVIGATE_TO_DROPOFF
  ↓ arrival
RELEASE
  ↓ confirmed
COMPLETE

Now add reality.

What if:

• navigation times out?
• acquisition is not confirmed?
• an obstacle blocks the route?
• localization confidence drops?
• the stop input is activated?

The state graph needs recovery and safe-stop paths.

Recovery is not retry forever

A retry policy should be bounded.

Example:

ACQUIRE
  ├─ success → NAVIGATE_TO_DROPOFF
  ├─ failure + attempts < 2 → REPOSITION
  └─ failure + attempts >= 2 → SAFE_STOP

The robot remains autonomous because it can respond without waiting for a human command. It remains bounded because the recovery authority is limited.

Define mission evidence

A mission can be evaluated using:

• completion time;
• success/failure state;
• number of retries;
• path deviation;
• localization confidence;
• stop events;
• object confirmation.

A video alone is weak evidence. Logs and state traces explain what the robot believed and why it acted.

Build your mission graph

Design a mission with at least six states.

Include:

1. one normal path;
2. one timeout;
3. one invalid-sensor condition;
4. one bounded retry;
5. one human stop/override;
6. one final safe state.

Then produce a short test list covering each branch.

This becomes the autonomy section of your systems dossier.

Mission design starts with conditions, not a route sketch

Consider this mission:

Move three samples from Station A to Station B.

Before choosing a path, define:

• start condition;
• completion condition;
• allowed operating area;
• obstacle assumptions;
• localization requirement;
• object-detection requirement;
• stop conditions;
• recovery behavior.

Now the mission can become a state model:

START
  ↓
NAVIGATE_TO_SAMPLE
  ↓
ACQUIRE
  ↓
NAVIGATE_TO_DROP
  ↓
RELEASE
  ├── more samples → NAVIGATE_TO_SAMPLE
  └── complete → DONE

Every transition needs evidence. ACQUIRE → NAVIGATE_TO_DROP should not occur merely because a timer expired if the robot can verify whether the object was actually captured.

Add failure transitions

A mission diagram with only success arrows is not finished.

Add at least:

lost localization → STOP / RECOVER
object not acquired → RETRY or ABORT
obstacle blocks route → WAIT / REPLAN
critical sensor stale → SAFE STOP

Then choose one failure and state what evidence allows recovery.

Autonomy becomes trustworthy when failure behavior is designed as deliberately as the happy path.

A mission should also declare what does not count as success. Reaching the destination after crossing a forbidden boundary, losing the payload, or ignoring a required stop condition is not mission completion. This prevents one success metric from overpowering the rest of the system requirements.