Mission Commands Are Conditional Logic

A waypoint mission is not a list of dots on a map.

It is a program that changes aircraft targets when certain conditions become true.

That means mission planning is partly a software problem: state, conditions, transitions, limits, and fallback behavior.

A waypoint is more than a coordinate

A fictional waypoint record might contain:

position: point B
altitude target: 35 m
arrival condition: within tolerance
next action: capture image
then: continue to point C

The mission engine has to decide when the aircraft has “arrived,” whether the required state is valid, what action comes next, and what to do if the expected condition never occurs.

The map shows geometry. The mission logic controls transitions.

Think like a state machine

A simple simulated inspection mission could have states such as:

READY
  ↓
TAKEOFF
  ↓
TRANSIT_TO_A
  ↓
CAPTURE_A
  ↓
TRANSIT_TO_B
  ↓
CAPTURE_B
  ↓
RETURN
  ↓
LAND

Transitions happen only when conditions are satisfied.

For example:

if altitude >= safe_transit_altitude:
    state = TRANSIT_TO_A

or:

if waypoint_A_reached and camera_ready:
    state = CAPTURE_A

The exact software differs by platform. The reasoning pattern is general.

Conditions can block progress

What if the aircraft never satisfies the waypoint-arrival tolerance?

A poor mission design may wait forever.

A stronger design considers:

• timeout;
• retry limit;
• alternate action;
• human intervention;
• abort or return state.

Every automated step should make you ask:

What happens if the condition is never satisfied?

That question is the beginning of failsafe design.

Mission logic depends on trusted state

Suppose the mission says:

if position inside capture zone:
    take image

That condition depends on a position estimate.

If the estimate is wrong, the software can execute the correct logic at the wrong physical location.

The mission program is not broken. The state entering the condition is wrong.

Week 6 measurement and Week 8 feedback are still inside the software layer.

Worked mission: roof-zone capture

A fictional inspection mission needs images from four roof zones.

A reasonable high-level flow is:

verify mission-ready state
→ enter zone A
→ verify position and camera state
→ capture
→ record metadata
→ enter zone B
→ repeat
→ return

Now add a failure condition:

if camera_not_ready:
    do not advance capture state

And an energy condition:

if remaining_energy_below_mission_threshold:
    stop collecting new zones
    transition to approved recovery behavior

The exact threshold would come from the approved mission system and its documentation. Do not invent a real-world battery limit from this classroom example.

The software lesson is the branching logic.

Priority matters when conditions conflict

Suppose the mission reaches Zone C at the same time a low-energy condition becomes true.

Which action wins?

• capture the image;
• continue the mission;
• return;
• land;
• request human decision?

The system needs a priority rule.

Safety-related state transitions generally need clear precedence over optional mission objectives, but the exact behavior must come from the approved platform, operating procedure, and mission design.

A mission without priority logic can produce contradictory commands.

Preconditions belong before actions

Consider this weak sequence:

take off
set home point
verify GNSS state

The order is backwards for a system that depends on those conditions before flight.

Mission logic should identify preconditions before entering a state that depends on them.

A classroom mission-readiness state could check:

• mission file loaded;
• required sensors valid in the simulator;
• home/reference point established according to the modeled system;
• geofence configuration loaded;
• payload ready;
• recovery behavior defined;
• operator approval state present.

Only then does the state machine permit progression.

Build a mission-state diagram

Create a state diagram for a fictional classroom mission with at least six states.

Requirements:

• one normal mission path;
• one precondition before mission start;
• one low-energy branch;
• one lost-link branch;
• one payload-not-ready branch;
• one completed mission state.

Label each arrow with the condition that allows the transition.

Do not write arrows labeled only “next.” “Next” hides the logic.

Misconception: automation removes decision-making

Automation moves some decisions into software before the mission runs.

Someone still has to decide:

• which conditions matter;
• what counts as success;
• which state has priority;
• what failure transitions exist;
• when human authority overrides automation.

If those decisions are vague in planning, the software does not magically make them precise.

The software model to keep

Mission software can be reasoned about as:

state → condition → transition → new state

Then ask one more question every time:

What happens when the condition is wrong, missing, delayed, or never becomes true?

That question carries us directly into geofences, home points, and lost-link behavior.