Use cases · Autonomy · Drone mission execution
The mission without
a model.
The operator types the mission in plain English. Senua AI writes the flight plan, then flies it — commanding a real autopilot in real time, on the drone’s own CPU class, with no language model, no GPU, and no cloud. The same engine that watches the telemetry also commands the aircraft.
The scenario
Two missions, spoken — not scripted.
There is no waypoint editor and no script. The operator describes the mission, and Senua AI drafts it: the same causal-state engine, run in reverse, turns the sentence into a leg sequence through its uniformity gate. No keyword parser, no template, no per-phrase lookup table — the language step is real.
Mission 1 · simple
“take off to twenty metres and return”
Senua drafts guided arm takeoff 20 return — GUIDED mode, arm, climb to 20 m,
return-to-launch, disarm.
Mission 2 · complex
“climb to thirty metres, fly one hundred metres north, then fifty metres east, and come back”
Senua drafts guided arm takeoff 30 goto 100 north goto 50 east return — the altitude and
both repositioning legs come back correct from one sentence: an L-shaped survey path, flown
through the same command path while the engine shadow-monitors the telemetry it is flying.
The flight simulator · what you are seeing
The moving map is not our software.
The physics and the flight code come from ArduPilot SITL — the same autopilot firmware that runs on a real Pixhawk, compiled to fly its control code against a simulated airframe. The display is QGroundControl, the standard open-source ground control station, connected over TCP to the vehicle.
One simulation exposes two MAVLink endpoints: Senua AI commands one; QGroundControl passively observes the other. Both show the identical aircraft at the same instant, with no skew. So when the map shows the drone arm, climb, fly the legs, and return, that is the real autopilot executing Senua’s commands — the ground station is only drawing the frames the autopilot emitted. The viewer cannot be accused of drawing what we wish were true.
What actually ran
The whole system — on the drone’s CPU class, measured, not estimated up.
The compute
One AWS Graviton2 arm64 instance (t4g.large — 2 vCPU Neoverse-N1, ~8 GB RAM). That is the drone’s processor class, a Raspberry-Pi-grade CPU — not a datacentre GPU.
The binaries
The Senua engine is ~5.5 MB of native arm64 machine code from a from-scratch compiler. No model weights, no GPU code, no Python/ROS/MAVSDK. On the airframe only the engine runs — plus a thin ~340 KB gateway if you want a console on the aircraft; the web UI and CLI are ground-side clients, never on the drone. Everything the aircraft carries is encrypted at rest.
The learned state
The Anima on disk is ~28 MB total. The mission language is a ~1.1 MB text corpus the engine induces into causal states at boot — there is nothing else to load, and no network to reach.
How Senua AI handles it, end to end
One engine: it reads the sentence, commands the aircraft, and defers to the flight controller for safety — every decision paced by a confidence value, not an if-statement.
1 · Draft from language
The mission specialist — the generic causal-state engine run in the generate direction — turns the spoken mission into a leg sequence. It abstains when it isn’t sure, rather than inventing a waypoint.
2 · Command the autopilot
Senua speaks MAVLink v2 natively — a from-scratch wire codec, CRC-validated against the autopilot’s own frames. It holds a link-confidence value with its derivative instead of timeout counts, and paces retries by it.
3 · The FC keeps authority
Flight-critical control never leaves the certified flight controller. If the companion vanishes, ArduPilot’s own failsafes bring the aircraft home. This is the companion pattern regulators already accept.
From simulator to bare metal
The same binary deploys onto the drone, via SenuaOS.
The arm64 binary that flew the SITL missions is the same binary that runs on the aircraft. Nothing is recompiled for the drone — the CPU class is identical. The integration is one serial cable.
The hardware
A COTS quad (Holybro X500 V2 class) with a stock Pixhawk 6C flight controller keeping safety authority; a Raspberry Pi 5 / CM5-class companion running Senua; an M10 GPS, a SiK 915 MHz telemetry radio, and a 5V/5A UBEC off the flight battery. Companion draw is a few watts — it fits the aircraft’s power budget, which is the whole reason a from-scratch engine exists instead of a GPU-hosted model.
The wiring
The Pi talks to the Pixhawk over a single UART wire — TELEM2 to the Pi’s UART at 921600 baud,
SERIAL2_PROTOCOL=2 — the first-class ArduPilot companion path.
That is the entire integration.
What the companion needs: almost nothing
Mainline arm64 Linux, the built-in UART, and the Senua daemon. No GPU stack, no CUDA, no Python, no ROS, no MAVSDK — the engine is syscall-native.
SenuaOS
A minimal appliance OS: a read-only root with an A/B partition scheme and a journaled data partition, an init that launches the daemon under a watchdog, and the Nexus peer plane. The drone boots straight into the engine — no desktop, no package manager, nothing to patch at the edge.
If the aircraft is captured
Everything the drone persists — the engine binary, the learned Anima, mission logs, and keys — lives on an encrypted data partition. The decryption key is held in the companion’s secure element / TPM and released only on the intact airframe at boot, so lifting the storage out of a downed aircraft yields ciphertext, not the mission history, the map, or the intelligence. There is nothing else to take: no cloud credential (the aircraft never depends on a server) and no model weights to extract (the intelligence is the causal-state machine, encrypted at rest). Tamper detection on the secure element wipes the key on intrusion. This is a SenuaOS design property, built on the platform’s own crypto — not a bolt-on.
The fleet · Nexus over RF
Shared intelligence that lives on the aircraft and travels over the radio.
A single drone is a companion; a swarm is a mesh. Nexus is Senua’s peer-to-peer sync layer, and it now runs directly over radio — no access point, no cell, no cloud in the loop.
The carrier
A datagram protocol built for half-duplex, lossy, contested radio, riding a SiK-class 915 MHz modem the aircraft already carries. Validated in emulation: windowed transfer ~9× faster than stop-and-wait, zero corrupt deliveries at 1–5% bit-error, resumable after a partition.
What travels
Learned knowledge, not raw video or a model. When one aircraft forms or updates a causal state — a new “normal”, a detected departure — that compact delta anti-entropy-syncs to every peer in range, and onward, hop by hop, across the mesh. Each node re-derives its own understanding locally.
Back to any node
A ground console, an operator laptop, or another aircraft is just another Nexus peer — a detection on aircraft 3 reaches the whole fleet and the subscribed ground console without any aircraft phoning a server. Drop the link and the sync re-arms; nothing is lost, nothing double-applied.
This is the layer an onboard language model cannot occupy — because it has no state to share, and no way to share it. F5 hardware-radio integration is the remaining build step; the protocol is built and validated today.
What the skeptic can check
Every claim is falsifiable.
The autopilot is not ours.
It is stock ArduPilot, unmodified. The wire protocol is MAVLink v2 with per-message CRC — a frame that parses is a frame the real stack emitted; a command that ACKs is a command the real stack accepted.
The display is independent.
The mission is observable in QGroundControl, an independent open-source GCS, in real time. It reads the same wire.
The engine carries no model.
The companion binary contains no model weights, no GPU code, and no network dependency beyond the flight-controller link. It is native machine code from a from-scratch compiler.
What we do not claim.
This is commanded mission execution in software-in-the-loop, plus live shadow monitoring (validated in the open on the public ALFA fault-flight dataset). It is not learned mission planning, not detection-triggered autonomous intervention, and not physical-flight hours — those are higher rungs on the autonomy ladder, gated on their own validation.
Autonomy that fits the aircraft.
The intelligence lives on the drone, speaks the autopilot’s language, and shares what it learns across the fleet over the radios they already fly — private, offline, no GPU.