Improved wind estimator validity check

[breadoven]

Should provide a more realistic method for determining wind estimator validity. The current method flags the wind estimate as valid with only 1 estimate calculation occurring which is nowhere near enough for an accurate wind estimation. Also the existing method used to flag an invalid estimate can take up to 15 minutes to trigger which seems excessive and not very practical. It should be noted that the existing method hasn't been removed by this PR, the new method simply complements it.

The method used by this PR is based on a scoring system. Each new estimate calculation adds to the score and each 10s timeout without a new estimate calculation decrements from the score.

The estimate is considered valid with a score > 100 with max score limited to 115. 100 seems to be the number of estimate calculations required to get a reasonable estimate based on current filtering. The estimate is considered invalid with a score < 85. This means a valid estimate will take around 2.5 to 5 minutes to become invalid if no new estimate calculations occur.

One issue with this is that it takes longer to get a valid wind estimate but that seems better than having an estimate that is totally inaccurate flagged as valid.

Works as expected using HITL..

[github-actions]

Test firmware build ready — commit 6491789

Download firmware for PR #11614

238 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[Jetrell]

One issue with this is that it takes longer to get a valid wind estimate but that seems better than having an estimate that is totally inaccurate flagged as valid.

From your HITL test. How much longer does it take approximately ?
I ask due to the way APA PID attenuation works with virtual airspeed. If the user has their gains tuned tighter and they launch into a strong headwind. This can lead to oscillations until the estimate is correct.
I have experienced this in one case. The oscillations only lasted for a couple of seconds after launch until the reading was valid.
But if it takes too much longer to get a valid estimation. The airspeed will have increase significantly, making it even worse.

[breadoven]

It seems to take > 30s to achieve a valid estimation flying in a loiter hold. Flying with less positional change would take longer. In Cruise the estimation doesn't update at all, it just degrades. Currently it's flagged as valid after a single estimate update even though the estimate is nonsense ... which isn't helpful.

[Jetrell]

I was going to test this today. But I wanted a bit more insight.

It should be noted that the existing method hasn't been removed by this PR, the new method simply complements it.

Being that the current wind estimator implementation appears to provide some form of reading in a sort period of time after the first turn, as inaccurate as it maybe. Yet never the less, a 50% less accurate read is better than no read at all.
Does the scoring method still allow this inaccurate data from the original method to act as a first-read ? So the estimator output still has something to feed to features that are using this data.. Or does it just provide nothing for that first 30sec. Or the following 30sec after the data may become untrusted inflight ?

[breadoven]

I was going to test this today. But I wanted a bit more insight.

It should be noted that the existing method hasn't been removed by this PR, the new method simply complements it.

Being that the current wind estimator implementation appears to provide some form of reading in a sort period of time after the first turn, as inaccurate as it maybe. Yet never the less, a 50% less accurate read is better than no read at all. Does the scoring method still allow this inaccurate data from the original method to act as a first-read ? So the estimator output still has something to feed to features that are using this data.. Or does it just provide nothing for that first 30sec. Or the following 30sec after the data may become untrusted inflight ?

The wind estimate will still display the current estimate in the OSD but it'll be flagged with an * to show it's not valid. As for the things that depend on the wind estimate it depends on whether you're also using the Auto speed PR. If you are then this PR will prevent the virtual pitot from working for the things using pitotValidForAirspeed until a valid wind estimate is available. So this affects Auto speed mode and fixed wing TPA factor although it just means Auto speed will fall back to using ground speed and TPA will use throttle based TPA rather than airspeed based. Other parts of the code check pitot validity differently (just sensor present and updating) so won't be affected. This inconsistency probably needs fixing, I guess pitotValidForAirspeed was added later but not applied to older code.

I should probably move the wind estimate validity check I added to the Auto speed PR to this PR actually to avoid confusing things. But this PR followed on from the Auto speed one when I realised that the virtual pitot validity test didn't seem very robust because it ignored wind estimate which is fundamental to the virtual pitot working correctly.