Hi, I’m trying to run Ardupilot’s Copter 4.5.6 on Beta Pavo20 Pro quad (see Pavo Pico Brushless Whoop Quadcopter - #13 by _sobi), but I’m having issue with tuning of Altidude Hold mode.
Estimated altitude in CTUN grapsh is way away from real altitude at the beginning, baro altitude is close to real altitude of vehicle a bit off when in ground effect. Vibrations graph seems to be OK.
One of the consequences is that I’m not able to take-off in Altitude Hold mode as the vehicle “thinks” that it’s somewhere up at that time.
Can anybody point me, what’s the problem?
Link to log of short hovering flight: 2024-10-03 12-27-24-altitude estimation issue.bin - Google Drive
I also notice you have the notch filter set to fixed, but you have Dshot ESC with telemetry. You should be able to improve the filtering by using a RPM based filter.
I usually use the Stabilize mode to check the first flight, if okay, I switch to Test Alt-hold middle of stabilize flight to let the algorithm learn the right propulsion.
Curious what type of battery are you using?
Double check your motor order too.
MOT_HOVER_LEARN,0 # change to 2, learn
MOT_THST_HOVER,0.1788078 # probably too low for your UA
MOT_BAT_VOLT_MAX,12.6 # unusual voltage range.
MOT_BAT_VOLT_MIN,9.9
FRAME_CLASS,1
FRAME_TYPE,1
SERVO1_FUNCTION,34 # 34 = M2, double check your motor order
SERVO2_FUNCTION,35
SERVO3_FUNCTION,36
SERVO4_FUNCTION,33
Firstly - thaks for all the answers.
To make it clear - we are talking about this quad: Pavo20 Pro Brushless Whoop Quadcopter – BETAFPV Hobby and I have no problem with flying this quad in STABILIZE mode, but there must be something wrong with calculated altitude estimate, but I have no idea what’s the issue yet.
@Jai.GAY Hover throttle with value about 0.17 is correct, value is from logs analysis and also MOT_HOVER_LEAN calculated similar value That’s why I’ve turned off MOT_HOVER_LEARN.
Battery I’m using is 550mAh 3S 75C BetaFPV Lava battery, that’s why max. voltage is set to 12.6V and min. voltage is set to value that will not cause failsafe for now.
I had to reconfigure motor order from default settings of BETAFPV-F405 target/board to fix the order for this FC F4 2-3S 20A AIO FC V1 – BETAFPV Hobby,
Original target is for board BETAFPV F4 1S 12A AIO V3 — Copter documentation, but BetaFPV Pavo20 Pro contains F4 2-3S 20A AIO FC v1. That’s why servo1 starts with pin 34.
X-frame type is correct too as the quad is perfect square :).
@dkemxr what do you mean by take a look at motor ranges? Values I have seems to work for me…
@Allister I’ve updated values of PSC_ACCZ_I and PSC_ACCZ_P, I’m attaching log from new indoor hovering flight. As I’ve expected - change of these values had no influence on wrong altitude estimate - see
Actually the estimated value is pretty strange - it looks to me that it’s always reset when reached some sort of max value. pavo20pro-betafpv405-4.5.6-241005.param (18.8 KB)
As soon as the motors start spinning there’s a pressure increase (alt-drop) showing on the barometer. Likewise when the motors stop the altitude comes back up.
Is there a way you can get a bit of foam to cover the barometer chip and maybe stabilize the airflow over the barometer? I’m just wondering if this is an airflow issue, not a setting issue.
Allister, actually I’ve already did so, but the difference between with or without foam is not significant. The frame is so small, that this behavior cannot be easily changed.
I think that MOT_HOVER_LEARN should be left at the default. I really don’t think it’s going to help to disable this.
if you could put little legs on the vehicle that would likely help reduce the interference on the barometer. Also if you just give it a bit of time (perhaps 30sec) after taking off before switching the AltHold (or Loiter, etc) it should settle down.
Thanks Randy @rmackay9 , I’ll try to attach some legs to Pavo. And I’ve also noticed that after some time, especially when flying outside with GPS, the estimated altitude value is getting closer and closer to real altitude as you wrote.
Anyways, I’m wondering why is the altitude estimate in the start of flight so much away - e.g. 100 meters, especially when flying indoors. Couldn’t be this caused by wrong EKF3 configuration or some kind of issue with IMU?
I’m trying to understand how EKF3 works for altitude estimate - Extended Kalman Filter Navigation Overview and Tuning — Dev documentation) - and one of things, that is connected to baro sensor I’ve found is EKF3.IPD - Innovations on the barometer height graph. According to documentation, the error is normal in range of few meters, but not 100 meters as I get.
Are you sure, that such a big error can be caused by ground effect when quad is taking-off? Why is the altitude error reset after some time and then it rises again?
The IMU values look a little suspicious. Normally gravity is 9.81m/s/s but in the logs it looks more like 11. The vehicle is probably not accelerating up at 1m/s/s (or else it must be climbing very very quickly after a few seconds) so perhaps something went wrong during the accel calibration.
Another possibility is very high vibration although I don’t see that in the vibe logs. Considering the size of the frame though I would expect higher vibration levels so this is also suspicious.
One more possibility is that the EKF is learning a bad accelerometer offset for some reason.
I see that AHRS_ORIENTATION = 8 (roll180) but perhaps the accelerometer calibration was not re-done after changing this parameter? Not sure of course, just an idea.
@rmackay9, you’re right that there must be something wrong with accel for Z axis - I’ve checked/graphed other my logs and yes - the ACCZ values are very strange. I’ve redone IMU calibration, but it didn’t help - the average value in logs is always around -11 instead of -9.81…
Today I had crash after I’ve engaged AltHold mode maybe after 20 seconds after take-off in stabilize mode - the quad felt down like an apple from apple tree. The logs shows that EKF3 estimate was that quad is about 50 meters higher at that time than it was in reality - so it turned off throttle. Even while quad was falling down, the estimated altitude was rising.
It’s very unpleasant behavior and I still don’t know how to fix it. Could be using of DCM instead of EKF3 workaround for this type of issue? Is it even possible with AC4.5?
If an accel calibration didn’t fix the problem then I think replacing the autopilot is probably the best idea. You could try a full parameter reset but I suspect that won’t resolve the problem.
Well, I didn’t give up and tried other different things but unfortunately I was not able to use on-board IMU.
Workaround for me is use of “external” IMU" - I’ve used module from an older gimbal with MPU6050 and I’ve connected it via I2C interface.
Short video of final setup when hovering in Loiter mode in moderate wind:
Updated Copter-4.5.6 code if anyone will try to run Ardupilot on Pavo20 Pro quad with F4 2-3S 20A AIO FC V1 Commits · mariansoban/ardupilot · GitHub . Only thing I would do different way would be use of I2C1 instead of I2C2/USART3 like I did because of a bit tricky soldering and necessity to disable internal ELRS receiver. Pads for I2C1 are populated on board, but not documented on FC page F4 2-3S 20A AIO FC V1 – BETAFPV Hobby. I’ve used SDA of I2C1 for switching of LED strip, that was connected to TX of USART6 before.
Thanks to everybody who tried to help me!
