New wind estimator in INAV 10 is too sensitive

[error414]

I noticed that new wind estimator from #11614 is too sensitive and mark wind data as invalid (astersik near wind OSD element). I happened to two planes.

My setup:
Inav version: Maintanence-10.x
Plane 1: Heewing T2, real pitot tube
Plane 2: Heewing T1, virtual pitot tube

video from T2: https://www.youtube.com/watch?v=ClvGF0pV3Sw
BB log:

LOG00002.TXT

If you would like I can provide logs and video from T1 as well

[breadoven]

It may well need fine tuning but it could also be indicating that the wind has changed and the estimate become unreliable. The previous wind estimate could be flagged as reliable even though it was in fact completely inaccurate. I'll have a look at the log and see if that shows anything useful that might help to improve things.

[error414]

Be honest I have no idea how wind estimator works at all. But what I testes in xplane11 (8m/s wind, 4m/s guts), I noticed that plenty of calculation was rejected due to restirction to 3ms or 6ms (depend on state).

If you would like I can make new test with debug_mode = WIND_ESTIMATOR. What values would you like there?

• validityScore
• hasValidWindEstimate
• spikeFilterDynAdjustment
• lastValidEstimateAltitude

is it ok?

[error414]

I added extra info to BB debug. see https://github.com/error414/inav/commits/error414/multitest/multitest-auto-speed/

LOG00003.TXT

DEBUG_WIND_ESTIMATOR debug channels (src/main/flight/wind_estimator.c)

Index	Value	Unit	Updated	Meaning
0	estimatedWind[X]	cm/s	Every cycle	Filtered wind estimate, North axis (earth frame)
1	estimatedWind[Y]	cm/s	Every cycle	Filtered wind estimate, East axis (earth frame)
2	estimatedWind[Z]	cm/s	Every cycle	Filtered wind estimate, vertical axis (earth frame)
3	V (raw airspeed)	cm/s	Only on new estimate calc	Last raw airspeed estimate from the ground-velocity / attitude-change equations (eq. 6), before spike filtering
4	validityScore	count (0–30)	Every cycle	Estimate validity score; increments on each new estimate, decrements on 10 s timeout. Estimate becomes valid above 15 (WINDESTIMATOR_VALIDITY_THRESHOLD), invalid at 0
5	spikeFilterDynAdjustment	count (0–40)	Every cycle	Dynamic spike-filter relaxation. Spike threshold is 300 + value × 40 cm/s, so 0 = baseline 3 m/s threshold, 40 = fully relaxed (19 m/s) to un-stick the estimate
6	State bitmask	flags	Every cycle	Bit 0 (1) = hasValidWindEstimate, bit 1 (2) = initialEstimate (still building the first estimate). So: 0 = invalid, 1 = valid, 2 = invalid + initial phase, 3 = valid + initial phase
7	spikeFilterRejections	count (cumulative)	Only when a sample is rejected	Running total of new wind samples discarded because one axis exceeded the spike threshold

Notes

• Indices 0–2 and 4–6 are written unconditionally at the top of updateWindEstimator(), so they are fresh every cycle — even when GPS heading/velocity is invalid and the function returns early.
• Index 3 only changes when a new estimate is actually computed (attitude change large enough, diffLengthSq > 0.04). A frozen value means no new wind calcs are happening — cross-check with index 4 draining and index 5 rising.
• Index 7 is never reset, so watch its rate of change rather than its absolute value. A fast-climbing count together with a high index 5 indicates the estimate is stuck and the spike filter is relaxing to recover.

[breadoven]

Looking at LOG00003.TXT I can see the issue is the one I noticed when testing myself. When spikeFilterDynAdjustment is active it decrements validityScore by 2 to degrade validityScore more quickly because spikeFilterDynAdjustment being active indicates the estimate has lost accuracy. The issue is that even if the raw estimate makes it past the spike filter validityScore still ends up being decremented by 1. Maybe this is too pessimistic.

Simple solution is to decrement validityScore by 1 rather than 2 so that it doesn't decrement at all if the raw estimate passes the spike filter. This would stop the estimate becoming untrusted in the log above during transient periods of excessive spikes. The best solution would be to fix the spike issue but I'm assuming this is just how this wind estimator model works. The other possibility is to only flag the estimate as invalid after a timeout period with a validityScore of 0, maybe 30s or so.

[Jetrell]

@breadoven I was out flying today with a build from last week. Which must have some of your wind estimator changes.
I have to report that it isn't working correctly. The wind direction indicator looks to be out by between 160 to 200degs. All this was referenced by the clubs weather station and the strips wind sock. So I knew the wind direction and speed at that location.

