Either the climb rate is wrong or I need explanations on it

ArduCopter Copter 4.0
1

The climb rate does not correspond to the vertical speed, is it a bug ? Am I dumb ? or did I misunderstood it ?

In this log you can see that the climb rate (CRt) does not follow the slope of the altitude (Alt) :

image
image2135×1188 172 KB

https://drive.google.com/file/d/1YsDk0q3tD0W1t3feBvZ1WuLQcG8JFNg5/view?usp=sharing

Because of this I’m struggling to tune AltHold, I don’t understand what’s happening in the PIDs. The climb rate PID is 100% fine : Desired Clim Rate is realy close to the Climb Rate. But the climb rate does not translate to an increase in altitude. I think that’s why AltHold is not working well. What am I missing here ?

I followed the tuning process here and here. AltHold has been working fine (after much effort) until today when I added the GPS, but after checking previous logs the climb rate was already “wrong” before and I had already added weight to the copter before. So, it does not come from the additional weight of the GPS. I don’t think it comes from some new GPS vibrations either because VibeXYZ is low at 2.

Also, mot_hover_learn was set to 2, it had time to converge before this log and I changed PSC_ACCZ_I and _P accordingly.

Also I’m flying a Single-Copter, but I don’t think that’s relevant.

Anyway, is there is problem with the climb rate ? or am I the problem ?

2

If you’re not in danger of a fly-away then you can set ATC_THR_MIX_MAN to 0.5 - you probably need to with only one prop to do all the work.
Wondering if INS_ACCEL_FILTER is too low? Although it probably wont make much difference to Alt tuning.
You have PILOT_SPEED_UP,100 but it’s more commonly 250 (in multirotors) - not sure if that’s an issue or a desired/tuned setting.

3

I’ll try ATC_THR_MIX_MAN=0.5, I don’t think it will apply in stabilize mode, so if I’ve a problem in AltHold I’ll then safely land in Stabilize. It may help AltHold but it doesn’t explain the “wrong” DCRt.

Yeah I may have forgot to switch back INS_ACCEL_FILTER=13 to its original value one time. Tuning instructions say between 10Hz and 20Hz so I’ll use 20Hz.
And yes PILOT_SPEED_UP is what I want. It doesn’t affect the control loop, it’s just the input desired climb rate when I go full/no throttle in AltHold.

4

@xfacta thanks for your inputs but nothing changed. ATC_THR_MIX_MAN just made the ATTitude control sluggish.

Small things :

  • I enabled the batch sampler to check the FFTs of the flights, and no new vibrations were added with the GPS.

  • It seems like the motor is a bit hotter than usual. I think it comes from the throttle that is not stable like before.

  • I tried PSC_POSZ_P = 1,2, and 2.5, nothing really changed (2.5 looked a bit better but nothing huge). I tried PSC_VELZ_P = 2 instead of 5, as espected oscillation were worse when changing altitude.

  • I noticed oscillations on the Yaw, but those are (I think) due to the thrust that oscillates and not a bad IMU. On a Single Copter, if the thrust changes, it’s changes the airflow on the flaps thus the flaps have less control on the whole system and the PID should find the new equilibrium.

Big findings :

There are 3 weird things happening, maybe linked to the baro :

  • Climb rate is not the derivative of Alt
  • Alt (from the EKF) “lags behind” or do not correspond to Baro Alt
  • Climb rate is the derivative of Baro Alt

image
image2146×1294 192 KB

Here you can see that CRt is much closer to a smooth derivative of BAlt than the derivative of Alt. (hypothesis) For some reason the CRt algorithm relies much more BAlt that the Alt algorithm, thus CRt is not the derivative of Alt. This leads to problems in AltHold because it uses both.

