Possible Multirotor yaw estimation regression since INAV 8.0 - transient errors after fast yaw maneuvers

[sensei-hacker]

The following is an AI-generated analysis which may be half wrong, fully wrong, or dead on.
I'm recording it here just to preserve it to look into later. It's likely that SOME part of this is accurate and potentially useful.

Summary

PR #9387 (merged Dec 2023, "Yaw/Altitude estimation sensor fusion") introduced three changes to imu.c that together create transient yaw estimation errors for multirotors after fast yaw maneuvers. These manifest as brief toilet-bowl episodes immediately following 180° yaw rotations that were not present in INAV 7.x.

Root Cause — Three Changes in PR #9387

1. Multirotor trust vector change (imu.c:438–441)

Before: vForward = {1, 0, 0} (forward vector, same for all aircraft)
After: vForward = {0, 0, 1} (thrust vector, points up for hovering multirotor)

For a hovering multirotor, the thrust vector is perpendicular to the horizontal plane. CoG heading projection through this vector makes heading estimation fully dependent on the magnetometer and GPS CoG with higher sensitivity to discrepancies between them.

2. imuCalculateMcCogWeight() drops wCoG during fast yaw (imu.c:352–359)

During a fast yaw maneuver, rotRateMagnitude is high → wCoG → 0. The Mahony filter falls back to gyro integration. After the maneuver ends, rotation stops, wCoG rises, and GPS CoG suddenly re-enters the fusion. If any gyro drift accumulated during the maneuver, the filter reconciles via a step change in yaw estimate — which the navigation controller then sees as a sudden heading error, triggering position hold instability.

3. Simultaneous mag + CoG fusion (imu.c:493–496)

Before PR #9387 (exclusive else if):

• Either magnetometer OR GPS CoG injected into Mahony error, never both

After PR #9387 (vectorAdd):

vectorAdd(&vErr, &vMagErr, &vCoGErr);

Both inject simultaneously. During position hold, motor throttle variation causes compass interference (distorted mag readings) while GPS CoG fluctuations inject at the same time. Both error sources add together into the Mahony integrator, creating larger corrections than 7.x.

Reproduction Pattern

1. Enter position hold (POSHOLD or RTH hover)
2. Perform a fast 180° yaw rotation via RC stick
3. Release yaw stick and observe position hold behavior for 3–5 seconds after maneuver
4. In 8.0+: transient toilet bowl orbit, typically 1–3 swings before recovering
5. In 7.x: immediate position hold recovery with no orbit

The effect is most pronounced with a magnetometer installed (additional mag error source compounds with CoG step change on wCoG recovery).

Relationship to PR #10854

PR #10854 (toilet bowl detection) was motivated by this regression and others. Users reporting increased toilet bowling after upgrading from 7.x to 8.0 are likely experiencing this.

Related PRs

• PR Yaw/Altitude estimation sensor fusion #9387 — introduced the regression (merged Dec 2023)
• PR Better yaw estimation for mulitirotor(magless operation) #11114 — AHRS-layer improvement (GPS-acceleration-based yaw estimation) partially addresses the transient recovery problem; merged

Suggested Investigation

Whether to revert any of the three changes in PR #9387 or tune imuCalculateMcCogWeight() to smooth the wCoG ramp-up (rather than step-recovering) after fast yaw maneuvers. A slower wCoG re-entry rate after fast yaw should reduce the step-change in heading estimate.

[sensei-hacker]

@breadoven while thinking about toilet bowling, my AI spontaneously decided to spit out this analysis. I don't know if there may be one little nugget in there that might be interesting to you. Not that I trust this analysis, or any AI, but it can be useful for brainstorming.