GNSS-loss dead reckoning — use existing accel-bias-corrected velocity estimator instead of fixed airspeed

[larpvox]

Apologies for this being written by AI, but it’s the best way to get my point across.

docs/GPS_fix_estimation.md realistic error of ~200m/km during GPS-loss dead reckoning, with the assumption (from gps.c) being that without a pitot, the aircraft flies at a fixed configured airspeed, integrated forward with mag heading. That’s the likely dominant error term — it’s blind to throttle, pitch, and gust variation during the outage.

navigation_pos_estimator.c already maintains posEstimator.est.vel with continuous accelerometer-bias correction (w_acc_bias, accBiasCorr) and a decay term for when velocity sources are lost (w_xy_res_v). That machinery is normally driven by GPS residuals. Proposal: during GNSS loss, instead of falling back to the separate fixed-airspeed model in gps.c, keep propagating posEstimator.est.vel forward from its last GPS-corrected value using the existing accel integration, with w_xy_res_v-style decay pulling it back toward last-known cruise trim (or a configured expected-cruise value) rather than decaying to zero. This reuses existing estimator infrastructure rather than adding a parallel one.

Rationale: seeding from last-known-good velocity + accel propagation should track real dynamics (throttle changes, climbs, gusts) far better than a fixed constant, while the existing decay/residual-correction terms already provide the “soft revert toward expected trim” behavior needed to bound accelerometer-bias-driven drift, rather than letting it walk away unconstrained.

Happy to help characterize the current error breakdown (how much comes from airspeed-assumption vs. heading vs. wind-staleness) with a HITL test using the existing INAV-X-Plane-HITL rig if that’d help scope this before a PR.

[sensei-hacker]

Integrating the acceleration value from a $3 IMU gets a LOT of error over half a million cycles (a few minutes). On the first integration, approximately 150 m/s of velocity error after five minutes. (336 MPH of error.)

That's not necessarily better than the known, measured, actual airspeed.

Suppose I know my plane cruises are 45 MPH.
Integrating the accelerometer and gyro says 380 MPH. If we average the two values we get 212.5 MPH. Not necessarily better than sticking with 45.

If you had a ring-laser gyro you can definitely use that. The most commonly used ring laser costs $10,000, though.

If you want to simulate this in the simulator there are a couple small things to add to the code:

1. Over the first three minutes, add 10 mg of error to your zero calibration on the x/y axis and 20 mg on the x axis to simulate the accelerometer warming up

2. Add 400mg sqr(Hz) of random noise (for a plane; multiply by 8 for a quad, which has four vibration motors rigidly attached to the accelerometer)

3. Add random +- 1.5° error to the gyro calculated attitude, so the calculation thinks the plane is level and accelerating, but the measured g is actually because the plane is 1° nose down

These will approximate the error you see on the MPU6000 datasheet.

If you simulate it with noise per the datasheet, you may notice that on a plane, the warm-up error is a significant portion of the error. So if pilots waited three minutes, then power cycled with the aircraft perfectly motionless to get a fresh zero, it would work better. The error would be only about 30-80 MPH of error after a few minutes.

[larpvox]

Appreciate the concrete numbers — that reframes things well. 150 m/s over 300s implies an effective bias around 0.5 m/s² (~51 mg), which is much bigger than accelerometer bias instability alone would suggest. Working through your third error source (1.5° attitude error), g·sin(1.5°) ≈ 0.26 m/s² leaks into the horizontal channel from gravity alone — that's roughly half your total right there, so tilt-error-driven gravity coupling looks like it's doing at least as much damage as raw accelerometer bias. Good catch, that's a different failure mode than I was modeling.

Although, 51mg effective bias seems a bit strong next to the MPU6000 datasheet — typical factory-trimmed offset is usually closer to low tens of mg, and your warm-up figures (10-20mg) plus tilt-coupling (~27mg-equivalent) don't obviously sum to 51mg without some added noise-driven random walk in the mix.

This also makes INAV's current fixed-airspeed approach look more justified: ~200m/km error is nowhere near what raw double integration would produce over the same time, so it's clearly already routing around this problem rather than being a naive placeholder.

Some ideas:

Rate-clamp against last known GPS velocity by bounding how fast the estimate is allowed to change per update based on the aircraft's plausible accel/decel envelope from last trusted GPS speed. Guards against exactly the kind of transient spike your tilt-error and warm-up models would produce — a real airframe's thrust/drag can't jump instantaneously the way a corrupted IMU reading can.

RPM as an independent airspeed proxy, for aircraft with it available.
For a fixed prop, RPM at a given throttle shifts with airspeed via advance ratio (V/(n·D)). Logging RPM vs. GPS groundspeed (and importantly, wind vector) at a couple of speeds during normal S&L flight (cruise + at least one other point) builds a rough per-airframe RPM→airspeed curve while GPS is still trusted, usable as fallback once it's lost. Caveats: density altitude and prop wear will shift the curve over time, but it's still an independent channel.

With the clamp plus the fact that nav modes push you towards the cruise speed anyway this is much more realistic.

[sensei-hacker]

RPM as an independent airspeed proxy, for aircraft with it available.
For a fixed prop, RPM at a given throttle shifts with airspeed via advance ratio (V/(n·D)). Logging RPM vs. GPS groundspeed (and importantly, wind vector) at a couple of speeds

That's an interesting idea.

Rate-clamp against last known GPS velocity by bounding how fast the estimate is allowed to change per update

Along the same lines, it occurs to me that absolute airspeed (near level flight) isn't likely to be 3X the cruise airspeed. Or less than cruise / 4. So you can clamp at some multiple . Maybe 50% - 150% of normal cruise or something like that. Naive integration error can easily put my Zohd Drift at 300 MPH. Knowing the maximum structural speed is 40 MPH and cruise is around 25 ...

Accelerometer may be best for tracking that is is going faster than it was 0.1 - 2.0 seconds ago, because it sees acceleration relative to a second ago. But not integrating that over hundreds of thousands of loops.

PS - I have read from several people who tried this in different ways. Their empirical results track with what we have discussed. Which doesn't mean it can't be used at all. Just that it's limited.