And the wind speed itself is as random as the virtual airspeed. OSD wind heading arrow has always pointed in the direction the wind is blowing. Like a wind sock. Now its pointing in the other direction more often. But the estimation is still incorrect most of the time. So it isn't just a case of arrow reversal.
The asterisk appears next to the horizontal wind OSD element, rather often. Even though I was making many turns greater than 180degs, within 1min most of the time.

On the first flight of the day. The virtual airspeed indicator had X! for the whole flight, regardless of how many turns that where made.

After looking over the DVR footage a few more times. It seems like the wind estimation is also becoming stale at the drop of a hat.
It's not like I'm flying in a straight line for any distance. I'm flying around within an area of 500 x 600m. With many turns being made in that time. Something that I am very familiar with doing.
I also looked back over some DVR footage from a few months back. Just to be sure I wasn't imagining things. And it was fine, as expected.

I'm thinking that the estimation may now be more accurate than before.. Not that I thought there was a problem with it previously. But it now only seems to hold that increased accuracy for a short period. And then becomes totally untrustworthy most of the time until a 270deg turn or roll is performed... While before its accuracy was slightly lower. But was still close enough to be accurate most of the time.

It is even effecting the way APA works. And makes VTOL transition by virtual airspeed void.

I have a log if you want me to post it to you on Discord.

[error414]

On the first flight of the day. The virtual airspeed indicator had X! for the whole flight, regardless of how many turns that where made.

Exactly same issue yesterday.

I flew with buddy so I can provide his DVR (he use inav before wind estimator change), and mine (inav 10). I have blackbox as well. I wil provide all if you would like

[breadoven]

I tested this today in HITL and it seemed to behave as expected, logically that is. It correctly estimated wind direction which was set heading South (aka a Northerly just to confuse things). This is logged as 180 degs and the OSD arrow pointed down the screen when flying North which is correct, wind heading being South. #11614 didn't touch basic the wind estimation calculation method though so if a valid estimation is obtained I'd have though the direction should be correct. If the estimate isn't valid then maybe not.

I did notice one issue where it's not doing exactly what was intended which I'll fix. Not sure this is the cause of the problems described here. I did also notice the wind estimation doing odd things when I was testing #11812 when it seemed to get stuck for far longer than it should so something isn't quite right.

On the first flight of the day. The virtual airspeed indicator had X! for the whole flight, regardless of how many turns that where made.

This a bit odd and tends to say that none of the wind estimation calcs managed to make it past the spike filter even though the filter is significantly relaxed for the initial estimate after boot up to ensure a valid estimate is achieved as quickly as possible.

It might be possible to glean something from the x, y, z wind estimates in the log files so would be useful if available.

[Jetrell]

I've already posted a log to you on discord from my second flight yesterday. I will also post the first one there now. The one where virtual pitot was X! for the whole flight.

I tested this today in HITL and it seemed to behave as expected, logically that is.

I have to wonder if the simulator might be having trouble replicating the effect real world wind conditions will play on specific airframes. The side drag coefficient of different airframes can vary greatly.
I don't know if the SITL/HITL was used by Roman and Shota to implement the fixes they made to actually get it to work as well as it has over the last few releases.
Before the changes they both made. It hadn't worked any better than it does now with your latest alterations.

[breadoven]

@Jetrell the issue here is the fact you're using a VTOL. Was @error414 also using a VTOL ?

#11668 added AIRPLANE as a pitot detection condition so if the VTOL was in Multirotor mode at power on the Virtual pitot wouldn't be detected which explains the X! for the entire flight. A VTOL mixer profile change obviously doesn't reload platform specific features such as pitot sensor so the solution is to remove the AIRPLANE condition. Not sure how that will work out when switching between platforms because OSD Pitot should really be marked X! in multirotor mode because it's unreliable. Changes need further checking.

