Drones and Aerial Autonomy: When the Compute Has to Fly With You

Aerial robotics is the cleanest illustration in this cluster of the rate problem, because the platform is unstable, the compute budget is set by physics rather than by procurement, and a late decision does not degrade gracefully.

A quadrotor falls over if you stop paying attention

A multirotor produces thrust along one body axis and controls its position by tilting. It has no passive stability in attitude: perturb it and the perturbation grows. Left uncontrolled it diverges on a timescale of a fraction of a second, which is why the attitude controller runs on a dedicated microcontroller at something like 500 Hz to 1 kHz, reading a gyroscope directly and writing motor commands directly, with no operating system scheduler and no network anywhere in the path.

Fixed-wing aircraft are the opposite case and worth contrasting: a conventionally-configured aeroplane is designed to be passively stable and will hold an attitude on its own, which is why fixed-wing autopilots can run slower and tolerate more delay. The design consequence is that “drone autonomy” is not one problem — the timing budgets differ by an order of magnitude between airframes.

The rate cascade

The standard architecture is a cascade, each layer slower and more abstract than the one below.

Why carrying compute costs more than it weighs

On a ground robot, a heavier computer costs a little battery. On a multirotor it costs superlinearly, and the reason is worth deriving.

From momentum theory, the induced power required to hover scales with thrust to the three-halves power over the square root of disc area and air density — P ∝ (mg)^1.5 / sqrt(2ρA). Since hover thrust equals weight, hover power grows as mass to the 1.5 power. Add mass and you pay for it twice: once for the mass itself, and again because the structure and battery must grow to carry it.

hover power  P ~ m^1.5   (fixed rotor geometry, fixed air density)

add 10% to all-up mass:
  power ratio = 1.10^1.5 = 1.15    -> 15% more power drawn
  endurance   = 1 / 1.15 = 0.87    -> 13% less flight time

and a compute module drawing 30 W continuously on a
250 Wh pack is 12% of the entire energy budget before
it has lifted its own mass.

So the onboard compute question is not “what accelerator is available” but “what fits inside a watt and gram budget that is being charged twice”. This is the sharpest version of a constraint that applies to every mobile robot with a battery, and it is why aerial platforms adopted quantisation and small specialised models long before it was fashionable.

The case against putting the loop in the cloud

The tempting alternative is to fly a radio instead of a computer and run perception remotely. The arithmetic says where that ends.

forward speed          10 m/s
round-trip budget      capture + encode + uplink + inference
                       + downlink + decode + act
optimistic total       200 ms  ->  2.0 m of committed motion
realistic on cellular  400 ms  ->  4.0 m

braking distance at 10 m/s with 5 m/s^2 decel:
  v^2 / (2a) = 100 / 10 = 10 m, plus the committed 2-4 m

detect an obstacle at 12 m and you are already inside
the stopping distance.

And that is the well-behaved case. Link loss is not an exception on a moving aerial platform; it is a scheduled event that happens behind buildings and at range. Any architecture where a dropped packet produces undefined behaviour is not a design, so the layers that must not fail are the ones that fly with the vehicle, and everything remote must degrade to a defined state — hold, return to launch, land — that the onboard stack can execute alone.

What fits, and what it looks like

• Estimation before recognition. Visual-inertial odometry is cheap, runs at high rate, and is what actually keeps the vehicle where it thinks it is. Semantic perception is comparatively expensive and comparatively optional.
• Distil the policy, and give it an abstraction. The 2021 Learning high-speed flight in the wild result from Loquercio and colleagues is the well-known demonstration of what fits on a flying platform: a policy trained entirely in simulation, taking an abstracted representation of the depth image rather than raw pixels, and producing trajectories directly — small enough to run onboard and robust enough to transfer without real-world training data. The abstraction is the load-bearing choice; it is what makes the sim-to-real gap narrow enough to cross.
• Quantise and prune aggressively. A model that fits in on-chip memory avoids a large fraction of the energy cost, since moving data off-chip dominates the power of small inference workloads. See what quantisation actually costs in quality.
• Event cameras where the dynamics are fast. Sensors that report per-pixel brightness changes rather than frames have microsecond-scale latency and no motion blur, which is exactly the failure mode of a rolling-shutter camera on a fast-moving airframe. The trade is an unusual data format that most vision models were not built for.
• Put the semantics offboard, deliberately. Mission planning, map building, inspection analysis and fleet coordination all tolerate seconds. That layer is where a large model belongs, and it is also the layer where a link failure means a delayed decision rather than a crash.