Inav 8.0 RC3 Airplane bumpiness

[kasatka60]

Copied the settings (diff all) from inav 7.1.2 and pasted them into inav 8.0 RC3.
In navigation modes the plane flies unstably.
https://youtu.be/n69w9CDaM8Q
(OSD is a little out of sync)
There is no SD card on board.
Maybe I configured something incorrectly when transferring the settings?
INAV_7.1.2_cli_DOLPHIN_20241215_124916.txt
INAV_8.0.0_cli_DOLPHIN_20241215_150820.txt

[breadoven]

Try adjusting the following settings which may be affected by changes in 8.0:

set nav_fw_pos_z_p = reduce to 30 or lower
set nav_fw_pos_z_i = probably OK as default
set nav_fw_pos_z_d = probably OK as default
set nav_fw_alt_control_response = new setting, could be increased closer to 40

See also #9471.

[kasatka60]

Okay. I'll try to check in a week, weather permitting.

[kasatka60]

It would be nice to add this description when switching from previous versions to the new one.

[kasatka60]

Are these universal settings or do have to select the settings for each aircraft yourself?

[breadoven]

It would be nice to add this description when switching from previous versions to the new one.

Yes, it seems to have been missed and should be added, probably to the Important Changes section @mmosca.

Are these universal settings or do have to select the settings for each aircraft yourself?

Hard to say. I've used the same settings as yourself for PID on a conventional plane and flying wing and not really noticed any pitch instability. I also increased nav_fw_alt_control_response to 50 without issues, just better altitude change response. Others have had bad instability like yourself. It might depend on other setting affecting pitch as discussed in #9471.

[b14ckyy]

Before we merge the changes in #10541 I would really like to see a blackbox log of that flight.
The frequency of the oscillation looks to me like a too high FF on pitch, that can be the result of a bad autotune or too much control surface throw resulting in a stall during autotune. Especially the Dolphin with its swept forward wings is sensitive to that.

I am hesitant to change the altitude PIDs too low as usually no one tunes them afterwards and too soft values can result in issues with WP missions or Autoland.

[breadoven]

Before we merge the changes in #10541 I would really like to see a blackbox log of that flight. The frequency of the oscillation looks to me like a too high FF on pitch, that can be the result of a bad autotune or too much control surface throw resulting in a stall during autotune. Especially the Dolphin with its swept forward wings is sensitive to that.

I am hesitant to change the altitude PIDs too low as usually no one tunes them afterwards and too soft values can result in issues with WP missions or Autoland.

The current altitude PIDS are for altitude control based on position though whereas the altitude control in 8.0 is now based on vertical velocity instead. It uses the same PID controller but with velocity error rather than position error. The basic PID tuning factors:

inav/src/main/navigation/navigation.c

Line 4961 in 4389286

