Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad altitude hold behavior in 2.2 #4878

Open
FinalFrag opened this issue Jun 24, 2019 · 9 comments

Comments

Projects
None yet
5 participants
@FinalFrag
Copy link

commented Jun 24, 2019

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

This comment has been minimized.

Copy link

commented Jun 24, 2019

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

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

@issue-label-bot issue-label-bot bot added the BUG label Jun 24, 2019

@MrLAtt

This comment has been minimized.

Copy link

commented Jun 30, 2019

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

This comment has been minimized.

Copy link

commented Jun 30, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 30, 2019

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

This comment has been minimized.

Copy link
Author

commented Jul 1, 2019

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

This comment has been minimized.

Copy link
Author

commented Jul 5, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 6, 2019

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

This comment has been minimized.

Copy link
Author

commented Jul 6, 2019

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: #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:
Screenshot_1 In the field the osd altitude stays at 0m before takeoff when only using baro for altitude measurements.

@giacomo892

This comment has been minimized.

Copy link
Collaborator

commented Jul 7, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.