KESTREL: Autonomous Flight Intelligence for Cluttered, Contested, Coordinated Airspace

1The autonomy problem

Flying an uncrewed aircraft in open sky with a good GPS fix is a solved problem. Everything that makes drones useful, inspecting under a bridge, mapping inside a structure, coordinating a fleet over a disaster zone, happens exactly where those assumptions fail.

The hard problem has four faces. First, perceiving without infrastructure: indoors, under canopy, or between buildings, GPS is unavailable and the aircraft must localize from its own sensors. Second, acting in a moving world: obstacles appear and shift on sub-second timescales, so a plan must be recomputed continuously and remain physically flyable. Third, coordinating many aircraft: assigning tasks and routes across a fleet is combinatorial and explodes with size. Fourth, sharing airspace safely: many aircraft, and other traffic, must be deconflicted in space and time.

These are different problems, state estimation, real-time optimal control, combinatorial optimization, and traffic management, and KESTREL pairs each with the appropriate method rather than forcing one tool across all four.

2System overview

KESTREL runs a loop from sensor to swarm and back. Each aircraft perceives and plans in hard real time onboard; the ground or edge coordinates the fleet; flight results refine the models. The split is deliberate: safety-critical control never depends on a link or a remote solver.

2.1Onboard plane and ground plane

KESTREL splits an onboard plane (perception, state estimation, planning, and control, running at hard real-time rates on each aircraft) from a ground plane (swarm optimization, fleet operations, and airspace deconfliction). The onboard plane is self-sufficient: if the datalink drops or a remote solver is unreachable, each aircraft continues to perceive, avoid, and hold or land safely. Nothing on the flight-safety path depends on the network or a quantum backend.

3Perceive — perception and navigation

Perceive gives the aircraft a metric understanding of where it is and what is around it, entirely from onboard sensors, so it can fly where GPS cannot reach.

3.1Visual-inertial state estimation

Pose and velocity are estimated by fusing camera and inertial measurements in a maximum-a-posteriori estimator over a sliding window. The estimate minimizes the weighted sum of visual reprojection residuals and IMU pre-integration residuals:

where X is the set of keyframe states and landmarks. This is a tightly-coupled visual-inertial odometry (VIO) that tracks the aircraft's motion with no external reference.

3.2Mapping and loop closure

As the aircraft flies, a map is built and maintained as a pose graph. Recognizing a previously-visited place adds a loop-closure constraint, and the graph is re-optimized to distribute the accumulated drift:

with ẑ_ij the measured relative pose between keyframes. Loop closure is what keeps a long GPS-denied flight from drifting away.

3.3Detection and depth

In parallel, learned models detect obstacles, people, and infrastructure and estimate their distance, producing a live occupancy map of free and blocked space. All of this runs on the aircraft's edge accelerator within a few milliseconds, because a perception result that arrives late is a perception result that arrives after the collision.

4Plan — real-time trajectory planning

Plan produces a smooth, dynamically-feasible trajectory to the goal through the free space Perceive reports, and re-solves it continuously so a changing world is handled as it changes.

4.1Trajectory optimization

Planning is posed as a receding-horizon optimal control problem: find the control sequence that minimizes a cost (progress, smoothness, effort) subject to the aircraft's dynamics, its actuation limits, and staying out of the obstacle set:

Because the dynamics f and input set U are the aircraft's real ones, the resulting trajectory is kinodynamically feasible: it can actually be flown, not just drawn. The problem is re-solved every few milliseconds against the latest occupancy map (model-predictive control), so a newly-seen obstacle changes the plan almost immediately.

4.2Guaranteed-safe fallback

Optimization can fail, no feasible path may exist in time. KESTREL wraps the planner in a control-barrier-function safety filter that keeps the aircraft inside a provably safe set ℋ = {x : h(x) ≥ 0} by enforcing

which renders the safe set forward-invariant: whatever the planner proposes, the filtered command cannot drive the aircraft out of safety. If no progress is possible, it slows and holds rather than gambling on a risky path.

5Swarm — multi-agent coordination

