Altitude loss while in POSHOLD, navPos laggs behind?

[mf0o]

Current Behavior

When enabling POSHOLD the wing looses altitude and even pitches down actively, mainly on the very first turn.

The barometer and GPS values are showing the decent, but the iNav calculated altitude seems to lag behind somehow.

This is the raw DVR: https://www.dropbox.com/s/pvkoux7n90n2hqy/pict0430_poshold_clean.mp4?dl=0
Here is the snipped, overlayed with blackbox data, slowed down: https://www.dropbox.com/s/a5m4jshwm3jy1y5/c2_raidix_poshold_pitch_down.mov?dl=0
This is a chart of the three altitude readings for the scene above:

This is the BBE on the POSHOLD timeframe where alt and pitch input can be seen:

Thanks a lot in advance!

Steps to Reproduce

1. enable POSHOLD

Expected behavior

iNav altitude "closer" to sensors, not taking nose down in POSHOLD.

Suggested solution(s)

n/a

Additional context

Setup:

• TBS Caipirinha 2 PNP
• BN220 GPS
• iNav 2.3, 2.4
• reduced airflow using open-cell foam on airduct and barometer itself
• trim verified, last auto-trim midpoints to 1491/1515
• pitch-align is set
• fw_reference_airspeed increased to 1666 (60kmh)
• ANGLE works
• 3DCRS works

some config items:
set inav_use_gps_velned = ON
set inav_w_z_baro_p = 0.400
set inav_w_z_gps_p = 0.200
set inav_w_z_gps_v = 0.100
set nav_fw_cruise_thr = 1400
set nav_fw_bank_angle = 35
set nav_fw_pitch2thr = 17
set nav_fw_pos_z_p = 50
set nav_fw_pos_z_i = 5
set nav_fw_pos_z_d = 5
set max_angle_inclination_rll = 600
set max_angle_inclination_pit = 600
set fw_reference_airspeed = 1666

full dump:
https://pastebin.com/rACwABti

---

• FC Board name and vendor: BrainFPV Radix (BMP280 Barometer)
• INAV version string: INAV/RADIX 2.4.0 Mar 8 2020 / 11:01:38 (da467a8)

[issue-label-bot]

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

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

[digitalentity]

Share the blackbox log please, not the rendered video that doesn't contain all the data to look at

[digitalentity]

Also note that RADIX is not officially a supported board. Please reach out to BrainFPV for debugging this.

[mf0o]

Hi Konstantin.
Thanks, blackbox log can be found here: https://www.dropbox.com/s/7vflyjh4djdwsp7/LOG00014.zip?dl=0

I'm already in touch with BrainFPV but I will be very thankful for your input if possible.
Have talked to a lot of people about this in the past weeks before opening the issue. Obviously trying to avoid ripping all cables out to put in a Matek.

"Help me, Obi-Wan Konst-ino. You're my only hope."

[isfelixthecat]

Hi mf0o
Inav 2.4. Matek F405 wing. Flashed Matek 405SE 2.5. C1 Chaser. Losing height after 25-50 mins of flying in POS/ALT hold. Log file shows - barometer & inav target is below target height( sometimes by 50-100m but consistently 10-20m) and then it just loses height rapidly in the end and crashes into the ground. Motor is running at around 50% ramping up to 55% as voltage sags. Maximum climb angle set at 12 deghrees so perhaps this is limiting it's ability to climb. Will try this soon and give some feedback.

[isfelixthecat]

I changed maximum climb angle from 12 to 20 degrees and this has improved its ability to maintain altitude. Over the first 15 minutes the C1 Chaser did drop 25m but corrected itself to reach the target height. The next 45 minutes altitude was held within 10-15m and by the end it was nearly spot on with corrections going above and below target. . I then flew in 3D cruise mode for 10 minutes at nearly precisely the correct height. It is difficult for a wing to maintain height when you are turning crosswind to downwind(craft lowers altitude) and then crosswind to headwind(craft gains height). So whilst it is not perfect it is much better.

[breadoven]

I have the problem of unstable altitude hold during POSHOLD with variations of up to 20m and best of 12m. This is on a Phoenix 2400 motor glider. ALTHOLD works fine by itself as do other modes but the ALTHOLD part of POSHOLD seems to struggle with the constant disturbance caused by turning.

