Building Autonomy Pilot Models for Unmanned Aircraft: Data Integrity and Physics Context

The deterministic data problem

Flight dynamics obey strict physical laws. Lift depends on airspeed and angle of attack. Drag scales with velocity squared. A given control surface deflection produces a predictable angular acceleration for a given airframe. That's the ground truth every training sample should be measured against.

Real flight logs rarely hold to it. Sensor noise, logging jitter, GPS multipath, timing mismatches between onboard sensors: each looks fine in isolation. In aggregate they teach the model correlations that violate physics.

A model has no concept of possible or impossible. It just fits a function to whatever it's shown. A maneuver showing acceleration with no matching change in thrust state doesn't get flagged as noise. It gets fit, then extrapolated from later with full confidence.

That's worse than a normal outlier problem, because standard data cleaning has no concept of physics either. The error only shows up once you check the data against a dynamics model directly: does thrust state actually predict the observed acceleration? That's not cleaning for noise. It's cleaning for physical consistency.

Validating against the physics envelope

Statistical cleaning, outlier removal, distribution normalizing, doesn't catch this, because physically invalid samples are often statistically unremarkable. They sit within normal ranges. They just violate the relationships aerodynamics requires between those ranges.

The fix is validating each sample against the physics envelope of the specific airframe: its lift curve, drag polar, inertia tensor, then checking whether recorded state transitions match what physics would produce. A sample that fails isn't noise. It's false ground truth, and it has to go before the model learns something untrue.

Physics context as a design choice

Once the data is clean, the next question is how much physics the model itself should carry, and this is exactly where the propulsion problem I started with lives. A pure pattern-matching model trained across quad-plus-pusher and fixed-wing glide configurations will pick up separate patterns for each and have no way to reason about a configuration or failure mode it hasn't seen. A model with physics built in, whether through physics-informed loss functions, a hybrid architecture running a dynamics model alongside the network, or state representations built from angle of attack and airspeed instead of raw sensor values, can reason from the underlying aerodynamics instead of memorizing per-configuration patterns.

That difference matters most at the edge of the training distribution. Off-distribution, a pure pattern-matcher extrapolates from the nearest thing it's seen. A model with physics built in reasons from the relationships that still hold. At the edge of a UAV's operating envelope, that's the difference between a recoverable upset and a loss of control.

Flying with minimum sensor input

Worth separating out first: most of a flight isn't actually a hard sensor problem. Instrument approaches, IFR nav, GPS-guided cruise: the data needed is available and standardized, and a fairly simple deterministic model can fly this reliably. The hard problem shows up close to the ground, in contested or GPS-denied airspace, or wherever ground operations demand richer sensing than en-route flight needed.

GPS-denied environments are real. IMU drift accumulates. Radar degrades under weather or terrain masking. Airspeed sensors ice over. The standard response is degraded-mode operation: detect the failure, fall back, notify the operator. Conservative, often necessary, but it treats every sensor gap as a hard boundary whether physics actually demands one or not.

An airframe's dynamics can extend how long a coherent state estimate holds, because they act as a prior. Last known airspeed was X, no control inputs have changed, throttle's still at Y percent: airspeed is still approximately X. Physics constrains what's plausible. Sensors provide evidence. When evidence goes missing, prediction can carry the estimate for a while before anything has to degrade.

This isn't new. It's what dead reckoning and the prediction step of a Kalman filter already do. The real question is how far you can extend that prediction before uncertainty makes it unreliable, and whether the model is capturing the airframe's actual nonlinear behavior or a simplified approximation of it.

Sensor fusion versus physics inference

Standard fusion already uses a dynamics model to predict state, then corrects with sensor readings weighted by trust in each. What changes here isn't the presence of a dynamics model. It's how much authority it gets. Physics inference treats the airframe's aerodynamics as the constraint sensors have to answer to, not just another input to average in. A reading implying a state the airframe can't physically be in is wrong, full stop, and that can be recognized without knowing which sensor produced it or why.

This isn't a replacement for fusion. It's a layer giving the physics model veto power fusion alone doesn't grant it.

What this means for the interface

An autonomy pilot that can reason through degraded sensing is more capable, but it's also harder to communicate to an operator. Flying normally, the operator needs to know state, position, current action. Flying under degraded conditions, fewer sensors online, more reliance on inference than direct measurement, they need to know the confidence behind that state and what it's actually based on. A position readout that looks identical whether it's from three GPS fixes or aerodynamic dead reckoning is misleading. The interface has to show the epistemic state of the autonomy, not just its output.

Where this is going

All of this is the same argument at four different points in the pipeline: the data has to be physically honest, the model has to carry the right amount of physics for the configurations it'll actually fly, the runtime has to keep reasoning from physics when sensors quiet down, and the interface has to be honest about which of those it's currently doing. Get it wrong at any one layer and you're one silent failure away from the other three not mattering.

This is why I'm building a tool around exactly that pipeline, not just the model.

Autonomy engineers work offline: build, train, and refine pilot models in batch against archived missions, per airframe and per motion model, since a quad-plus-pusher and a fixed-wing glider need different physics envelopes and different pilot models entirely. Every flight, real or simulated, feeds back into an archive per aircraft construct, so the model keeps improving against its own flight history rather than a generic dataset.

HITL reviewers work on the other side of that boundary: deploying trained models in real time, one aircraft or many, watching how each one actually handles a maneuver or a degraded sensor state, and vectoring in when it doesn't. That's the interface problem from earlier, made concrete. A reviewer supervising multiple aircraft needs to see which ones are flying on solid sensor data and which are running on physics inference, not just a uniform "nominal" readout across the board.

Ground operations add their own layer on top, since airport data brings in constraints, airspace and traffic, that en-route flight never had to deal with, and the same physics-honesty question applies there too: is the model reasoning from real constraints or just pattern-matching a taxiway it's seen before.

None of this works if the foundation from the sections above isn't solid. A validation tool built on data that silently violates physics, or a model that can't tell an engineer why it made a call, isn't actually validating anything. That's the problem I'm building against.