MS5611 throttle oscillations

[andrejpodzimek]

An ancient bug about altitude hold throttle oscillations has been closed, but it looks like the problem still persists. At least I'm seeing it on this aircraft running yesterday's master. Switching to baro mode causes fast throttle oscillations (~2Hz I'd say) that tend to be severe enough to activate my battery alarm even with an almost full battery. Should I try to increase d_alt or decrease p_alt? The (default) settings that I'm using at the moment:

baro_bustype = I2C
baro_spi_device = 0
baro_i2c_device = 1
baro_i2c_address = 119
baro_hardware = MS5611
baro_tab_size = 21
baro_noise_lpf = 600
baro_cf_vel = 985
baro_cf_alt = 965
fixedwing_althold_reversed = OFF
alt_hold_deadband = 40
alt_hold_fast_change = ON
p_alt = 50
i_alt = 0
d_alt = 0

I hypothesized that the sound of the propellers could resonate with the barometer and throttle changes could feed back into the control loop, but surrounding the barometer with a thick layer of foam doesn't help; I'm still getting throttle oscillations so strong that the altitude hold mode is basically unusable. Tuning recommendations would be very helpful. (And maybe some of them should become defaults.)

(I'd be very interested to try how iNav handles altitude hold, but my attempts to run it haven't progressed much thus far.)

[andrejpodzimek]

iNavFlight/inav#4 is the only bit of information on the current defaults that I could find.

[andrejpodzimek]

A small (albeit pessimistic) update: I've just tried the following:

set p_alt = 50
set i_alt = 15
set d_alt = 25

But I have the impression that things got worse. Here's a video with 4 attempts to switch baro hold on:

It behaves exactly the same way on both aircraft I tried it on (F4 on the left, F7 on the right; the video is from the F7 with the RunCam Split).

What's the next step here? Should I try e.g. set p_alt = 0 and only keep the I-term and D-term? Or should I just set the P-term to something much smaller than 50? Last time I tried it with unchanged default altitude PIDs and the oscillation was much more intense and at a lower frequency. The baros are under foam on both aircraft.

[noviuk]

Betaflight 3.2.2
SP F3 clone
Had the same issue. Solved by changing P to 0, and increasing I to 15 with D to something like 10.
1st tests show that there is no more oscilation.
2nd tests show that there in no altitude hold. its or descends or ascends.
Edit:
changed ALT PID back to original 50 ; 0 ; 0
and then changed VEL PID to 50 ; 5 ; 30
no oscilation and altitude hold works fine.
tho still need some tweaks because there is some werid behavior when i lower the throttle.

[andrejpodzimek]

@noviuk Thanks for the update! That's a very interesting finding. I'll test it ASAP.

However, at the first glance, I find it really puzzling that the velocity PID can have an impact on the stability of the altitude PID. I would expect the velocity PID to only come into play in GPS hold mode (and I never got that far in Betaflight due to severe magnetometer calibration issues and GPS issues). What I have been trying was only altitude hold, without GPS or anything that could possibly be related to velocity. If the velocity PID can indeed resolve the altitude PID oscillation problems, that definitely sounds like a bug. Using altitude hold without GPS should have nothing in common with the velocity PID, because there's no notion of velocity in that mode (and the drone may not even have a GPS installed).

As for the response to throttle in altitude hold mode, I already filed a bug for that: #3824 The problem is (at least in my case) that leaving the throttle steady appears to engage altitude hold, but moving it a little bit causes the FC to switch (for a moment, perhaps 1 second or so) back to direct throttle input, which may be quite a sudden and surprising change. All the DJI-style and Hubsan-style drones use the throttle as a derivative of altitude while in altitude hold mode, i.e., centering it means a derivative equal to 0 (keep the same altitude) and minimum or maximum throttle yield the maximum rate of descent or climb, respectively. This makes the throttle response of Betaflight in altitude hold mode somewhat counter-intuitive.

(Admittedly, centering the throttle wouldn't be easy on a common transmitter, because it doesn't have a spring-loaded throttle stick. So one may need to configure a switch to center it and/or create a large dead zone activated by a switch. Both should be easy to set up in Deviation (which I use) or OpenTX.)

[dave-patterson-bristol]

I'm interested to see how the range finder support coming in 3.3 works in relation to this issue. I've got an indoor area with a tether to safely test behaviour. The lightweight lidar modules are supposed to be very reliable and I've got bluetooth MSP to track the sensor in flight. I'll run some tests this weekend and report back.

[stale]

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[stale]

Automatically closing as inactive.

[andrejpodzimek]

@noviuk I've tested the recommended settings on 3 different builds and I can confirm that the following indeed works without strong oscillations:

• ALT PID 50, 0, 0
• VEL PID 50, 5, 30

However, baro hold is still next to unusable in Betaflight due to #3824. Basically there are severe issues with the throttle channel interpretation that make the baro hold cruising experience painful.

There seems to be a large deadband around the throttle position at the moment the baro hold gets activated and moving the throttle outside the deadband instantly sets throttle to that particular position (instead of something relative to the automatic stable hold position). And that in turn only lasts for a short while; the baro control over throttle resumes after a few seconds. This means that the baro hold works, to a limited extent, but there's simply no way to use it for climbing or descending in a graceful semi-automated way.

To get at least stable baro hold cruising without the need to worry about moving the throttle while applying yaw, I set up a switch that blocks my throttle at exactly 50%, regardless the stick position. I assumed that the baro hold would eventually kick in once it gets activated, but it only really worked on one of the 3 builds while the other ones ended up with throttle positions so surprising that I had to deactivate the mode quickly.

All in all, it would be nice if the baro hold had more of a DJI-style or Hubsan-style behavior.