Module 5/5 · Weeks 13–15 · 27 h

Crew, decisions and debrief

UAT 304 UAS Mission Planning and Autonomous Flight

About 85 minDraft, awaiting reviewLast updated 28 September 2026

Lesson

By the end of this module you will be able to

  1. Assign crew roles and use read-back communication
  2. Assess risk before and during the mission with PAVE and 3P, separating external pressures
  3. Merge events from several logs with unsynchronised clocks into one timeline
  4. Debrief by separating events from conclusions and tracking corrective actions

Prerequisites: UAT 304 Modules 1–4 · UAT 313 Module 4 (human factors)

Why this matters

Most missions that go wrong do not start with the machine but with a crew that does not share the same picture, or that accepts risk because of pressure. The drone knowledge base’s unit on teamwork and situational awareness stresses role assignment, read-back and workload management. Its unit on decisions when the plan does not go as expected uses PAVE to separate risk from pressure, and its unit on records and after-action review separates events from conclusions and tracks fixes until there is evidence to close them.

Roles and communication

The minimum mission crew has a pilot in command (final authority on safety), a payload or GCS operator and an observer (watching the aircraft and obstacles). Important commands and information use read-back: the receiver repeats what was heard and the sender confirms, for example “Battery 30 percent” — “Copy, 30 percent, returning to launch”. Before the mission, agree on emergency call-outs and on who is authorised to terminate the mission.

PAVE and 3P

Chapter 2 of the FAA’s PHAK (FAA-H-8083-25C), on aeronautical decision-making, presents PAVE as a four-part risk checklist: Pilot (for example fitness under IMSAFE), Aircraft, enVironment and External pressures. It also presents the 3P model: Perceive the circumstances, Process their impact on safety, and Perform the best action, repeated throughout the mission. External pressures, such as a waiting client or fear of losing face, are the most dangerous part, because they lead people to accept the risks in the other three.

Example 1 The team’s PAVE worksheet

The team scores each item 0–3 and sets limits in advance (the scoring method is the team’s, not the FAA’s).

pave = {
    "Pilot": {"slept < 6 h": 2, "first flight at this site": 1},
    "Aircraft": {"motor replaced yesterday, one test flight": 2},
    "enVironment": {"gusts near limit": 2, "people near take-off point": 1},
    "External pressures": {"mayor wants images by 10:00": 3, "media present": 1},
}
LIMIT_TOTAL, LIMIT_ITEM = 8, 3
total = sum(v for items in pave.values() for v in items.values())
for area, items in pave.items():
    print(f"{area:<19} {sum(items.values())}  {', '.join(items)}")
worst = [(a, k) for a, items in pave.items() for k, v in items.items() if v >= LIMIT_ITEM]
print(f"total {total} (limit {LIMIT_TOTAL}); items at maximum: {worst}")
if total > LIMIT_TOTAL or worst:
    print("do not start as planned: remove or reduce risks, or postpone")
Pilot               3  slept < 6 h, first flight at this site
Aircraft            2  motor replaced yesterday, one test flight
enVironment         3  gusts near limit, people near take-off point
External pressures  4  mayor wants images by 10:00, media present
total 12 (limit 8); items at maximum: [('External pressures', 'mayor wants images by 10:00')]
do not start as planned: remove or reduce risks, or postpone

The total exceeds the limit, and the worst item is external pressure. A good response is not “be more careful” but to remove the risks that can really be reduced: have a well-rested pilot fly instead, cordon off the take-off area, test-fly the aircraft whose motor was just replaced, and tell the client in advance that images may arrive later than requested.

Four boxes side by side: Pilot 3, Aircraft 2, enVironment 3 and External pressures 4, with the external pressures box in the strongest pink; below, a total of 12 above the limit of 8
Figure 1 The team's PAVE scores before the mission

Ordering events from several logs

A debrief needs a single timeline, but the flight controller log, the GCS and the crew’s notes use different clocks. ArduPilot logs record GPS time as a week number (GWk, counted from 5 January 1980) and milliseconds into the week (GMS). GPS time does not count leap seconds while UTC does; GPS time is currently 18 seconds ahead of UTC (derived from IERS Bulletin C, which states that UTC has differed from TAI by 37 seconds since 2017, and from the fixed 19-second difference between TAI and GPS time). Computer and phone clocks can be off by seconds or minutes as well.

Example 2 Merging three sources into one timeline

Use an event recorded by every source, “arm”, as the reference and shift each source’s times (simulated data).

from datetime import datetime, timedelta

GPS_EPOCH, LEAP, TZ = datetime(1980, 1, 6), 18, 7
fc_arm = (2440, 354718000)                     # GWk, GMS of the arm event in the flight controller log
arm_utc = GPS_EPOCH + timedelta(weeks=fc_arm[0], milliseconds=fc_arm[1]) - timedelta(seconds=LEAP)
arm_local = arm_utc + timedelta(hours=TZ)
print("arm (from FC log):", arm_local.strftime("%Y-%m-%d %H:%M:%S"), "local")

