Position estimation drift

[Sibre3]

From the release of iNAV 7.1.0 I have been experiencing abrupt position drift while in navPoshold. The drift occurs both vertically and horizontally.
A quick look through iNAV github has revealed that others have also experienced the same. But when I asked about the matter on discord last month it was only known to one developer.
After following the trail left here by @ultrazar @Jetrell I have come to the same conclusion as them. This commit 4c4a74c is not scaling the accelerometer weight correctly. After inav_w_xyz_acc_p was replaced with a scaled clipping factor, to prevent poorly tuned quads momentarily shooting vertically.

Original method:
Used a relative alpha value to calculate and adjust the weight factor based on the time step dt and a predefined constant.
INAV_ACC_CLIPPING_RC_CONSTANT. This adjustment used to allow for a gradual transition in the weight factor, rather than an abrupt change. Only providing scaling reduction of the weight at higher vibration levels.

New method:
But now navGetAccelerometerWeight() function retrieves a weight for the accelerometer, which is then used to scale the estimated position and velocity corrections ctx.estPosCorr and ctx.estVelCorr. And that retrieves the current vibration level of the accelerometer, which is constrained between 1.0 and 4.0. The scaleRangef() function then scales this value to a range between 1.0 and 0.3, producing the acc_vibration_factor. With the same range as the old inav_w_xyz_acc_p.

This leads to attenuation of the accelerometer data to both estimators. Causing even abrupt stabilization motion while in navPoshold, to reduce the accelerometer weight unnecessarily. Leading to the quad drifting sideways, up or down by many meters in some cases. Requiring full stick deflection to correct the error.
I also observed weight attenuation reduction at lower temperatures on some FCs, when higher vibration spikes are present. Something not seen as often on warmer days.
inav_w_xyz_acc_p used to be set to 1.0 as default. With even a minor setting reduction leading to drift when other sensors are providing weak data.

Not withstanding the problems its causing some Rangefinder units. #10314

Expected behavior

For the quad to maintain its relative position as it used to pre 7.1.0. Without it randomly climbing, falling, drifting sideways, forwards or backwards and injuring someone.

Suggested solution(s)

• Allow significantly higher levels of vibrations before acc_vibration_factor scaling occurs.
• Or even replace the old setting back in the CLI. So users can choose between STATIC or DYNAMIC acc estimator weight. Because if
  your quad is setup correctly, the old method still works well.

Additional context

My quads are tuned smooth enough for iNAV 7.0.0 to show no issues at all.
I wrote a great deal of information about this issue on discord to @b14ckyy @sensei-hacker. I didn't report the matter here until now, hoping a fix for this critical bug would have been in 8.0.0.

• FC Board name and vendor: many boards
• INAV version string: 7.1.0 to 8.0.0

[Jetrell]

@Sibre3 I agree with your findings.
I personally feel this is behind many other reports too, not just copter related.
e.g. The new fixedwing vel_z controller and its altitude oscillations in navigation modes... And the reports of the accelerometer AHI drift returning.

[b14ckyy]

The Position_Z controller was a tuning value issue after the new controller was put in place. This is now fixed by reducing the strength of the D-Term by x3.

For the quad position issues afaik there is no final solution yet except making sure your build is not exaggerated noisy. But its still looked into for a better way.