Now we can search why the Baro Alt is different from the Alt estimated by the EKF. BUT this is not the root of the problem, the problem is that CRt is the smooth derivative BaroAlt and not Alt. Bringing BaroAlt closer to Alt is just a way to bypass the problem.

  • It’s possible that there is a problem on the IMUs, this fools the EKF short term estimation, but the long term estimation converges to BaroAlt. This will result in Alt lagging behind BaroAlt.
    • This is unlikely because I’ve 2 IMUs, I think an error will occur if one was behaving strangely (IDK how to check that, I only have one IMU in my log)
    • It can come from vibrations, but I’ve (very) low vibrations, I’ve set the notch filter and looked at the FFTs today.
  • There could be a problem with the baro. The airflow could change its value, and the EKF not seeing an upward acceleration will take some time to converge to the BaroAlt value. If the propeller spins faster, the pressure goes down above the prop (and on the board), creating a feedback loop that makes CRt converge faster toward DCRt.
    • On one hand, this is likely because the board is 10cm above the single propeller
    • On the other hand, the thrust doesn’t change that much
      image
      image2126×1302 257 KB

      The log shows a small correlation between thrust and CRt but I’m not 100% sure it comes from the change in pressure, because more thrust increases the real CRt.

Any idea on where does it realy come from ? How to fix it ?
Is there a way to make CRt closer to d(Alt)/dt and not use BAlt that much for the estimation ?

5

Here is a log of this morning last flight : https://drive.google.com/file/d/17XbAE_H4uR0ZQs2MUP52LD4kP0LP76i-/view?usp=sharing

And a video of it : https://youtu.be/Zpmfms2aBGQ

6

I disabled the GPS … and it worked better. I did it with EK2_GPS_TYPE=3. I’m not sure the GPS is the cause, maybe charging the battery changed something or it’s just luck.

image
image2168×1206 155 KB

However the weird CRt BAlt and Alt values are always there.

image
image2106×1195 170 KB

CRt continues to follow BAlt’s slope and not Alt, here it’s quite obvious.
Plus the thrust has two spikes that did not change the barometer value, so the thrust changing the pressure did not happened here.

7

I’ve also re-leved the copter before this flight. But it was not too far off level.

8

Ok, I got it guys. It comes from the EKF !

AltHold is not the problem, the CRt and Alt estimations from the EKF are.

For some reason, using the GPS makes the EKF worse. So I used EK2_GPS_TYPE=1 to only use 2D GPS and not use the altitude from the GPS (I’ll fix the GPS fusion later).

I switched EK2_ALT_M_NSE=3 to EK2_ALT_M_NSE=1, so the EKF uses more of the baro and it was nice (IDK why it was on 3, the default is 1). Using 0.5 created some clear and fast oscillations, using 5 worsen the phenomenon described all above.

The strange thing is that I’ve also lowered EK2_ACC_P_NSE=0.6 to EK2_ACC_P_NSE=0.1, thus making the accelerometer more important. This improved the EKF further.

So I increased the importance of both the accelero and baro (without GPS), and now the EKF is better ? ¯_(ツ)_/¯ that’s weird but I’m not a pro in Kalman Filter.

Anyway, after those tweaks, CRt is much closer to d(Alt)/dt. You can see that in NKF1/ VD & dPD. VD is the vertical speed from the EKF (this is also CRt) and dPD is the derivative of the altitude from the EKF (this is also d(Alt)/dt ).

This is VD & dPD with the latest settings, they are close to each other :

image
image1033×481 11.7 KB

This is from one of the first log/flight, VD is awfully wrong :

image
image1013×479 11.5 KB

My question is then : Why not use dPD in AltHold for the climb rate instead of VD ? Because as seen here a difference between the two fucks with the PID.

I also don’t know why such a huge difference between VP and dPD was present, maybe it’s only me but it could lead to poor AltHold performances for many other.

1 Like
9

With the GPS, the poor performances were due to a bad GPS setup on the Navio2 board. I fixed the issue with Navio.
Without GPS this could be because the EKF is not made to not have a GPS. So some tweaks of the gains are necessary for a better estimation.