Swarm decides which aircraft does which task, in what order, along which route, and keeps the fleet coherent. This is the combinatorial layer, and where quantum and hybrid solvers earn their place.

5.1Task allocation and routing

Assigning tasks to aircraft under capability, energy, and deadline constraints, and sequencing each aircraft's route, is a coupled assignment and vehicle-routing problem. The decisions are encoded as binary variables in a QUBO, with constraints as quadratic penalties:

and solved with QAOA, a depth-p circuit alternating a cost and a mixing unitary whose angles a classical optimizer tunes:

A classical relaxation warm-starts the solve, and the CVaR of the measured energy distribution is minimized to concentrate on the best samples. Small fleets are handled by a classical solver; the quantum path engages as size grows.

5.2Decentralized consensus

Between global re-plans, aircraft hold formation and agree on shared quantities (heading, spacing, timing) over the mesh using local consensus dynamics:

which provably drives connected agents to agreement using only neighbour-to-neighbour communication, so the swarm stays coherent even if the ground link or a single node drops.

6Operate — fleet and airspace

Operate turns a set of capable aircraft into a safe operation: it deconflicts flight paths in space and time, manages energy across the fleet, and runs missions from launch to recovery.

6.14D deconfliction

Every planned trajectory is checked against every other in four dimensions, three of space and one of time, so no two aircraft claim the same volume at the same instant. Conflicts are resolved by re-timing (delaying a launch or slowing a leg) or re-routing, before takeoff and continuously in flight. The check is conservative: it reasons over each trajectory's uncertainty tube, not just its nominal path.

6.2Energy-aware operations

A learned energy model predicts each aircraft's remaining endurance from battery state, wind, payload, and planned profile, so KESTREL recalls or swaps an aircraft before endurance becomes a safety margin rather than a comfort margin. Recovery and charging are scheduled as part of the mission, not bolted on after.

6.3Airspace integration

KESTREL exposes standard interfaces for unmanned traffic management (UTM) and remote identification, so a KESTREL operation is a well-behaved participant in shared airspace and interoperates with existing authorities and other operators.

7Hybrid orchestration

The "quantum only where it pays" principle is enforced in code by a router that chooses, per job, between classical and quantum solvers and between onboard and ground execution, always guaranteeing a usable result in time.

7.1The router

Every job carries a class, a size, and a deadline. Perception, planning, and the safety filter are always classical and onboard. Swarm allocation and routing are sized: small ones go to a classical solver; large ones to the quantum/hybrid solver when a backend and time budget allow; and when a deadline looms, the router returns the best classical result. The router is free to choose classical, and for small fleets it does.

Autonomy / swarm router (simplified)def route(job):
    if job.kind in ("perceive", "plan", "safety_filter"):
        return Onboard(job.kind)          # hard real-time, never remote
    if job.kind in ("allocation", "routing"):
        n = job.drones * job.tasks
        if n <= CLASSICAL_LIMIT:
            return Classical(solver="milp")
        if backend.available() and job.deadline > QPU_MIN:
            return Hybrid(qaoa_depth=6, warm_start=True)
        return Classical(solver="heuristic")   # graceful fallback

7.2Backends and mitigation

One circuit interface runs across simulators and gate-model QPUs, so operators are not locked to a vendor and benefit as hardware improves. On real hardware KESTREL applies readout-error calibration and zero-noise extrapolation, and records which backend and mitigations produced each plan in the log.

8Deployment and integration

KESTREL runs on the operator's airframe and inside the operator's boundary, with a thin, self-sufficient stack onboard and coordination on the ground or edge.

8.1Onboard and ground

The onboard stack targets common edge accelerators and standard autopilot interfaces (for example MAVLink), so KESTREL flies on the operator's existing platform rather than requiring a new one. The ground plane runs on-premises or at the edge; flight data stays within the operator's boundary, and only abstracted optimization instances are brokered to a quantum backend over an encrypted channel.

8.2Simulation and hardware-in-the-loop

