Nav position estimator baro air cushion compensation fix

[breadoven]

Prevents baro air cushion effect compensation remaining active when it shouldn't be and also limits its use to multirotor only. Should close #10917.

Needs testing.

[ABLomas]

I can test (if you think it can fix #10917 - i don't think so, as i tested with GPS_ONLY and still had altitude drops with rangefinder) on weekend, but where to pick binary (speedybee f405 wing)?
My compilation setup is 2 weeks away at this moment

[breadoven]

@ABLomas You should be able to download the firmware for this PR from:

https://github.com/iNavFlight/inav/actions/runs/15788138905/artifacts/3373282765

(Above link found at https://github.com/iNavFlight/inav/actions/runs/15788138905/job/44509308684, under "upload firmware images")

Doesn't make sense this would fix #10917 if you did test with GPS_ONLY but it's the only obvious thing that could cause the affect you're seeing. The baro air cushion problematic logic ties in with the log file you provided pretty well exactly. This PR is valid either way because the current logic doesn't work. If it fixes your issue then all the better.

[breadoven]

Changes made to improve take off behaviour for multirotor in AltHold mode. Seems to prevent the altitude yo-yo effect seen with the old method so lift off should now be smoother.

[ABLomas]

OK, so with airplane this made no difference - at least with default settings (still having altitude oscillations)

[breadoven]

OK, so with airplane this made no difference - at least with default settings (still having altitude oscillations)

Hmmm that's a shame because it's not at all obvious what else might be causing your problem. It's odd given the problem in #10917 and the log data seemed to fit with the Baro air cushion logic very nicely.

[breadoven]

I was checking LOG00009 in #10917 again and I'm afraid that issue is definitely related to this PR. The behaviour of estimated position Z fits the air cushion logic pretty well exactly with one example shown in the following screen shot:

Estimated altitude starts to recover at 07:36.806 because the surfaceRaw is > 20 cm briefly setting air cushion to False but then starts to fall again when surfaceRaw drops below 20 again setting air cushion to True causing a large correction to takeoff altitude.

I'm not sure what you did @ABLomas but it's hard to see that you tested the change in this PR. I need to recheck the correct firmware file you need to use. Can you confirm the target name ?

[ABLomas]

Can you confirm the target name ?

I took FW from #10925 (comment)
Also there are more changes after initial post, it seems (7997094 ) not sure if that was included in zip linked earlier.
FC used - Speedybee Wing (bigger version).
I can flash latest changes and re-test, including blackbox data (just need to make new canopy - current version did not wanted to participated in testing and ejected somewhere 10km away from me :D ) if you link firmware which needs to be flashed.
Also, should i keep inav_default_alt_sensor on default (BARO, IIRC)?

[breadoven]

The correct firmware should be available from:

https://github.com/iNavFlight/inav/actions/runs/16260928120/artifacts/3524513555

Keep inav_default_alt_sensor set on default.

If this doesn't work then I've no idea what the problem could be unfortunately.

[Jetrell]

@breadoven I ran some tests with this today on a plane with a rangefinder.. And a copter.

Firstly I ran some fixedwing nav flights without these commits. And it was noticeable to see the surfaceRaw in the log spiking. And at that time navPos[2] would reduce in altitude and the plane would pitch up as the motor throttled up for a ghost climb.

Then I loaded the last commit from your changes here.
The surfaceRaw spikes still appear in the logs. But I never experienced the altitude errors I did previously. So there where no ghost climbs attempted by the altitude controller.

Changes made to improve take off behaviour for multirotor in AltHold mode. Seems to prevent the altitude yo-yo effect seen with the old method so lift off should now be smoother.

I tested taking off with the copter in Althold, with and without these changes. And it certainly seemed much smoother with them, than without. The throttle even feels more linear with respect to the copters actual altitude changes.

[breadoven]

The launch behaviour for multirotor seems much better with this change, a lot more predictable. Sounds like it works for fixed wing also although it would be useful to get additional feedback related to the original issue #10917.

[ABLomas]

would be useful to get additional feedback related to the original issue

Maybe yes, but in practice it it hard to do ;-)
I had 3x TOF10120 rangefinders - and all 3 died in process (1 is my fault, but others two - i dunno, really, power is filtered, maybe hypersensitive).
So i ended with TF-Luna (benewake) rangefinder. Real range above grass is ~3m (compared to <40cm for TOF10120) and it did not failed in flight.

I did not encountered any "altitude fluctuations" (using firmware from linked above url: https://github.com/iNavFlight/inav/actions/runs/16260928120/artifacts/3524513555 ) - but this may be due to fact, that luna did to made false triggers in flight. I quickly reviewed ~50km of DVR and at least OSD did not shown anything else than "--" in rangefinder altitude (real altitude closer to 50m).

So it's hard to say for now, what fixed issue - better rangefinder (which does not make false positives), or code fix. To test properly i would need to order pack of TOF10120 (what i don't want to do, because thay are garbage and range unusable on airplane), or flash older firmware and do long trip (will do that if weather allows). But for now i believe it's safe to close issue if fix is merged to INAV 9 changes and re-open if it resurfaces (in some different way, i believe)

[filipmu]

I was ready to report an erratic altitude estimate with VL53L1X rangefinder enabled in 8.0.1 for fixed wing when I found issue #10917. I have blackbox logs and video showing both slow estimate drift of navPos[2] from baro (10M difference 17 sec after launch when in Angle mode) and jumps to a negative estimate (at ~1 min) then more drift to -10M and finally a jump up to +2M 10 sec later (baro is at 36M). Its a 5 min flight. I also have a similar flight of 4 min where the rangefinder is disabled that does not show this behavior? Would these be useful to post? I can try the proposed fix next flight as well.