M7-T1: UAV onboard computing architecture

Learning objectives

After this lesson, you should be able to:

• Partition UAV functions between the flight controller, companion computer and ground station using explicit criteria.
• Explain the role of failure containment and a narrow interface between safety-critical and best-effort software.
• Estimate whether a function’s latency and compute needs fit the chosen processor.
• Document the partition so that it can be reviewed and changed.

Conceptual explanation

Established This is standard embedded-systems and safety-architecture practice. The example numbers in the table are order-of-magnitude illustrations of typical systems, not specifications of any product.

Three processor classes appear on most research and commercial UAVs:

Partition by three criteria:

• Latency and determinism: loops with deadlines of a few milliseconds and tight jitter (rate control, attitude control, state estimation with the IMU) belong on the real-time microcontroller.
• Compute and memory: perception, mapping, VIO front ends, learning-based methods and global planning need more than a microcontroller can supply and belong on the companion.
• Failure containment: anything whose failure must not endanger the vehicle sits behind an interface the flight controller can supervise: a companion crash must degrade to a defined safe state, not take the stabilisation down.

Engineering intuition

Think of two organisations: an operations room that must never stop (the flight controller) and a research team that can be brilliant and occasionally wrong (the companion). The operations room accepts requests from the research team through a formal channel, checks them, and keeps working if the team goes quiet. Putting a critical function in the research team, or giving the research team unfiltered control, puts the flight at the mercy of a general-purpose operating system.

The placement is not permanent: a function can move as it matures. Visual-inertial odometry typically starts on the companion; if it must run when the companion is unavailable, it has to be moved, simplified or duplicated. Move the function, and the failure analysis moves with it.

Mathematical formulation

A simple feasibility test for placing a function on a processor: the worst-case execution time $C$ and the period $T$ must satisfy the utilisation bound with margin, and the end-to-end latency must fit the budget:

For a set of periodic tasks under rate-monotonic fixed-priority scheduling a sufficient utilisation bound for $n$ tasks is $n(2^{1/n}-1)$, which tends to $\ln \,2\approx 0.693$ for large $n$ and is 0.828 for $n=2$ and 0.780 for $n=3$. Above that bound schedulability must be shown by response-time analysis. Failure containment can be quantified by the probability that a companion fault affects the vehicle: with rate $\lambda _{c}$ of companion faults and detection coverage $c$ of the supervisor, the rate of uncontained events is $\lambda _{c}(1-c)$, which is why coverage of the heartbeat and output checks matters as much as the companion’s own reliability.

$C_{i}$, $T_{i}$

worst-case execution time and period of task $i$.

$U$

processor utilisation.

$c$

coverage: fraction of companion faults detected and contained by the supervisor.

Architecture and data flow

Sensors → flight controller (IMU, barometer, GNSS, magnetometer) → estimator and controllers → actuators. Camera, lidar and depth sensors → companion (CPU and GPU) → perception, VIO, mapping, planning → narrow command interface (offboard setpoints or external odometry) → flight controller supervision (stream monitoring, plausibility limits) → controllers. State and status flow back from the flight controller to the companion. Telemetry and video go to the ground.

Real-world UAV applications

• Choosing where VIO or lidar odometry runs for a GNSS-denied vehicle.
• Deciding whether obstacle avoidance’s last-resort layer runs on the flight controller or the companion.
• Sizing the companion computer from the perception pipeline.
• Writing the system architecture section of a design review.

Implementation example

This runs as shown. A placement checker: each function has a period, worst-case execution time, a latency deadline and a criticality; the checker computes the utilisation per processor with the rate-monotonic bound and flags violations such as a safety-critical function placed on the companion.

import numpy as np
funcs = [  # name, period s, WCET s (measured on that processor), deadline s, safety-critical?, processor
    ('rate control', 0.004, 0.0004, 0.004, True, 'fc'), ('attitude control', 0.004, 0.0003, 0.004, True, 'fc'),
    ('ekf2', 0.010, 0.0012, 0.010, True, 'fc'), ('failsafe monitor', 0.020, 0.0002, 0.020, True, 'fc'),
    ('vio frontend', 0.033, 0.018, 0.100, False, 'companion'), ('planner', 0.100, 0.030, 0.200, False, 'companion'),
    ('depth fusion', 0.067, 0.020, 0.150, False, 'companion'), ('obstacle last resort', 0.020, 0.002, 0.060, True, 'companion')]
def rm_bound(n): return n * (2 ** (1.0 / n) - 1)
problems = []
for proc in ('fc', 'companion'):
    fs = [f for f in funcs if f[5] == proc]; U = sum(f[2] / f[1] for f in fs)
    print(f"{proc}: {len(fs)} tasks, utilisation {U:.2f}, RM bound {rm_bound(len(fs)):.2f}")
    if U > rm_bound(len(fs)): problems.append(f"{proc}: utilisation above the sufficient bound (needs response-time analysis)")
for f in funcs:
    if f[2] > f[3]: problems.append(f"{f[0]}: WCET exceeds deadline")
    if f[4] and f[5] == 'companion': problems.append(f"{f[0]}: safety-critical function placed on the companion (needs a supervised interface or relocation)")
for p in problems: print("PROBLEM:", p)
assert abs(rm_bound(2) - 0.8284) < 1e-3 and abs(rm_bound(3) - 0.7798) < 1e-3
assert any('obstacle last resort' in p for p in problems)

Common engineering mistakes

Failure modes

Debugging approach

1. Measure execution time distributions per function on the target under realistic load.
2. Trace the data path timestamps end to end.
3. Disable the companion in a bench test and check the flight controller’s response.
4. Review each function’s placement against the three criteria.

Practical exercises

1. Place twelve functions of your own vehicle on processors and justify each by the three criteria.
2. Compute the rate-monotonic bound for 5 tasks and compare it to the measured utilisation.
3. Define the interface between the companion and the flight controller: messages, rates, limits, timeouts.
4. Estimate the fault rate that escapes containment with coverage 0.9 and 0.99 for a companion fault rate of $10^{-3}$ per hour.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• Liu, C. L. & Layland, J. W. (1973). Scheduling algorithms for multiprogramming in a hard-real-time environment. J. ACM 20(1)
• PX4: Companion computers
• PX4: Architectural overview

What’s next