Crew, decisions and debrief
UAT 304 UAS Mission Planning and Autonomous Flight
Lesson
By the end of this module you will be able to
- Assign crew roles and use read-back communication
- Assess risk before and during the mission with PAVE and 3P, separating external pressures
- Merge events from several logs with unsynchronised clocks into one timeline
- Debrief by separating events from conclusions and tracking corrective actions
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.
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.
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
- Assign crew roles and rehearse call-outs and read-back
- Complete a PAVE worksheet before the mission with Example 1 and record the risk reductions
- The instructor injects pressure during the simulated mission; the team uses 3P to decide and records the reasons
- Merge the SITL log, GCS log and crew notes into one timeline with Example 2
- 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
- What does PAVE stand for?
- What are the steps of 3P?
- GPS time 10:00:18 corresponds to what UTC time?
- 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?
- Why should a review not focus on blame?
Answers
- Pilot, Aircraft, enVironment, External pressures
- Perceive, Process, Perform
- 10:00:00 UTC
- Plus 56 seconds
- 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
- Federal Aviation Administration. (2023). Pilot's handbook of aeronautical knowledge (FAA-H-8083-25C). link
- International Organization for Standardization. (2023). Unmanned aircraft systems — Part 3: Operational procedures (ISO 21384-3:2023). link
- ArduPilot Dev Team. Onboard message log messages. ArduPilot Copter documentation. link
- 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
Teamwork and situational awareness
Deciding when the plan goes wrong
Exercise: team briefing and decisions
Logs, handover and post-mission debrief
Diagnosing abnormal events before choosing a response
Field drone operations
In class / field
Lab or field practice from worksheets with a safety checklist
Learning evidence: Checked worksheets and quiz results