The thing I noticed from the logs is the elevator input pretty much only starts to move to cancel the previous corrective input as the plane hits the target altitude by which time it's too late to stop any overshoot. E.g. if descending toward the target altitude nose down elevator is held until target is almost hit with zero elevator at target followed by overshoot and up elevator only really kicking in after passing below target. Assuming up elevator is required before the target altitude is hit to avoid overshoot which of the nav_fw_pos_z PID parameters is likely to achieve this ? D seems to be "predictive" so would increasing this significantly work better for a glider that is maybe a bit sluggish changing direction ?

Current settings:

set inav_w_z_baro_p =1.000
set inav_w_z_gps_p = 0.100
set nav_fw_cruise_thr = 1530
set nav_fw_bank_angle = 25
set nav_fw_pitch2thr = 8
set nav_fw_pos_z_p = 50
set nav_fw_pos_z_i = 5
set nav_fw_pos_z_d = 10
set max_angle_inclination_rll = 600
set max_angle_inclination_pit = 600
set roll_rate = 10
set pitch_rate = 14
set yaw_rate = 6
set fw_p_pitch = 12
set fw_i_pitch = 26
set fw_ff_pitch = 119
set fw_p_roll = 14
set fw_i_roll = 30
set fw_ff_roll = 167
set fw_p_yaw = 20
set fw_i_yaw = 40
set fw_ff_yaw = 200
set nav_fw_loiter_radius = 4000

[breadoven]

Finally managed to test increasing nav_fw_pos_z_d and it seems to have improved altitude hold during Poshold significantly. Now seeing variations of around 8m and this was in slightly gusty conditions with rotor turbulence. Ended up with:

set nav_fw_pos_z_p = 30
set nav_fw_pos_z_i = 15
set nav_fw_pos_z_d = 50

Elevator input still lags as before, it seems to be better motor power control that has improved things which perhaps makes sense given Althold uses motor speed changes to control altitude although elevator should still be trying to achieve level pitch.

I had tried an I term of 10 before on a different day with 0 for D but it made no difference seemingly. This time I started with an I term of 20 and a D of 30 and it was better but still varying by 15m. A D of 40 and I reduced to 15 improved things to <10m with a D of 50 making only a little improvement perhaps. A bit more tweaking should get it better still but at least it now isn't climbing almost into a stall followed by a swooping dive.

Just need to work out how to stop it flying kidney shapes rather than circles, guessing due to wind effects.

[isfelixthecat]

Hi breadoven Interesting information - thanks for that. You might have a valid point with regards to the elevator lag. I can't look at mine for the next 3 weeks or so because I am busy with other work but when I can ,I will compare logs and try some different settings.

…

On Tue, Jul 7, 2020 at 8:15 PM breadoven ***@***.***> wrote: Finally managed to test increasing nav_fw_pos_z_d and it seems to have improved altitude hold during Poshold significantly. Now seeing variations of around 8m and this was in slightly gusty conditions with rotor turbulence. Ended up with: set nav_fw_pos_z_p = 30 set nav_fw_pos_z_i = 15 set nav_fw_pos_z_d = 50 Elevator input still lags as before, it seems to be better motor power control that has improved things which perhaps makes sense given Althold uses motor speed changes to control altitude although elevator should still be trying to achieve level pitch. I had tried an I term of 10 before on a different day with 0 for D but it made no difference seemingly. This time I started with an I term of 20 and a D of 30 and it was better but still varying by 15m. A D of 40 and I reduced to 15 improved things to <10m with a D of 50 making only a little improvement perhaps. A bit more tweaking should get it better still but at least it now isn't climbing almost into a stall followed by a swooping dive. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5855 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AP6YD6SOPSGFOFZC2DVH2MTR2LYU7ANCNFSM4N5TF5XQ> .

[breadoven]

Just out of interest I was adding the POS_Z PIDS to the OSD and noticed that the example that appears in the Configurator OSD screen simulation uses values of 20 15 80. So 80 for the D value. Don't know where the example display values come from but the D value is much higher than most of the other recommended settings I've seen.

[isfelixthecat]

Hi. No. A wedge tail eagle grabbed it from above and the aircraft was never seen again. I've seen eagles attacking drones and thought highly unlikely but it does happen. I new it's approximate position but was over heavily timbered country so finding it was rather unlikely.

…

On Fri, 21 Jan 2022, 16:18 Jetrell, ***@***.***> wrote: Just need to work out how to stop it flying kidney shapes rather than circles, guessing due to wind effects. Did you ever get the time to take this further? Both issues are prevalent on every FW I've flow. Your nav_fw_pos_z_p settings noticeably help. Maybe they should be made defaults for FW platforms. — Reply to this email directly, view it on GitHub <#5855 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AP6YD6U3BT6AMICCTPFH37LUXD3DPANCNFSM4N5TF5XQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>