Inav: Bad altitude hold behavior in 2.2

[FinalFrag]

I updated my S800 wing to inav 2.2 a few days ago. While testing the nav modes, I noticed that 3D cruise and loiter (with alt hold) were oscillating heavily.

Video: https://www.youtube.com/watch?v=38nds57TteQ
At the start of the clip, the plane is in one of the dives it does repeatedly, but the altitude in the osd is increasing. The same thing is visible 12 seconds in. When the plane pitches up at 18 seconds, the osd altitude keeps dropping. When the altitude catches up with reality at 23 seconds, the cycle starts again. It seems like the osd altitude is delayed by a few seconds, causing this behavior.

This plane and all it's althold modes worked perfectly in inav 2.1, so I decided to reflash 2.1 to confirm that and do some testing.

Video: https://www.youtube.com/watch?v=W7Q-Rl7hurw
Up to 42 seconds I'm in 3DCRS mode and everything is fine, altitude is holding a steady 90-ish meters. At 42 seconds I switch to loiter (with althold) and while the vario says a positive number at 49 seconds, the osd altitude is dropping. At 1:01 it is even more apparent with the vario at -5.6m/s but the osd altitude climbing. Up until 1:48 I keep it in loiter mode and the vario, osd altitude and real altitude are conflicting heavily and the plane is "doing the dolphin". At a certain point it even looks like the numeric vario is inverted? :/

Video: https://www.youtube.com/watch?v=q8JcU7w4qnw
In this clip I'm testing what happens when enabling RTH while below the configured altitude of 60m. As configured, the plane climbs before starting its turn towards home. Again, vario is inaccurate during the climb.
When reaching 60m the plane turns for home and goes into a dive. I switch to acro mode to save it. During the dive, vario seems correct at -3m/s, but osd altitude is stuck at 60m while the plane is on a crash course. Only a few seconds before the end of the clip the altitude catches up with reality.

Video: https://www.youtube.com/watch?v=rd3D0ZXwQjQ
In this last clip the vario inaccuracies are even more pronounced. At 10 seconds it states -10m/s while the plane is climbing. As soon as the plane levels out at 118m, everything calms down and behaves correctly. Just like before, 3D cruise works pretty well, only dipping a bit in the corners, but generally sticking the the 118m altitude pretty accurately. At 1:28 we see the vario at -11m/s again in a climb.

Sadly I'm unable to provide blackbox logs as my target (matekf405 servo6) does not appear to support it, although the fc has an sd card slot.

2.1 diff: https://pastebin.com/QGhVsMmy
2.2 diff: https://pastebin.com/C2szuwqC

TLDR: vario reading are inaccurate, 3d cruise and loiter is ok in 2.1, but got worse in 2.2

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label BUG to this issue, with a confidence of 0.94. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[MrLAtt]

I have also had the same issue with 2.2, but have also had problems with RTH mode, making it completely unusable since most of the time it would try to crash the plane instead of RTH.

I've gone back to 2.1 for the time being

[b14ckyy]

determine and set the board pitch alignment correctly. It is not set properly so this causes the fluctuation. This is in most cases the reason for height fluctuation especially in loiter.

[hali9]

Is Your plane well balanced in pitch axis ?
If yes, is Your pid well (especially in roll axis), did You do autotune ?
If yes, You can use only baro sensor and not use gps alt, try :

set inav_w_z_baro_p =  1.000
set inav_w_z_gps_p =  0.000

[FinalFrag]

The board alignment is the same both my 2.1 and 2.2 setup. It may not be 100% perfect, but since it is equal in both versions, it doesn't explain the difference.

set align_board_roll = -60
set align_board_pitch = 10
set align_board_yaw = 900

I did autotune the 2.2 setup, but the resulting PIDs did not make sense. It set P for both pitch and roll to 0 and 1 respectively, so I reverted back to using the defaults. All videos were made on stock PIDs.

I'll try disabling either gps and baro next time I'm out flying, see if the behaviour changes.

My main concern is that the vario and altitude are apparently not linked together/get their data from the same source. I tried figuring it out in code, but I'm not familiar enough with the code base. The vario showing -10m/s while the osd altitude increases is never a valid scenario...

[FinalFrag]

I updated to 2.2.1 today for some more testing.

First I double checked some things. Switching from acro to manual goes smoothly, so mechanically the plane is set up well. In angle mode the plane flies level and depending on the last maneuver goes up or down at about 2m/s, so the board alignment is setup correctly as well.

Then I disabled the baro on the configuration tab to see how 3d cruise and the variometer would behave purely on GPS info. As expected, GPS data is not fast enough to get good flight behaviour, but at least the reported altitude and the vario tell the same story (no more of that -10m/s vario when the altitude is increasing).
Switching to 3D cruise, the plane goes up and down like before. The tardness of the GPS data is to blame here, because the reported altitude is decreasing during a climbing motion and vice versa.
Video: https://youtu.be/D1mfXACi24A

Next I tried enabling the baro again and setting the inav_w_z_..._p to 1 for baro and 0 gps. This resulted in a much smaller oscillation (about 3 meter variance; totally acceptable), but the throttle still annoying me because it oscillates between 35 an 50%. This is a very loud wing so it is very noticeable.
Video: https://youtu.be/zpY8Rn7faKw