(If you want to fix this yourself then just go to

inav/src/main/sensors/pitotmeter.c

Line 155 in 2e8857e

if (STATE(AIRPLANE) && feature(FEATURE_GPS)) {

and delete STATE(AIRPLANE) && ).

I assume the second flight (that I take it did show Pitot airspeed in the OSD) was powered on in FIXED WING mode ?

As to the accuracy of the wind estimation:

Has this VTOL plane been flown pre the wind estimation changes ? If so how was the estimate in that case ? I'm curious as to how well a VTOL behaves in FW mode with all the additional VTOL hardware affecting the attitude response. I assume this has 4 fixed lift motors in addition to the 2 wing motors ?

It wasn't clear what the wind direction was from your Discord message, sounded like it was a Northerly wind because you said it was mostly coming from almost due north. If this is the case then the wind heading shown by wind estimator in the Log should be 180 degs. The first log shows it was on average around 70 degs, so neither N or S. The second Log (with virtual pitot = X!) shows a wind direction of around 350 degs on average so close to N/S but possibly 180 degs out.

As mentioned above #11614 made no changes to the wind estimation calculation method it only limited which calculation samples were used for the final estimate and provided an indication of validity based on the number of good samples.

It could just be the current changes in #11614 are using tolerances that are too tight (to improve accuracy) so may need relaxing to find a better compromise vs the previous method.

[error414]

yes, you are correct, I was ussing VTOL.

[Jetrell]

added AIRPLANE as a pitot detection condition so if the VTOL was in Multirotor mode at power on the Virtual pitot wouldn't be detected which explains the X! for the entire flight.

That would make sense.

I assume the second flight (that I take it did show Pitot airspeed in the OSD) was powered on in FIXED WING mode ?

Actually no. The second flight (which you have the log for) and all the following flights where all powered in MC VTOL mode as was the first.

Not sure how that will work out when switching between platforms because OSD Pitot should really be marked X! in multirotor mode because it's unreliable.

The irony of this is.. This specific VTOL and another, have been running a speed and timer based transition logic I wrote, for many months before the new VTOL auto transition PR was loaded onto this model... And even though wind and virtual airspeed are technically not highly trusted in MC VTOL transition state, going from MC to FW flight. I found it to work remarkably well while using virtual airspeed. As did APA.
But now it falls over.

Has this VTOL plane been flown pre the wind estimation changes ? If so how was the estimate in that case ? I'm curious as to how well a VTOL behaves in FW mode with all the additional VTOL hardware affecting the attitude response. I assume this has 4 fixed lift motors in addition to the 2 wing motors ?

Yes, it handles well, when comparing to the same airframe without the VTOL hardware. The main thing you feel is the extra drag and weight on the wings, in the way it dampens the roll axis. Which can be tuned out with expo and different rates and FF.
As mention in my previous reply. I ran it many many times before with my transition logic. And the wind estimation and virtual airspeed worked very well on this airframe. No differently to any of my other fixedwing test planes.

Yes wind was generally coming from due north. And was swinging +- 20degress either side of that throughout the day.
And yes to your assessment too. The wind direction was noticeably incorrect.

I'm thinking that the way the wind estimator and virtual airspeed worked previously to these changes, fell back heavily on 3Dspeed if the estimate wasn't known, or totally correct.... But I did do a lot of testing with it last year. On many fixedwing airframes and VTOLs, comparing virtual pitot to real pitot airspeed at launch. And i found it was remarkably accurate. Even when it would get a fast estimate of the virtual airspeed straight after launch. And it would also get a rather accurate wind heading, even just after a 90deg turn.
This worked out very well. Because it made it perfect for APA launches and MC to FW transitions.
I even found it considerably more accurate than Ardupilots virtual airspeed.

I appreciate your efforts in trying to improve it. However I think in an attempt to gain more accuracy. Which you have. It has made that accuracy only usable and trustworthy for a small portion of the flight. Unless you constantly fly around in circles.. While the way it was before this, after INAV 6.0, the guys worked out a way to make it work more consistently with only a little less accuracy.. But never the less it was far more usable, as I mention previously.

I'm incline to think the cause is in this #11668. Because I hadn't used this until the other day. And from memory. I had used your earlier changes once on this VTOL and many times on other fixedwings. And didn't experience the reported problems.

[b14ckyy]

@breadoven

I did also notice the wind estimation doing odd things when I was testing #11812 when it seemed to get stuck for far longer than it should so something isn't quite right.

Yeah I noticed that too but only when I tested at really excessive speeds at 30-50kph wind in my tests. I thought it was caused by the long time it needed to reach a waypoint against the wind or because of the sim update rates.

But if its broken I wonder if your fix should go into maintenance 9.x instead since there will be another patch anyway as the LTS version. @sensei-hacker what do you think?

[breadoven]

@breadoven

I did also notice the wind estimation doing odd things when I was testing #11812 when it seemed to get stuck for far longer than it should so something isn't quite right.

Yeah I noticed that too but only when I tested at really excessive speeds at 30-50kph wind in my tests. I thought it was caused by the long time it needed to reach a waypoint against the wind or because of the sim update rates.

But if its broken I wonder if your fix should go into maintenance 9.x instead since there will be another patch anyway as the LTS version. @sensei-hacker what do you think?

The change causing the problems mentioned here was introduced in 10.x so not relevant to 9.x.