Recovery Is a Feature

Robots fail in the middle of missions.

A system that can only succeed from a perfect starting state is a demonstration, not a robust machine.

Recovery levels

A robot might respond to a fault by:

1. retrying the same action;
2. repositioning and retrying;
3. switching to a degraded mode;
4. asking for human assistance;
5. entering a safe stop.

The right response depends on consequence and confidence.

Bounded recovery

Retrying forever can be worse than failing once.

Example:

DOCKING
  ├─ success → CHARGING
  ├─ alignment failure + attempts < 2 → BACK_UP_AND_RETRY
  └─ attempts >= 2 → REQUEST_ASSISTANCE

The system retains autonomy without pretending every fault is recoverable.

Preserve evidence

When recovery starts, keep enough information to explain why.

Useful records can include:

• previous state;
• failure code;
• sensor snapshot;
• command;
• retry count;
• recovery selected;
• final outcome.

Without evidence, repeated failures become stories.

Recovery test

Design one fault injection for your autonomous mission from Unit 13.

Predict:

• which subsystem detects it;
• how fast it should be detected;
• which state transition should occur;
• what output must stop or change;
• what evidence must be saved.

Then simulate the state trace.

The best recovery design is not the one that keeps moving at all costs. It is the one whose behavior remains understandable when normal assumptions break.

Recovery begins by defining a safe intermediate state

A robot does not always need to jump directly from failure to normal operation.

Suppose localization becomes invalid during an autonomous mission.

A safer sequence could be:

RUNNING
   ↓ localization invalid
SAFE_STOP
   ↓ sensors stable / operator acknowledges
RELOCALIZE
   ↓ pose confidence restored
READY
   ↓ explicit resume
RUNNING

Each arrow needs a condition. Otherwise "recovery" becomes wishful thinking.

Restart is not recovery

Power cycling may clear a symptom. It can also erase logs, reset evidence, and return the robot to the same failure state.

A recovery design should answer:

• What state is preserved?
• What state must be rebuilt?
• Which outputs stay disabled?
• How is readiness verified?
• Who authorizes resume?
• What happens if recovery fails again?

Test the recovery path

If a robot claims it can recover from a lost sensor, deliberately simulate or use supplied evidence for that loss.

Record the state sequence and expected outputs.

The recovery path is part of the product. If it is never exercised, it is only documentation.