On 18 October, an INAV pull request proposed a Gaussian sum filter (GSF) yaw estimator for fixed-wing aircraft. It is open, disabled as an AHRS heading source by default, and not a released INAV feature. The case is worth examining beyond its eventual merge status because the same estimation architecture already appears in PX4's EKF2 documentation and ArduPilot's EKF-GSF implementation.
A GPS course is not a fuselage heading
GNSS velocity supplies a direction of travel over the ground. In still air during a coordinated, approximately straight fixed-wing flight, that direction may sit close to the aircraft's heading. In wind, the aircraft can crab: its nose points into the wind while the ground track follows the intended route. A direct assignment from course over ground to yaw can therefore import a wind-dependent error into attitude and navigation.
The physical relationship is straightforward: ground velocity is the vector sum of air-relative velocity and wind. A single ground-velocity vector cannot distinguish those contributions. The IMU contributes body-frame angular rates and acceleration, but angular-rate integration accumulates bias. A magnetometer supplies an independent direction reference when its calibration and electromagnetic environment are trustworthy. The design question is whether changes in the measured motion give an alternative reference when that magnetometer is wrong.
PX4 explicitly documents a multi-hypothesis yaw estimator that combines GNSS horizontal velocity and IMU data, optionally including airspeed information, then uses its output as a backup to the main filter. ArduPilot's compass-less operating guidance similarly warns that GSF needs accurate GNSS velocity and low vibration. The existence of those systems supports the mechanism, not the performance of the new INAV code.
What five competing headings buy the estimator
The INAV proposal uses five small extended Kalman filters. Each estimates north velocity, east velocity and yaw, starting from a different candidate heading. Gyroscope and horizontal-acceleration measurements propagate each candidate forward. A GNSS velocity measurement then tests how well the candidate predicts actual motion. The Gaussian sum filter gives more weight to candidates whose predicted velocity agrees with the observation and yields a composite yaw with a measure of uncertainty.
This is different from taking a circular average of the compass and the GNSS course. Candidate headings are judged on their ability to explain changing motion. A turn can supply information that a long, constant-velocity segment cannot: the body rotates, the inertial accelerations change in body axes, and their relationship to the observed horizontal velocity helps resolve the earth-frame orientation. The filter must still handle noisy acceleration, bank angle and delayed GNSS reports.
The INAV author says the proposed system runs at 50 Hz on fixed-wing craft in flight, fusing GNSS at measurement time. It takes roll and pitch from INAV's main attitude estimate rather than estimating independent tilt in every heading hypothesis. That is a significant architectural dependency: it reduces duplicated attitude-state machinery but allows roll or pitch errors in the main AHRS to influence the yaw candidates.
ArduPilot's GSF header exposes a model that predicts from IMU increments and corrects against north/east velocity with its reported accuracy. PX4's navigation-filter documentation describes the same general three-state, multiple-model method. Implementation details and enablement policy differ among stacks; sharing an algorithm family is not evidence of identical failure modes.
The estimate should admit when the flight has taught it nothing
Convergence is not automatic at takeoff. On an aircraft moving straight with nearly constant ground velocity, several yaw hypotheses can remain consistent with the observations. A filter can print a number before it has earned the right to control navigation from that number.
The INAV proposal therefore puts explicit conditions between estimation and use. According to its PR, it accumulates motion excitation in one-second blocks, requires 25 m/s of accumulated velocity change from maneuvers, and then requires estimated yaw standard deviation below 15 degrees for three seconds. The author describes the excitation target as roughly a 90-degree turn at 16 m/s. An innovation-consistency statistic can revoke usability, and sustained inconsistency restarts the estimator.
Those values are proposed implementation thresholds, not independently established safe limits for all airframes. A slow trainer, high-speed wing and a plane flying in turbulent air can supply very different accelerations and sensor noise. The useful principle is to separate a running estimator from one sufficiently constrained to be trusted. The specific thresholds require testing by aircraft class, GNSS receiver and flight envelope.
This also explains why the candidate deliberately keeps the primary AHRS option off by default. The proposed estimator can collect Blackbox data when it is not controlling heading, allowing developers to compare its result with other sensors before enabling it as a navigation source.
Timing can masquerade as an attitude error
GNSS messages arrive later and less often than IMU samples. A turn makes that delay visible: an old velocity vector compared with a current inertial prediction appears inconsistent even when both sensors are healthy. Treating reception time as measurement time can bias the winning yaw hypothesis or prevent the filter from becoming usable.
The proposed INAV implementation begins with a delay estimate of one GNSS update interval plus 20 ms. It then estimates delay from the alignment of inertial and GNSS velocity changes during turns. The author describes calculating alignment over a 400 ms history and accepting a refined delay only when its uncertainty is sufficiently low. The exact approach must be evaluated against real GNSS transport and firmware timing, which may differ from the simulated delay.
The pull request reports unit tests covering delays from zero to 260 ms at 10 Hz and a 220 ms case at 5 Hz. It also notes a hardware-in-the-loop case where plugin acceleration itself was delayed, complicating identification of the GNSS delay. These are author-reported tests, useful for deciding what to reproduce, not independent flight validation. The broader lesson is that an estimator can fail while every raw sensor appears numerically plausible if their timestamps refer to different moments.
Disagreement with a compass needs hysteresis
Once a second heading estimate exists, it can expose a bad compass. It can also falsely accuse the compass when GNSS velocity is corrupted or the aircraft has not maneuvered enough to establish yaw. A one-sample disagreement is a poor basis for switching heading sources.
With the experimental ahrs_gsf_yaw option enabled, the INAV proposal weighs the GSF estimate according to uncertainty, phases out a compass after sustained large disagreement, and allows it back only after sustained closer agreement. It also allows a bounded number of AHRS yaw resets when the primary estimate is far from the GSF result and no valid compass is available. These state transitions and limits are described in the PR; they are not promises about behavior of shipping builds.
The proposed related magnetometer-learning work illustrates a second use for independent yaw: fitting a compass against observed attitude and earth-field information, rather than relying only on a geometric sphere fit. It is also open and layered on unmerged work. Neither proposal removes the need to inspect installation alignment, motor current interference, sensor health and actual magnetic-field residuals.
Alternative heading sources deserve separate consideration. PX4 documents dual-antenna GNSS yaw, which measures baseline orientation rather than inferring yaw from a maneuver. That requires compatible hardware and a valid antenna baseline; GSF instead uses existing motion sensors but depends on the dynamics and data quality that make yaw observable. They solve related problems under different operational constraints.
What the reported tests do and do not show
The PR author reports unit tests for convergence, lack of false confidence without maneuvers, noisy GNSS, angle wraparound, gyro drift and delay estimation. In one simulated aircraft with wind, the reported yaw uncertainty remained broad until the first turn, followed by small error after maneuvering. Four X-Plane hardware-in-the-loop flights on a TBS Lucid H7 are described, including deliberately misaligned compasses and delayed GNSS. The author's outcomes are promising demonstrations of the intended logic, but they remain self-reported experiments on a limited set of configurations.
There are substantial verification gaps before this can be treated as an operational fallback:
- Excitation coverage: Straight departures, shallow turns, different airspeeds, crosswinds and long loiter segments need distinct cases. A filter should declare itself unavailable when the flight does not provide enough information.
- Clock and sensor failures: Dropped GNSS updates, inconsistent velocity-accuracy estimates, timestamp jitter and temporary interference can produce confident-looking but wrong estimates. Test loss and recovery, not just clean convergence.
- Attitude coupling: Compare failures induced by wrong roll/pitch alignment, launch acceleration and vibration. The INAV design's shared tilt makes this particularly relevant.
- Mode handoffs: Verify what the AHRS, navigation controller and operator see before yaw becomes usable, during compass rejection and after any reset. A heading discontinuity can change the interpretation of course commands.
- Resources and portability: The PR lists several kilobytes of added flash and roughly two kilobytes of fast RAM on supported targets, with tight code-memory headroom on some F7 builds. Porting is more than enabling a configuration bit.
A practical validation setup would retain a reference heading source independent of the experimental estimator where possible, record IMU, GNSS velocity, reported measurement ages, magnetometer data and estimated uncertainty, and replay the exact failure transitions. Use a simulator first; flight evaluation requires controlled conditions and an established recovery procedure. Reproducibility matters more than one clean plot.
Why a second heading estimate changes the safety argument
A sensor fallback is credible only when it knows whether it is observing the quantity it claims to estimate. With magnetometer-free yaw, the core constraint is not a clever filter equation but sufficient motion, trustworthy timing and conservative acceptance of uncertainty.
INAV's October 18 proposal provides a concrete design to review against existing PX4 and ArduPilot practice. It remains unmerged, the performance numbers come from its author, and the acceptance thresholds still need broader independent testing. The useful question for builders is therefore not whether GNSS can replace a compass in general. It is whether this aircraft, with this motion and these timestamped sensors, can establish an independent yaw estimate before the flight controller is allowed to act on it.