6.3 Automated Flight Management Systems (RAFM)
Key Takeaways
- RAFM is a common Part 101 MOS unit: section 4 applies it to any RPA in any category "whether operated under a manual or an automated flight management system", so it cannot be skipped by pilots who hand-fly.
- Automation never transfers legal responsibility - the remote pilot in command still owns visual line of sight, the 400 ft AGL limit and every other standard operating condition on an automated mission.
- The most common AFMS trap is a return-to-home altitude set below an obstacle on the return path, or a home point captured before a stable GNSS fix.
- Loss of GNSS degrades the aircraft to attitude (ATTI) mode: position hold and return-to-home stop working and the RPA drifts downwind until the pilot flies it manually by visual reference.
- An IMU fault corrupts the attitude estimate itself, so the aircraft may pitch or roll away under its own control input - take manual control and land as soon as practicable rather than trusting a failsafe.
What an Automated Flight Management System Is
An automated flight management system (AFMS) is the combination of flight-controller firmware, navigation sensors and ground-station mission-planning software that lets an RPA fly a pre-programmed profile without continuous stick input. On a typical survey multirotor it is the autopilot plus the mission-planning app: you draw a route or a survey grid, set altitude, speed and camera triggers, upload the plan, and the aircraft flies the pattern itself.
RAFM is the Part 101 MOS knowledge unit covering this material, and it is a common unit. MOS section 4 applies it to any RPA in any category "whether operated under a manual or an automated flight management system", and Schedule 2 lists it in Appendix 1 alongside RBAK, RACP, RBMO, REES, RHPF, RKOP and RORA. You cannot skip it on the grounds that you hand-fly everything. Its single Schedule 4 topic carries priority A, so expect it to be examined directly.
It helps to think of RPA automation as a ladder of levels rather than an on/off switch:
| Level | What the pilot does | What the system does | Typical use |
|---|---|---|---|
| Manual / rate | Commands rotation rates continuously | Motor mixing only | Confined-space recovery, sport flying |
| Stabilised (ATTI) | Commands attitude, corrects drift manually | Holds level attitude and (usually) altitude | GNSS-denied or GNSS-degraded flying |
| Position hold | Commands position, monitors | Holds a three-dimensional position using GNSS | Hovering inspection, photography |
| Waypoint / mission | Plans, monitors, intervenes | Flies a programmed route and triggers the payload | Survey, mapping, linear inspection |
| Return to home (RTH) | Monitors, can override | Climbs to a set altitude and returns to the recorded home point | Link-loss and low-battery failsafe |
Automation does not change your legal position. You remain the remote pilot in command, the RPA must stay within visual line of sight unless you hold a separate approval, and every standard operating condition applies to an automated mission exactly as it does to a hand-flown one. "The drone was flying its programmed mission" is not a defence.
Precautions When Programming a Mission
Most AFMS occurrences are planning errors rather than hardware failures, so work through a fixed pre-programming discipline every time:
| Check | Why it matters |
|---|---|
| Home point recorded and confirmed | The aircraft may latch the home point at first GNSS fix. If that happens in a car park 300 m away, RTH flies there, not to you. |
| RTH altitude above the tallest obstacle on the return path | RTH normally climbs to a set height then tracks straight home. A 40 m RTH altitude with a 55 m transmission tower on the direct line is a collision. |
| AGL versus AMSL, and terrain along the route | A plan flown at constant altitude over rising ground closes on the terrain; over falling ground it can exceed 400 ft AGL even though the number never changed. |
| Every waypoint altitude against the 400 ft AGL limit | The height limit applies at each point of the route, not to the launch point. |
| Geofence, airspace and approval boundaries | Manufacturer geofence databases are advisory and can be stale. They are not a substitute for checking the VTC and NOTAMs. |
| Battery reserve for the whole route plus RTH | Budget the return leg and a reserve, into wind, not just the survey grid. |
| Failsafe action on link loss | Confirm whether the aircraft is set to hover, land or RTH, and that the choice suits the site. |
| Units and coordinate datum | Feet versus metres, and a mismatched datum, both put the aircraft somewhere you did not intend. |
| Payload triggers and gimbal angles | A mis-set trigger interval wastes the sortie and tempts a rushed, unplanned reflight. |
After uploading, verify the plan on the aircraft, not just in the app. Read the uploaded route back, confirm the waypoint count and altitudes, and walk the first leg visually before you commit. Brief your observer on what the aircraft is about to do so that a deviation is obvious to both of you, and keep your hand on the controls with the manual-override mode selected and rehearsed.
A survey mission is programmed with a return-to-home altitude of 40 m. The direct line from the far end of the grid back to the launch point crosses a 55 m communications tower. What is the consequence?
Limitations of Automation, and Spotting a Developing Fault
An AFMS is a precise executor of the plan you gave it and nothing more. Its limitations are the exam-relevant part:
- No see-and-avoid. The system has no awareness of other aircraft, and obstacle sensors are limited by range, field of view, lighting and surface type. Thin wires, glass and water are classic misses.
- GNSS dependency. Position hold, waypoint navigation and RTH all rest on a good satellite solution. Degrade the fix and those functions degrade with it.
- A static plan in a dynamic environment. The route does not know that the wind rose, that a crane arrived, or that a crowd gathered under leg three.
- Wind and performance are usually unmodelled. The aircraft will attempt the programmed groundspeed into a headwind by drawing more current, quietly eroding the reserve you calculated.
- Sensor drift and stale data. Compass and IMU calibrations age; airspace and geofence databases are only as current as the last update.
- No legal authority. Automation cannot grant an approval you do not hold.
Identifying faults with an AFMS
Catch problems on the ground where possible. Pre-arm and pre-flight indications are the first line: refused arming, compass-interference warnings, "IMU calibration required", a low satellite count or a poor dilution-of-precision figure, a home point that will not set, and firmware or database version mismatches between aircraft and controller.
In flight, the tell-tales are behavioural. Watch for the aircraft drifting in position hold with the sticks centred; toilet-bowling (a widening circular orbit around the intended hover point), which points to a compass or magnetic-interference problem; a telemetry position that does not match what you can see; unexpected yaw or heading changes; sluggish or overshooting responses to commands; and a mission that skips, stalls at, or overflies a waypoint. Any mismatch between what the ground station reports and what your eyes see should be treated as a system fault until proven otherwise — believe your eyes, and take manual control.
During a waypoint mission the ground station shows the RPA tracking the planned route, but the pilot can see the aircraft slowly orbiting in a widening circle around its intended position. What is the correct interpretation and immediate action?
Degraded Automation, Abnormal and Emergency Situations
The MOS calls out degraded automation explicitly, and two cases dominate.
Loss of GNSS (no GPS). With the satellite solution gone, the aircraft falls back to attitude (ATTI) mode: it holds a level attitude and roughly holds height, but it will not hold position. The visible symptom is the RPA drifting steadily downwind. Position hold, waypoint navigation and return to home are all unavailable, because each needs a position fix to work. The pilot must fly it manually by external visual reference — expect noticeably more stick work — and recover it to a clear landing area rather than chasing the programmed plan. Deep urban canyons, close-in structures, solar farms and strong radio-frequency interference are the usual causes.
IMU failure. This is more serious, because the inertial measurement unit supplies the attitude estimate the controller uses to stabilise the aircraft. A failed or badly drifting IMU means the aircraft is stabilising to a false horizon, so it may pitch or roll away under its own control input, oscillate, or climb or descend without command. Automation cannot correct a fault in its own reference. Select a manual or attitude mode, fly by what you can see, and land as soon as practicable at the nearest safe area.
Loss of control and loss of thrust. If the aircraft becomes unresponsive, do not spend the flight troubleshooting menus. Work the priorities in order: aviate — take manual control and keep it flying; navigate — steer it away from people, roads and property toward your pre-briefed emergency landing area; communicate — alert your observer and any ground crew, and clear the area. A partial loss of thrust on a multirotor shows as a yaw or roll the controller cannot trim out and a rapid rise in current draw; reduce demand, avoid aggressive inputs, and put it down early and deliberately rather than attempting to complete the task. If a controlled landing is no longer achievable and people are at risk, use flight termination to bring the aircraft down in the least hazardous place available.
The unifying rule for RAFM: automation is a workload aid, not a decision-maker. Every degraded-automation scenario resolves the same way — the remote pilot takes manual control, uses the external visual picture rather than the display, and lands.
An RPA on a programmed survey loses its GNSS fix mid-mission. What behaviour should the remote pilot expect, and what is the correct response?