sources = {   # source: (arm time on that clock, [(time on that clock, event)])
    "GCS laptop": ("09:32:05", [("09:36:50", "video link freeze reported"), ("09:38:12", "RTL commanded")]),
    "pilot phone": ("09:31:02", [("09:35:40", "gust felt at take-off point"), ("09:37:00", "decision to abort")]),
}
timeline = [(arm_local, "FC", "arm")]
for name, (arm_txt, events) in sources.items():
    arm_src = datetime.combine(arm_local.date(), datetime.strptime(arm_txt, "%H:%M:%S").time())
    offset = arm_local - arm_src
    print(f"{name}: clock offset {offset.total_seconds():+.0f} s")
    for txt, ev in events:
        t = datetime.combine(arm_local.date(), datetime.strptime(txt, "%H:%M:%S").time()) + offset
        timeline.append((t, name, ev))
for t, src, ev in sorted(timeline):
    print(t.strftime("%H:%M:%S"), f"{src:<12}", ev)
arm (from FC log): 2026-10-15 09:31:40 local
GCS laptop: clock offset -25 s
pilot phone: clock offset +38 s
09:31:40 FC           arm
09:36:18 pilot phone  gust felt at take-off point
09:36:25 GCS laptop   video link freeze reported
09:37:38 pilot phone  decision to abort
09:37:47 GCS laptop   RTL commanded

Ordered by corrected times, the real sequence is gust, video freeze, abort decision, and RTL a few seconds later. The slow part was the decision after the video froze, which took over a minute. With raw times, it would look as if the team decided quickly but the GCS operator was slow to command RTL, which would draw the lesson about the wrong person.

A horizontal timeline after clock correction with five events from left to right: arm, gust, video freeze, abort decision and RTL command, each coloured by source: flight controller, GCS and pilot phone
Figure 2 One timeline from three sources after clock correction

After-action review

An effective review separates three parts: what happened (along an evidence-based timeline), why it happened (human, machine, environment and organisational factors) and what to fix (actions, owners, due dates and the evidence that will close them). Focus on the system rather than blaming people, so that the crew reports openly next time.

Module lab

Lab: a simulated mission with a debrief

  1. Assign crew roles and rehearse call-outs and read-back
  2. Complete a PAVE worksheet before the mission with Example 1 and record the risk reductions
  3. The instructor injects pressure during the simulated mission; the team uses 3P to decide and records the reasons
  4. Merge the SITL log, GCS log and crew notes into one timeline with Example 2
  5. Debrief and write corrective actions with owners and closing evidence

Common mistakes

Watch out

  • Not stating who may terminate the mission
  • Accepting commands without read-back
  • Overlooking external pressure because it is not technical
  • Ordering events by raw times from different clocks
  • Reviewing to find someone to blame instead of systemic causes

Summary

  • The crew needs clear roles, an authority to terminate and read-back communication
  • PAVE checks four areas: pilot, aircraft, environment and external pressures; 3P repeats throughout the mission
  • GPS time in ArduPilot logs converts to UTC by subtracting 18 seconds and serves as the reference for other clocks
  • The review separates events, causes and fixes with closing evidence

Check your understanding

  1. What does PAVE stand for?
  2. What are the steps of 3P?
  3. GPS time 10:00:18 corresponds to what UTC time?
  4. A phone logged arm at 09:31:02 but the true time was 09:31:58. How much must the phone’s times be shifted?
  5. Why should a review not focus on blame?
Answers
  1. Pilot, Aircraft, enVironment, External pressures
  2. Perceive, Process, Perform
  3. 10:00:00 UTC
  4. Plus 56 seconds
  5. People will stop reporting events, and systemic causes will not be fixed

Key formulas

GPS time from week and milliseconds
Conversion to UTC (since 2017)

Key references

  1. Federal Aviation Administration. (2023). Pilot's handbook of aeronautical knowledge (FAA-H-8083-25C). link
  2. International Organization for Standardization. (2023). Unmanned aircraft systems — Part 3: Operational procedures (ISO 21384-3:2023). link
  3. ArduPilot Dev Team. Onboard message log messages. ArduPilot Copter documentation. link
  4. International Earth Rotation and Reference Systems Service. (2026). Bulletin C 72. link

Further reading

Study the assigned knowledge units in advance, review media and take the module quiz

In class / field

Lab or field practice from worksheets with a safety checklist

Learning evidence: Checked worksheets and quiz results

Module quiz

This is a formative self-check, not a graded exam

Knowledge domain: Law, safety and risk · Mission planning, flight and simulation