navPidInit(&posControl.pids.fw_alt, (float)pidProfile()->bank_fw.pid[PID_POS_Z].P / 100.0f,

were corrected to take account of this by changing them from 10 to 100. This is based on the technical difference in required values that falls out from switching from position to velocity and also on what seemed to work from testing. The basic tuning factors weren't fine tuned any further. So it's likely the current default PIDs could be better tuned compared to previously. Reducing P fits in with what @Jetrell found from testing and others so it shouldn't be too much of an issue. It would be useful if @kasatka60 could test with lower P values to see if it helps fix the issue in this case confirming this is what's wrong. Is the Dolphin a bit pitch sensitive, seems to be the plane that others have had issues with ?

[kasatka60]

Before we merge the changes in #10541 I would really like to see a blackbox log of that flight. The frequency of the oscillation looks to me like a too high FF on pitch, that can be the result of a bad autotune or too much control surface throw resulting in a stall during autotune. Especially the Dolphin with its swept forward wings is sensitive to that.

I am hesitant to change the altitude PIDs too low as usually no one tunes them afterwards and too soft values can result in issues with WP missions or Autoland.

Inav 7.1.2
set fw_p_pitch = 15
set fw_i_pitch = 5
set fw_d_pitch = 5
set fw_ff_pitch = 231
Flight on version 7.1.2. No problems with pitch.
https://youtu.be/BA9YSCzN8ro (no osd)
I'll try to fly with the black box this weekend. Weather permitting.

[b14ckyy]

Alright guys in this case lets see the blackbox and @kasatka60 ideally you fly with current values one more time, then with the changed values as breadoven said. Just to 100% exclude any PIDFF tuning issue. Its the fast oscillation in your clip above that throws be off a bit. Especially as no one else noted that issue so far.

If the new defaults for vertical velocity pids work well and don't lack of precision (it would be bad if we have a 5m altitude error that takes 1km to correct), I am fine. I wish I had known about the necessary default changes to do more focus testing beforehand.

[Jetrell]

@kasatka60 Just inquiring. Did this value fw_ff_pitch = 231 come from an Autotune ? I'd be interested to know the setting value you have for pitch_rate. My Dolphin's FF is nothing like that high... What @b14ckyy has said does have validity.. Incorrectly tuned pitch FF and rate will certainly add to the effect.

it would be bad if we have a 5m altitude error that takes 1km to correct

@b14ckyy Lets not loose track of the fact this controller operates on a different method.. No need for the sarcasm. Its disrespectful towards @breadoven's work.
When tuned correctly, It acquires the target more quickly and doesn't experience the same initial altitude overshoot the Z position controller did.

[b14ckyy]

Sorry it was not meant to be sarcastic. Just somewhat exaggerated. I understand that the method needs new values. I just want to mess these defaults up based on a plane that is completely out of tune elsewhere and make it worse for everyone else.

I am all in for good values but they should be flown and tested on at least well autotuned planes. Then we can still tweak them somewhat conservative from there. But they should not cover up a completely messed setup.

[Jetrell]

I am all in for good values but they should be flown and tested on at least well autotuned planes. Then we can still tweak them somewhat conservative from there. But they should not cover up a completely messed setup.

Is that like a pat on the back, then a slap in the face towards Breadoven and myself. In saying we know nothing about testing and tuning aircraft ?
This feature has been around for 12 months before its official public release. I flight tested half a dozen different airframes with it in that time period, through summer and winter, running back to back testing that took weeks of total testing time.. Of which all had there stabilization and nav PID's tuned to the highest level INAV can provide for each model.

And as I said yesterday, among other things.. This controller is more accurate, but this also makes it more sensitive.. Which will also make slight altitude oscillations more obvious on some airframes, that aren't tuned or setup as well.

Not withstanding the dynamic vibration clipping, with its side effect, that was added around the same time as the velocity controllers original commit. That know-one except @ultrazar @breadoven had noticed as a significant issue. #10308
Which is also effecting accelerometer estimation across a wider temperature and vibration (intermittent spike) range. That INAVs minimal logging rate often misses.

[kasatka60]

@kasatka60 Just inquiring. Did this value come from an Autotune ?

Values ​​obtained as a result of autotune.

[Jetrell]

Thanks @kasatka60
The pitch feedforward on my two Dolphins are 90 and 110. Derived from autotune...
But our control throws would have to be different, as would have been the airspeed/throttle the autotune was conducted at, to see such a large difference between our two settings.

Being that autotune can set such a drastic difference in feedforward and likely rates too, on the same model, is interesting to see. That would mean any small oscillations from over tune of the nav_fw_vel_z controller gain, would be essentially increased by the stabilization controller with a less than optimal feedforward and rate tune.

[b14ckyy]

Is that like a pat on the back, then a slap in the face towards Breadoven and myself. In saying we know nothing about testing and tuning aircraft ?

Mate you are interpreting too much into here. I am talking about the Setup of the poster that apparently has a completely out of tune setup. Such a case should not be the reference.

So my question here is, if not answered already. Have all your tests in the last 12 months been stable and precise on the current defaults or did you have to reduce them to values close to here: #10541 ?

The main reason why I wanna know that is, because for years we set nav_fw_pos_z_p based on the old controller type to 25 for Fixed wing without a tail and 35 for fixed wing with elevator.
So if you tell me that the new default would work great for both plane types in the new velocity control, then we also need to remove that part from the defaults presets and stick with the firmware defaults.

The bigger problem is also, that everyone who Upgrades from 7.1 with a diff, will keep the values from the old preset, even if you change the firmware defaults. As a result, imho this parameter should have been renamed to nav_fw_vel_z_p in the first place if it is important, as this might cause a lot of questions or issue feedback from users.

PS: I skipped through the video posted above. I can't tell for sure what FM was active most of the time but I see possibly a lot of flying in Angle mode and a swinging pitch axis. So after pitch changes the plane waves up and down a few times and then settles. This is an indicator of a overtuned FF. Can only say for sure with the logs.

I had that phenomenon myself especially on my Dart250 since a speed stall due to angle of attack from strong pitch authority can sometimes be unnoticed on a swept forward. So the control output is high but the actual resulting pitch rate stays low in that stall situation. This tunes rates too low and FF too high resulting in what we see.

[Jetrell]

Mate you are interpreting too much into here.

Fair enough.. I just figured you would have read about it all. There is plenty of conversation between breadoven and myself in that PR.. But you must not have. No problems then 👍

So my question here is, if not answered already. Have all your tests in the last 12 months been stable and precise on the current defaults or did you have to reduce them to values close to here: #10541 ?

Many things changed over the year, as we become more aware of possible causes. That was why its merge was held off for so long.
But the answer to your question is yes to it all.. I couldn't have flown my test planes like that in other 8.0 development tests, without lowering the velocity P gain.
Breadoven also made a change in another PR, that altered its P and I correction factor. Which had a noticeable effect on the way nav_fw_alt_control_response worked.. But the P-gain still required lowering.

[b14ckyy]

@mmosca OK mate I think based on Jetrells report and based on the fact that I also had no issues in my tests with the Configurator preset values of 25 and 35 (the new default would be in the middle) on 5 different planes, I think we can merge the default value change in #10541

I will also remove that value from the presets in configurator. We should add a Upgrade note to the release notes that in case of Oscillation issues, the pilot should reduce that value. Alternatively we rename it as mentioned above?

[breadoven]

You're right that adding new nav_fw_vel_z_pid settings would have been the better way to go but I was surprised how much work was needed to make this change so laziness got the better of me and so instead it was decided to leave it as was and work on the basis that the basic PID tuning factors mentioned above could be adjusted so the existing PID settings for nav_fw_pos_z_pid would work OK without retuning. As far as users are concerned these settings affect altitude control which is essentially position control whether it's done using position or velocity derived from position. The old method did control vertical velocity also even though it was using position derived from velocity to do it so that wasn't entirely technically correct either.

And don't forget that if you add nav_fw_vel_z_pid it will have to be retuned anyway so the only benefit would be that it highlights the change and the possible need to retune.

I don't think this is too big an issue so long as people are aware the PID settings might need adjusting if copied across from a previous version.

[b14ckyy]

Fair enough. In the end only No-Tail Planes are 5 points above firmware default after the change and I guess in most cases it won't even be a problem if the plane is overall tuned well. Planes with tail are 5 points below FW default. I edit the preset, add a note to the release notes and we are good to go.

And for the @kasatka60: When you fly your dolphin again to create a blackbox log, reduce the FF value for pitch to 160 (just a guess on my end based on past experiences) for the second flight and see if its better. We can then compare the logs with your current values and with reduced FF to see if the tune gets better.

[kasatka60]

PS: I skipped through the video posted above. I can't tell for sure what FM was active most of the time but I see possibly a lot of flying in Angle mode and a swinging pitch axis.

I spent most of my time flying on cruis mode.

[b14ckyy]

Good to know, so the bumpiness shown above was just occasionally then? Probably after a "harsh" correction?

[kasatka60]

I haven't adjusted anything yet. I transferred the diff settings.

[kasatka60]

I ordered a memory card. I'll try flying in rain and snow and write down the logs. Just don't swear.

[kasatka60]

https://youtu.be/_tjXIUEi-Bk
diff 1.txt
1.TXT

[kasatka60]

https://youtu.be/1YGIyu9Bsqc
diff 2.txt
2.TXT

[kasatka60]

https://youtu.be/xAGBW0SVRAU
diff 3.txt
3.TXT

[breadoven]

OK so reducing P to 30 doesn't fix the issue. Also I assume the 3rd test was using a nav_fw_pos_z_p of 40 which appeared to initially delay the onset of instability in CRUZ which isn't what you might expect. Unfortunately I can't open any of the log files, they all appear corrupted so it's not possible to understand the PID behaviour.

I did notice though that you have fw_d_pitch = 5 whereas I have it always set to the default of 0. Don't know if this makes much of a difference. You'd think it might help damp the oscillation but maybe not, D seems a little unpredictable sometimes.

And a value for FF of 160 still seems a little high perhaps. The defaults are 70 for a wing without a tail and only 50 for the general setting.

[kasatka60]

I'll try to flash the firmware again and set it up again. After all, others fly fine, but I'm the only one with glitches.

[kasatka60]

And a value for FF of 160 still seems a little high perhaps. The defaults are 70 for a wing without a tail and only 50 for the general setting.

Maybe I'm not using autotune correctly?

[Jetrell]

@kasatka60 You have the logging rate at 50%.. You won't get the F405SE to log reliably above 13%. Especially with blackbox SERVOS enabled.
I'm surprised your rates are so low.. Are you applying full stick deflection in the autotune process.

If you want a comparison. These are the tunes on one of my Dolphins... With my other Dolphins tune, not being much different.

fw_ff_pitch = 90
pitch_rate = 12

fw_ff_roll = 37
roll_rate = 29

[kasatka60]

You have the logging rate at 50%..

These are the default settings.

[Jetrell]

These are the default settings.

Yeah. Unfortunately SPI card logging experiences issue when logging above 13%.. And even more so with many F405 controllers, especially when more demanding tasks are placed on the controller.
e.g. Many OSD elements are selected, Programming frame work is used heavily. And multiple Control profiles are used.

[kasatka60]

I'll try to fly tomorrow. Maybe the black box will record logs normally.

[kasatka60]

for F722 what black box settings should be set?

[b14ckyy]

3% (30Hz) would already be enough for this. But do not go above 50% (500Hz)
To be sure we get precise reaction measurements, I suggest 20% log rate that should be fine.

[kasatka60]

Have a nice day everyone

[kasatka60]

https://youtu.be/4Bdrkk84Qig
diff 4.txt
4.TXT
The logs seem to be correct.

[kasatka60]

Autotune sets high ff values ​​and that's why there are problems

[MrD-RC]

Depending on physical setup. FF below 200 is fine. It could also be how the autotune was performed.

[kasatka60]

Next weekend I'll try to fly with these parameters:
fw_ff_pitch = 90
pitch_rate = 12

fw_ff_roll = 37
roll_rate = 29

[kasatka60]

Depending on physical setup. FF below 200 is fine. It could also be how the autotune was performed.

If I understand correctly, because of the large value ff, the plane flies incorrectly

[kasatka60]

I'll try to install inav 8 on z-84 and reptile 1100 (There is also T1 vtol)

[MrD-RC]

Depending on physical setup. FF below 200 is fine. It could also be how the autotune was performed.

If I understand correctly, because of the large value ff, the plane flies incorrectly

If the plane was autotuned correctly. The rates and FF should be correct for your plane's setup. It would be based on the physical throws of your individual aircraft.

[kasatka60]

Why does the 8 inava fly so crookedly? inav 7 flew perfectly.

[Jetrell]

Next weekend I'll try to fly with these parameters:
fw_ff_pitch = 90
pitch_rate = 12

fw_ff_roll = 37
roll_rate = 29

Just a quick reply.. I looked at your video. But haven't had the time to look at the log.

From the way you did the autotune. It was either the control surfaces have very little throws. Or you weren't moving the stick to full for long enough. So it wasn't providing autotune a good snap shot.
Ideally. If you want to provide the best absolute rate of rotation for each axis. You should push full stick, and complete a full barrel roll, both left and right.. And then do the same for pitch, by completing a full loop.. And doing this while maintaining a relatively constant speed.

Why does the 8 inava fly so crookedly? inav 7 flew perfectly.

The velocity z controller that INAV 8 uses works differently to what INAV 7 used. Meaning the nav_fw_pos_z_p gain needs to be reduced.
Specifically on my Dolphins. I had it set to 32 in summer and 25 in winter... The temperature variance in the tune is related to another issue.

If I understand correctly, because of the large value ff, the plane flies incorrectly

I spoke to you about how the two are tied together in the lower part of this post. #10536 (comment)

[kasatka60]

I will try to follow your advice.

I remembered. There is a tab Adjustments. I will try to select the values ​​of nav_fw_pos_z_p during the flight

From the way you did the autotune. It was either the control surfaces have very little throws. Or you weren't moving the stick to full for long enough. So it wasn't providing autotune a good snap shot.

For autotun, is it correct to make full turns on both axes?

[jaroszmm]

Hey, I believe we've met on FB Inav page.
I have similar issues with my Altus. It was flying well on 7.1.2. When I tried RC2 recently I noticed in cruise mode a lot of oscillations. The moment I switch into angle all is fine.
I'm pretty sure for the plane that it was solid on INAV 7. Also redoing autotune in flight with RC2 creates minor FF changes (like by a 5 or 6 tops) so for me it seems there is something fishy here.
But to be even more "helpful" I tried today RC2 on Swordfish, which was solid on 7.2.1 and had zero issues in cruise mode there.

Altus is at the moment back on 7.1.2 hoping for a short flight tomorrow to see if it's solid on that FW.

[kasatka60]

As everyone here recommends: you need to reduce the value of nav_fw_pos_z_p.
They also recommend resetting the PIDFF settings.

[jaroszmm]

I flew RC2 on both "stock" and recommended by Marc changes on some values. They didn't change anything.
I can reset the PIDFF if this can make some improvements

[kasatka60]

https://youtu.be/4Bdrkk84Qig
If you notice, before autotune the plane to fly relatively well in cruise mode
set nav_fw_pos_z_p = 35
set fw_p_pitch = 15
set fw_i_pitch = 5
set fw_d_pitch = 5
set fw_ff_pitch = 70
set fw_p_roll = 15
set fw_i_roll = 3
set fw_d_roll = 7
set fw_ff_roll = 50
But they recommend 25-30 for nav_fw_pos_z_p.
I'll be playing with the nav_fw_pos_z_p values ​​this weekend.

[Jetrell]

@kasatka60 @jaroszmm There is also another setting related to the Z velocity controller called nav_fw_alt_control_response.
Its not in the Adjustments tab.. But is in the CMS altitude pids, called fw alt response.

Decreasing its value can help prevent altitude target overshoot or oscillations around the target, which may occur on some airframes, if you happen to have nav_fw_auto_climb_rate somewhat higher than default.

If these don't stop it. Which is slightly below what I used at 3C in my winter. Then its another issue that is also adding to this problem.
nav_fw_pos_z_p = 25
nav_fw_pos_z_i = 11
nav_fw_alt_control_response = 15

[helicocrasher]

@Jetrell
Concerning the conversation on Discord. Altitude issues.
The flight in the links was a short test flight, at about 1°C with upcoming snow and low clouds.
Main objective - check the GPS number of sats.

Video: time refers to flight timer in te OSD
00:07 Autolaunch ends. OSD Alt says 1m ag (baro 20m) - rather short autolaunch I might have touched the stick,
00:41 RTH manually engaged (RTH target alt 120m) ... not really climbing a lot OSD altitude stays at 0m until 01:09
01:22 RTH finally increases trottle 71% 10.8A
01:25 OSD speed shows 7km/h way too low
01:29 OSD altitude drops from 88 to 63m instantaneously
01:32 OSD altitude drops jumps to 99m
..
02:22 RTH terminated manually --> Loiter in the meantime OSD altitude has dropped to 84m (why not 120m)
02:35 manual motor stop to loose altitude and get out of the clouds (perceived altitude feels higher than 84m - baro says 110m)

Link to the DVR footage: https://youtu.be/FUuB_qc4uIg?si=MtJhDsLLcegm-Ehv
Link to BB log: https://www.dropbox.com/scl/fi/rprzj8anmlpinm48h0tvi/blackbox_log_2024-12-23_190429.TXT?rlkey=ivjjfpqzo62yfqjel8n1v0ayn&st=4823qmd0&dl=0
Link to diff all file: https://www.dropbox.com/scl/fi/8v7k0wt01jmkks0k6xcdj/ArWing_P_B2_8.0rc3.txt?rlkey=qz6i58nyecw6a11smmpgpmlc0&st=cfu0ltx4&dl=0

[jaroszmm]

LOG00001.TXT
This is a short LOG from my yesterday flight.
It was on 8.0 with diff all from 7.1.2 and already I've changed
set nav_fw_pos_z_p = 30
set nav_fw_alt_control_response = 40

Before that I was using default values that either came with 8 or were already in 7 (don't know if they are in DIFF but I guess not) and it was ALSO pitching up and down.

I want now to fly again on 7 just to make absolutely sure it is fine on 7.
What could I do next? Reset PID controller for default FF and rates and do autotune on 8 RC3 again? So like go from scratch on RC3 and if it doesn't help what else should I change with CLI?

[breadoven]

The main problem here seems to be related to the position estimations which, looking at the @helicocrasher log in particular, are inconsistent with the sensor data for the Baro, GPS and Accelerometer. There's pretty poor correlation between the Baro and the GPS altitudes and the estimated position and vertical velocity.

e.g. between 1:05 and 1:25 in the above log file:
Baro increases from 29 to 59 m, or 30m
GPS increases from 657 to 674m, only 17m ... almost half the Baro change
Estimated position increases from -11 to 2.3m, only 13.3m
Vertical velocity is all over the place.

Then there's a major glitch at 1:45 when the Position suddenly drops by 26+ meters seemingly because the vertical velocity plummets even though this is contradicted by both the Baro and GPS altitudes which actually increase. Although the vertical acceleration at this point decreases which would correspond with a drop. 3s later the opposite happens and position shoots back up. This may have been caused by the GPS vertical velocity decreasing even though the altitude seemed to keep increasing. Can't tell from the video if this occurred during a stall, didn't look like it and attitude says not but the speed was very low.

I guess the problem is which sensors do you believe.

One thing to try is to change inav_default_alt_sensor to GPS_ONLY to only use the GPS for altitude estimations or BARO_ONLY to only use the Baro. Also try setting inav_w_z_baro_v and inav_w_z_gps_v to 0 to stop vertical velocity taken from these 2 sensors from affecting the overall vertical velocity estimation.

[jaroszmm]

The idea of Baro having issues and messing actually starts to make sense.
I've just looked at my DVRs from two planes on INAV 8.
The one having issues also has some weird stuff on osd, like after powering up there is no altitude reading on OSD for a short while before it suddenly appears.
Also while landing I levelled at around 2 or 3m altitude but OSD shows altitude frozen at 1m.

While on Swordfish that flew okay with 8.0 RC2 I get altitude on OSD instantly and it shows pretty accurate values.

The boards are Speedybee 405Mini Wing (the bumpy plane) and Matek 405WMN (the solid one)