The flight controller keeps the aircraft upright; the companion computer makes it worth flying. Every capability your customers actually pay for — detection, tracking, mapping, smart inspection, live video with overlays — runs on this second brain. Here's how to size it, wire it and keep it from cooking itself.
The division of labour
The architecture rule that keeps aircraft safe: the flight controller must remain able to fly and land the aircraft if the companion computer dies mid-mission. The FC (see FC selection) owns rate loops, estimation and failsafes on a real-time MCU. The companion owns perception, planning and connectivity on Linux — powerful, and precisely as deterministic as a Linux box under load, which is why nothing safety-critical lives there.
Hardware classes
| Class | Examples | Compute | Power | Fits when |
|---|---|---|---|---|
| SBC (ARM) | Raspberry Pi 5/CM5, Orange Pi | CPU only (+ light NPU) | 3–8 W | Mission logic, geotagging, streaming, cloud link |
| Edge-AI module | Jetson Orin Nano / NX class | GPU/NPU, 20–100+ TOPS | 7–25 W | Onboard inference: detection, tracking, depth |
| x86 module | Intel N-series / Core mini-PCs | Strong CPU, weak GPU | 10–35 W | Legacy x86 software stacks, heavy single-thread |
| FPGA/ASIC add-ons | Hailo, Coral accelerators | Efficient fixed-point inference | 2–5 W | Boosting an SBC to inference duty at low watts |
Choose by the heaviest workload with numbers: model, resolution, frame rate, latency target — the full workflow around this is in our AI drone integration guide. "Run YOLO-class detection at 1080p 30 fps under 50 ms" is a spec you can shop with — and the vendor benchmark you should reproduce before committing the airframe design.
Power and heat: the taxes nobody budgets
Every companion watt is battery mass or minutes (do the arithmetic with the endurance guide) — 20 W of compute on a small quad can be two minutes of flight. And those watts leave as heat from a module that throttles at ~85–95 °C junction, mounted inside an enclosure in direct sun with no fan-friendly dust environment. Working practices:
- Duct real airflow — prop wash is free cooling if the mechanical design uses it; a sealed box is a slow cooker.
- Structure as heatsink: thermally strap the module to an aluminium plate doing double duty.
- Test the thermal corner: full inference load, zero airspeed (hover), maximum sun, then check for throttling — throttled perception at the moment of obstacle detection is a systems failure, not a component one.
- Power it cleanly: a dedicated regulated rail with brown-out protection; companion reboots from voltage sag during aggressive manoeuvres are a classic "ghost bug".
Wiring and software patterns that age well
- Link: Ethernet FC↔companion where hardware allows (bandwidth, electrical robustness); UART/MAVLink remains fine for command-and-telemetry-only roles.
- Software interface: MAVSDK or ROS 2 (uXRCE-DDS on PX4; MAVLink/DDS on ArduPilot). Resist inventing a bespoke protocol — the ecosystem tooling you inherit is worth more than the elegance you imagine.
- Deployment: containerise the autonomy stack, version it like firmware, and make the update path field-safe (A/B partitions or rollback). A fleet of aircraft with hand-configured companions is technical debt with propellers.
- Watchdogs both ways: companion monitors its processes; FC monitors companion heartbeat and downgrades the mission gracefully on loss — a behaviour that belongs in your failsafe matrix and gets exercised in flight test.
Perception compute is sized by its input. A global-shutter camera on a stable mount with decent optics reduces the model quality you need; a rolling-shutter camera on a vibrating mount manufactures artefacts no network fully unlearns. Spend on the sensor before the TOPS — and mind USB3's notorious RF interference with GNSS receivers when you route it.
Build vs buy, once more
Integrated FC+companion combos and vendor "autonomy kits" compress your first year usefully. The trade is lock-in exactly where your product differentiation lives. A defensible pattern for startups: standard FC + standard compute module + your own carrier board when volumes justify it — the carrier is a modest engineering project that buys you connectors you chose, power sequencing you trust, and a bill of materials you control. It's also a well-bounded first project to hand an external electronics partner if the skill isn't in-house yet.
Frequently asked questions
What does a companion computer do on a drone?
It runs everything too heavy for the flight controller: computer vision, AI inference, mapping, mission logic, video encoding and cloud connectivity. The flight controller keeps flying the aircraft; the companion computer decides what the aircraft should do.
Jetson or Raspberry Pi for a drone?
Raspberry Pi (or similar SBC) suffices for mission logic, geotagging and video streaming. The moment you run neural networks onboard — detection, tracking, obstacle perception — you want a Jetson-class module with a real GPU/NPU. Budget 10–25 W and the thermal design to match.
How does a companion computer talk to the flight controller?
Traditionally MAVLink over a UART; increasingly Ethernet. On PX4, ROS 2 via uXRCE-DDS is first-class; on ArduPilot, MAVLink libraries (pymavlink, MAVSDK) and the DDS bridge cover most needs. Keep the safety-critical loop inside the flight controller regardless.