sensors: Apply bias computed during gyro zeroing regardless of BiasCorrectGyro setting.

[glowtape]

The inflight bias correction doesn't seem to gel with acro flight and noisy quads, so it's worthwhile attempting to disable it. There's a few reported instances where a quad gains a permanent bias.

I have the same issue over here on mine. It doesn't do it when hovering, but when doing acro, at the end of a session, there's a considerable bias. Can be handled in rate, but entering leveling, it tilts considerably as result. With BiasCorrectGyro disabled, everything is fine here.

(Betaflight seems to deal with this by disabling the integrator beyond certain angular rates. Might be worthwhile to explore.)

However, turns out that the gyro zeroing stops working with the setting disabled. So if you have a screwy gyro with a permanent offset, you're SOL.

This captures the bias up until the quad goes armed, then applies the last known value, if BiasCorrectGyro is disabled but gyro zeroing desired. Also disables the GyroBias warning (not sure how I feel about this, a gyro shouldn't have say 30°/s offset).

[fxbisto]

Thanks a lot for this glowtape
You're right; a gyro shouldn't have a 30 deg/s offset but unfortunately my F405-CTR is an example of one that does. As you mentioned, the other camp handles gyro offsets differently, and it works very well.
calibration is performed by waiting for the gyro data to be consistently within a set range (historically titled "moron_threshold" in baseflight by Timecop; only recently renamed in bf 3.4!) for a set time period (default is 750ms IIRC) That way we plug a battery in, set the quad down, and once it's stopped moving and the gyro data is within moron_threshold for the allotted time it's calibrated until the power is removed.
My screwy CTR gyro always worked fine on other firmwares using this method, never showing any drift or deviation even after hitting the floor very hard / clipping a branch at 60mph etc. I believe that this method will be fine for gyros with a 'permanent' offset such as mine, rather than damaged ones which might wander from their 0 deg/s position.
As mentioned on the forum I have tested this patch but something needs revision. To achieve proper calibration requires 2 or 3 re-arms after initial arm.

[tracernz]

build artifacts please

[tracernz]

Code looks okay in isolation. I'd like to take some time to read surrounding areas to consider how it interacts.

[dronin-ci]

Artifacts built, by request of @tracernz

• windows
• linux-x86_64
• macosx

[glowtape]

Our attitude filter does compute the bias. What's curious is that you said that without this patch, but BiasCorrectGyro enabled, it'll snap in place when arming. I wonder if also needs to run when disarmed, so that it can settle during power up already.

[glowtape]

@fxbisto Please see what this change does.

[fxbisto]

Sure thing, would you like another vid of results or just a written report?

[fxbisto]

I went ahead and did another screengrab video with commentary anyway :P
Results: Improvement.
Upon powering up the gyro is instantly more stable, perhaps about the same as after the first arm from last changes. Now only requiring 1 arm to successfully compute bias - however not correctly applied until we disarm for the first time.
For completeness I also tried ArmTime=2000 as only used 250ms in the vid. Results identical.
Vid at this address, will also post in forum: https://youtu.be/bWmq7vKo29A

[glowtape]

I suppose I have to try something else. Probably put the zeroing in sensors.c.

[fxbisto]

What's happening to cause perfect zeroing bias calculation after the disarm? Is it re-calculating when I disarm or is it just not updating the results from the initial measurement until after arming flag ends?

[glowtape]

IDK. I'm gonna set up a fake gyro bias on a test board tonight and see what happens.

[fxbisto]

No problem, if you wanted to reproduce my results more accurately these are the correction biases for my specific screwy gyro:

[fxbisto]

Sussed it!
I was intrigued that nothing was applied until AFTER we've armed the flight controller. Turns out that's because we're asking it to do GyrosBiasGet(&gyrosBias) up until we're in the FLIGHTSTATUS_ARMED_ARMED state - but it's too late by then as once we're armed and BiasCorrectGyro=false we're not looking for new bias values.
Solution:

if (status != FLIGHTSTATUS_ARMED_ARMING) 
                {  /* Keep updating bias until we're entering armed status, then keep using
				    those values, as they're the ones from gyro zeroing. */
				GyrosBiasGet(&gyrosBias);
			    }

In this case the new values are applied when we're arming, ready for when we get to ARMED state.
Tested and working fine with one caveat - we must wait for this to happen in attitude.c first:

else if(complementary_filter_state.initialization == CF_INITIALIZING &&
		(ms_since_reset < 7000) && 
		(ms_since_reset > 1000))

Otherwise the first arm will not be accurate. A power-on arming grace period seems sensible in this case, what do you think?

[fxbisto]

What is your thoughts on my arming delay idea? Is this is sensible place to put it? Should I make it a private SYSTEMALARMS case?
It's working well on my matek405 and revolution boards.
fxbisto@850f4f2

[glowtape]

Not a fan of a delay. I'll investigate doing a simple calibration in sensors.c.

[fxbisto]

Okay, no issue. 8 Seconds seems plenty long enough by the time an FPV pilot would have plugged in a battery, placed the copter & lowered their goggles, but I can appreciate it could be frustrating for a LOS pilot.
Looking forward to testing the v3.0 patch

[fxbisto]

Issue rectified.
Bias correctly calculated first time, every time; even when you arm before BLHeli tones finish - regardless of ArmTime.
Right on the money :)

[glowtape]

Glad to hear. I'm still trying something else.

The artificial horizon still takes some time to settle here with fake bias injected, trying to get it to converge faster. Some bits of the code are 6-8 years old, and that stuff isn't my forte.

[fxbisto]

I would hazard a guess that's to do with the 7 seconds accelerometer convergence in attitude.c I tried the grace period for. The GUI seems to take accurate accelerometer readings in under 2 seconds, perhaps you could simply speed that portion up? Attitude.c:Ln:597

The artificial horizon isn't something I use personally, but I know a lot of people who do.
I'm on hand as soon as you need me to test changes.

[fxbisto]

I snuck out and put a few packs into testing this today, reviews-wise it's only good things from me.
Forum post is here: https://forum.dronin.org/forum/d/603-how-is-gyrobias-calculated-whilst-armed/31

[fxbisto]

Do you need another tester for this? Looks like it's ready for showtime.
Meant to ask also: Does this mean we can remove the need to wait for ArmTime? Or are we still calibrating when arming?

[glowtape]

It still needs a tiny fix and another round of testing from me. Gonna implement it later today and test it tomorrow.