Adding a second source of position to an aircraft sounds like a wiring job. In practice it is a systems job: the new source has to speak the autopilot’s language, the autopilot’s estimator has to weight it sensibly, the failover behaviour has to be defined before it is needed, and all of it has to be tested in a way that exposes failure modes rather than hides them. This article sets out each stage.
What “autopilot-agnostic” actually means
Most small-aircraft autopilots, open source and commercial alike, accept external position input through a defined interface. Typically that is a serial or CAN message carrying position, velocity, a timestamp and some measure of uncertainty. Some accept a message that looks like a GPS receiver’s; others have a dedicated external-navigation message carrying richer information.
A navigation source that is autopilot-agnostic exposes its output in one or more of these standard forms and does not require the autopilot’s firmware to be modified. In practice that means the source has its own compute and produces a finished position, rather than expecting the autopilot to run part of the algorithm. It also means the source does not depend on a particular software ecosystem, such as a robotics middleware, being present on the aircraft. Integration then reduces to physical connection, message configuration and estimator tuning, which most operators can do without the vendor in the room.
How an EKF fuses multiple sources
An autopilot’s navigation estimate is usually produced by an extended Kalman filter. The filter holds a running belief about the aircraft’s position, velocity, attitude and sensor biases, and updates that belief every time a measurement arrives. Each measurement comes with a stated uncertainty, and the filter combines the measurement with its current belief in proportion to how uncertain each is. A precise measurement moves the estimate a long way; an imprecise one barely nudges it.
Adding a second position source therefore does not mean choosing between it and GPS. Both feed the filter, which blends them according to their reported uncertainty. When both are healthy and agree, the estimate is slightly better than either alone. When one degrades and honestly reports a larger uncertainty, the filter automatically leans on the other. The important word is honestly. A source that reports high confidence while being wrong will poison the estimate, which is why the confidence reporting of any secondary source deserves as much scrutiny as its accuracy.
Most autopilot estimators also run innovation checks: if a measurement disagrees with the current belief by more than expected, it is rejected. These gates need to be set wide enough to accept a legitimate correction after a period of drift and tight enough to reject a bad fix, and finding that balance is part of the tuning.
Failover logic: when to trust what
Fusion handles gradual degradation well, but there are discrete decisions that still need rules. Consider defining, before the first flight:
- Which source is primary in normal conditions, and what health criteria it must meet to keep that role.
- What triggers a switch, expressed in terms the autopilot can evaluate, such as loss of fix, a persistent disagreement between sources, or a sustained rise in reported uncertainty.
- How a switch is executed, preferably as a change in weighting rather than a hard cutover, so the position estimate does not jump.
- The conditions for switching back, including a period of agreement before the recovered source is trusted again.
- What the aircraft does if both sources are lost or disagree beyond tolerance, usually a defined safe behaviour such as holding heading and altitude or returning along the last trusted track.
- How all of this is displayed to the remote pilot and logged for later review.
Writing these down forces the awkward questions into the open early, and the document becomes the basis of the test plan.
Testing before you trust it
A staged regime is safer than a single big flight. Bench testing with recorded flight data replayed through the estimator will catch message format and timing problems without risking an airframe. Ground testing, with the aircraft moved by hand or on a vehicle, confirms that the source produces sensible output and that the autopilot accepts it.
The first flights should run the secondary source in a monitor-only mode, logged but not fused, so its output can be compared against GPS after landing across a range of altitudes, speeds, light conditions and ground types. Only once that comparison is consistently good should the source be fused, and then initially with GPS still available so the estimator has a known-good reference. Deliberate GPS denial in flight, by disabling the receiver in software at a safe altitude over a safe area, is the final step and should be repeated across the conditions the aircraft will actually operate in. Each stage should end with a review of the logs, not just an impression that it went well.
Common integration mistakes
A few problems recur. Timestamps that are not synchronised between the source and the autopilot produce a position that lags at speed and looks like a lateral error. Coordinate frame and datum mismatches produce a constant offset that is easy to mistake for a calibration issue. Hard-coded uncertainty values, rather than ones derived from actual match quality, defeat the whole point of fusion. And testing only in benign conditions, on clear days over distinctive ground, produces confidence that does not survive the first hazy morning over a uniform paddock.
Where TerrainSLAM fits
TerrainSLAM is built as an autopilot-agnostic source that computes an absolute position onboard from terrain matching and delivers it to the autopilot through standard external-navigation interfaces, without requiring firmware changes or a robotics middleware on the aircraft. It reports a confidence with each fix so an autopilot’s estimator can weight it properly, and the staged testing above is how we would suggest any operator validate it on their own platform.