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 9eaef95

Download firmware for PR #11614

237 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]

That's a good find concerning Cruise. I guess the logic makes some sense. But as you know, Cruise can be turned by stick input.

This would seem to indicate just how well 3Dspeed also works for general Attenuation/Boost PID speed processing. As well as for other applications that can use virtual pitot, when the virtual estimation isn't totally reliable. Maybe the effect airspeed difference has on an RC model at lower flight speeds, isn't as bad as theory would suggest, but obviously only up to a point.

From past tests and OSD post flight analysis. When in a launch climb-out, the wind and virtual airspeed correction, is generally in favor of the actual wind direction, straight after the plane gets airborne . i.e. virtual airspeed reads higher than 3Dspeed, when launching into a headwind.
So it would appear the vertical wind calculation is also assisting to provide a somewhat beneficial read ? But it isn't until after a 360 turn that the wind direction and speed are updated to what I've known to be correct from on-site weather station data, at that time.

EDIT:

So it would appear the vertical wind calculation is also assisting to provide a somewhat beneficial read ?

Maybe not... I had a quick look at the OSD footage of a 4 +1 VTOL transition from a MC hover to horizontal flight, without any altitude change. And immediately after the forward speed reaches around 20km/h, virtual airspeed becomes active on the OSD, and also reads higher than the GPS ground speed, when transitioning into the wind.
This seems to be consistent across all the OSD footage I have viewed.