Every capability is validated first in high-fidelity simulation and then in hardware-in-the-loop, replaying recorded flights and stress scenarios (sensor dropout, wind gusts, sudden obstacles). New models are shadow-flown, advising without commanding, until they earn authority; autonomy is proven on the twin before it flies a mission.

8.3Logging and audit

Every perception output, plan, command, safety-filter intervention, and swarm decision, with the compute path that produced it, is logged for post-flight review. The system is auditable end to end, as operators and aviation authorities require.

9Validation and benchmarks

We benchmark against strong baselines, standard autopilots and classical planners and schedulers, and report where quantum does not yet win.

9.1Methodology

• Perception is scored by trajectory drift against motion-capture ground truth and by detection accuracy on held-out flights.
• Planning is scored by success rate through obstacle courses, path smoothness, and replanning latency against its budget.
• Swarm optimization is measured by solution quality (total energy, coverage) at a fixed wall-clock budget and by feasibility.

The verdict column is the point: learned perception and classical planning carry the single-aircraft problem; quantum optimization earns its place as swarm coordination grows, and on small fleets KESTREL routes to the classical solver.

10Limitations and current maturity

This section is deliberately blunt. Flight is unforgiving; credibility with operators and regulators depends on candor.

• NISQ reality. Quantum hardware is noisy and limited in scale. KESTREL's quantum advantage on swarm coordination is demonstrated in simulation and on small instances; classical solvers carry production coordination today, and the router falls back automatically.
• Perception has failure modes. VIO degrades in feature-poor, dark, or fog-filled scenes; detection can miss a novel obstacle. This is exactly why a classical safety filter, not the perception model, holds the safety guarantee, and why the aircraft slows when confidence drops.
• Sensing bounds everything. The aircraft cannot avoid what no sensor can see; thin wires, glass, and sudden intrusions remain hard, and are handled by conservative margins, not bravado.
• Autonomy is bounded. KESTREL flies within operator-set envelopes and defaults to a safe hold or landing in ambiguity; it is not an unbounded mission planner.
• Simulated figures. Every number here is illustrative of the target. Production performance depends on the airframe, sensors, environment, and backend, and is established per platform and validated in flight.

11Responsible use and safety

Uncrewed flight is safety-critical and dual-use. KESTREL is operated for civil and commercial missions, inspection, mapping, logistics, agriculture, and public safety, under operator agreements and within applicable aviation regulation and export controls. Safety is enforced by a verifiable classical filter that bounds every autonomous action; the system defaults to safe holds and landings, and keeps a human operator in command authority. Partner flight data and maps remain the partner's property and stay within their boundary; models are not shared across partners. Full provenance is retained so every perception output, plan, and action can be traced and reviewed.

12Roadmap

—References and further reading

1. Qin, Li & Shen. VINS-Mono: A Robust and Versatile Monocular Visual-Inertial State Estimator. IEEE T-RO 34 (2018).
2. Mur-Artal & Tardós. ORB-SLAM2: an Open-Source SLAM System. IEEE T-RO 33 (2017).
3. Forster et al. On-Manifold Preintegration for Real-Time Visual-Inertial Odometry. IEEE T-RO 33 (2017).
4. Mellinger & Kumar. Minimum Snap Trajectory Generation and Control for Quadrotors. ICRA 2011.
5. Zhou et al. EGO-Planner: An ESDF-free Gradient-based Local Planner for Quadrotors. IEEE RA-L 6 (2021).
6. Ames et al. Control Barrier Functions: Theory and Applications. ECC 2019.
7. Olfati-Saber, Fax & Murray. Consensus and Cooperation in Networked Multi-Agent Systems. Proc. IEEE 95 (2007).
8. Farhi, Goldstone, Gutmann. A Quantum Approximate Optimization Algorithm. arXiv:1411.4028.
9. Barkoutsos et al. Improving Variational Quantum Optimization using CVaR. Quantum 4, 256 (2020).
10. FAA / NASA. UAS Traffic Management (UTM) Concept of Operations, v2.0.

This brief describes a system and design intent. All performance figures are illustrative and simulated for demonstration; production characteristics are established per platform and validated in flight. © Ace Hacker Research & Development Lab.