Replies: 2 comments · 1 reply
|
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. 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:
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. |
|
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. With the clamp plus the fact that nav modes push you towards the cruise speed anyway this is much more realistic. |
That's an interesting idea.
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. |
Uh oh!
There was an error while loading. Please reload this page.
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.
All reactions