I decided to set the throttle_to_pitch setting to stop the throttle oscillation (still only using baro data, no gps). This again resulted in about a 10 meter height oscillation. Enough of a nosedive to make it uncomfortable over water 1km out so I switched to angle and called it a day.
Video: https://youtu.be/QrISYm0Khzg

After returning home I noticed I did my autotune session after these tests, so I guess I'll have to retest this on the new tune but I wanted to update this issue anyway in case it triggers some new insights.
2.2.1 diff after tuning: https://pastebin.com/MVp3R2Hi

It also seems I am the only one having these issues (or at least reporting on it) so I may just have a damaged GPS or flight controller? Or maybe a lot of people haven't updated to 2.2.x yet?

What do you think, should I swap out the GPS for a new one, or go straight with a new FC and GPS, or keep trying to figure this out?

[giacomo892]

Fist of all, since you are running a matek f405, please provide logs.
Second, which GPS module are you using?
Is the baro behaving correctly on the ground? What's the reading from the sensors tab?

[FinalFrag]

I'm afraid I cannot provide logs, the blackbox tab says "Your flight controller's firmware does not support Blackbox logging.". It seems I'm not the only matek user with that issue: https://github.com/iNavFlight/inav/issues/4904

I'm using a hglrc gps unit: https://www.hglrc.com/products/hglrc-7m-8m-ublox-m8n-gps-module-for-apm-pixhawk-cc3d-naze32-f3-flight-control-for-rc-drone

The baro graph in the sensors tab looks like this while sitting on my desk:
In the field the osd altitude stays at 0m before takeoff when only using baro for altitude measurements.

[giacomo892]

Enable blackbox from CLI then..

1. feature BLACKBOX
2. set blackbox_device = SDCARD
3. save

or just enabled Blackbox Logging from the configuration tab.

It should log the next flight.

[tiriad]

Same problem, in version 2.1 I didn't have this problem, same configuration, same values, in 3DCruise Mode strong decelerations and accelerations without maintaining the constant altitude in version 2.2.1

[preisedj]

I have experienced the same issue with MatekSys 405 Wing on a SonicModell AR Wing. When I use position hold, the altitude fluctuations and throttle fluctuations are nerve wrecking. My OSD indicates altitude fluctuations of about 10 meters, but in reality I am estimating at least 25 meters. I'll try switching out the GPS altitude and use baro only and see if it improves.

[teckel12]

@preisedj Do you fly with airmode on?

[preisedj]

Yes, air mode is permanently enabled. I've attached my flight log. There is about a 2 minute segment where I was in NavHold.
LOG00020.TXT

[teckel12]

@preisedj There was someone else who reported something similar but it only happened with airmode off. Must be unrelated.

[b14ckyy]

Yes, air mode is permanently enabled. I've attached my flight log. There is about a 2 minute segment where I was in NavHold.
LOG00020.TXT

I have just replayed your log. For me it seems like your Cruise throttle is way too high or your pitch to throttle ratio. Most likely pitch to throttle ratio. Also your Loiter radius is too small. 50m radios for speeds of up to 80kph is just too narrow.

Retune your pitch to throttle ratio. Fly in 3d cruise level, watch at your speed (enable 3D speed in OSD). Then pitch up to gain altitude. the plane should ideally keep the same 3D speed as in level flight. if it accellerats significantly, your oitch to throttle is too high. Therefore it will throttle up too much when correcting altitude and overshoots due to high speeds.

[preisedj]

Yes, air mode is permanently enabled. I've attached my flight log. There is about a 2 minute segment where I was in NavHold.
LOG00020.TXT

I have just replayed your log. For me it seems like your Cruise throttle is way too high or your pitch to throttle ratio. Most likely pitch to throttle ratio. Also your Loiter radius is too small. 50m radios for speeds of up to 80kph is just too narrow.

Retune your pitch to throttle ratio. Fly in 3d cruise level, watch at your speed (enable 3D speed in OSD). Then pitch up to gain altitude. the plane should ideally keep the same 3D speed as in level flight. if it accellerats significantly, your oitch to throttle is too high. Therefore it will throttle up too much when correcting altitude and overshoots due to high speeds.

I appreciate all the suggestions and I tried them all but there simply was no improvement. So I went with my long term plan to run Ardupilot on the same Mateksys F405SE Wing with the same setup. Voila, the loiter mode holds altitude within 2 meters. This is with the default settings for Ardupilot.

[dynahenry]

Hi,
There seems to to be a problem in calculating of the altitude in INAV 2.5.0. or 2.5.1.
I am using a SPRacingF3 FC in my 4" multicopter with GPS and Baro.
First i thought it is because there is a MS5607 assembled to my FC board instead of a MS5611 Baro.
So i modified the SW slightly to use the right Baro driver.

Behavior before modification displayed in inav-configurator. I was moving the board 0.8m up and down.

Behavior after modification. There is no visible change.
Then i went down and up the stairs in my house about 8 meters.

The Baro value decreases and increases as expected.
But the Altitude value stays nearly constant. Only if i rapidly increase or decrease the position of the board, the Altitude value changes. It seems not to be the Altitude value, it seems to be a Vario value.
Maybe that is problem with Althold?
The Altitude telemetry value on my Radio (TX16s with LUA) displays 0 Meter when i went down and up the stairs. I should display -8 Meters on bottom of the stairs.
Has someone an Idea?

[digitalentity]

@dynahenry arm the copter. When disarmed altitude estimate is kept at zero as we don't expect the device to change altitude when it is disarmed.