Discrepancy between EKF altitude and barometric altitude in AltHold

Hi Folks,

My copter is behaving strangely in AltHold Mode, when I try to take off slowly in AltHold, after an initial hop it looses altitude again and sometimes even touches the ground.

I did 3 test flights today and the ‘achieved altitude’ (CTUN.Alt) doesn’t really follow the barometric altitude (CTUN.BAlt) but is closer to the desired altitude (CTUN.DAlt). From what I can tell, the barometric altitude matches what the drone was actually doing during the flights (that includes touching the ground in the third flight). These are the graphs from the 3 test flights I was talking about:

I checked for vibrations in Mission Planner, they are mostly below 10 with a spike above 15 where I grabbed the drone from the air in the end.

I checked for vibrations in the Filter Review tool, that looks good as well.

I feel like I am overlooking something trivial but I cannot wrap my head around.

These are the three flight logs:
flight log 1
flight log 2
flight log 3

The drone in question is the drone from the methodical tuning guide, but with beefier motors and 8-bladed props.

Thank you in advance for looking into this, as long as the drone flies better afterwards I don’t mind feeling stupid.

1 Like

Check EKF height source.
We have same when main vertical pos source was rangefinder.
Also be noted that QGC show not baro alt, but target Alt what is complately stupid.

Yes, I checked that. I should have written that in the main post.
EK3_SRC1/2/3_POSZ is set to 1 (baro).

Is the barometer shielded from rotor wash and direct sunlight?

Yes, the baro is placed on the underside of the FC, between FC and ESC with a bit of open-cell foam covering it. Also the drone has duct-like prop guards so there’s not much prop wash towards the baro anyway.

Hi @Janno,

The EKF’s altitude (shown in CTUN.Alt) is a combination of the IMU’s accelerometer values and the barometer so either ground effects (air pressure disturbances near the ground) or vibration affecting the IMUs can cause problems.

As you say the vibration levels are relatively low so I think it has to be the ground effect.

Thank you all for your answers.

I did another test flight, this time basically outside, the area is open to three sides and has a roof that’s about 6 meters high. Here is the log file.

At around 17:02:50 in the plot, the EKF altitude dropped, causing the drone to shoot up (visible in the baro altitude), which obviously led to me dropping throttle to not hit the roof.

Vibrations are not as low as before, but still quite low on an absolute scale.

Again the baro altitude matches my observation of the drones altitude during the flight. I don’t think that there is any ground effect going on when flying 3 meters high with a 3" drone.

hello @Janno
from the log what i have observed that your state variances are bit high you need to look into these, it should below 0.5 m/s.
i also recommend you to do barometer calibration and compass calibration.

So I dug some more in the direction you pointed (thank you for that hint), innovations are indeed high.

XKF3[0].IPD gets stuck during flight, do you know what could be the reason for that?
XKF3[1].IPD is fine the whole time and, as seen in your screenshot, IPN and IPE signals are also continuously logged.

XKF3[0/1].IVD/IVE/IVN seem to only be available (or get logged) after ~30 seconds of flight, right when the copter jumps up in the air. Do have an idea what could cause that?

I noticed that XKF3.IVD/IVE/IVN weren’t available at all in the three flights I posted first, which were indoor without gps. Is it possible that there is a connection to EK3_SRC1_VELZ = 3 (GPS)?

I did the MagFit test flight before, but when I uploaded the log in the MagFit webtool it said that compassmot doesn’t yield significantly better results than just compass offsets + iron calibration, so I used the latter. I you want to have a look, here is the MagFit test flight.

With “baro calibration”, do you mean baro compensation or did I miss something? I am planning to do windspeed estimation and baro compensation after I finished Autotune, during which these problems came up.

1 Like

Firstly my question is are you flying indoor? with Gps or without Gps ?
if you are flying without GPS , then follow this guide.
Non gps Navigation

Flight controller which you are using has only 2 IMU’s refer this Matek H743
This is the reason for XKF3 not shown in log .bin file.

I also observed that in auto mode, you have height fluctuations as shown in below screenshot.

I recommend you to try EK3_SRC1_POSZ = 3 and AHRS_GPS_USE = 2 , then do test flight and analyze logs.


I usually fly outside with perfect gps signal or in a hangar with decent gps signal (good enough for home to be acquired). I did the first three flights I posted indoor, as they were planned to just be short hovers to check filters. In the future it is planned to use the drone fully indoor with PoZYX beacons.

I’m not sure what you mean with that, I do have XKF3[0] and XKF3[1] messages in the logs.

I don’t think setting EK3_SRC1_POSZ = 3 will help much, the GPS altitude varies even more than the baro altitude. I would attribute the baro fluctuations to flying on a windy day without baro compensation.

Well I mean that XKF3 is shown but only for 2 IMU’s that is XKF3[0] and XKF3[1]. You don’t have a 3rd IMU so that XKF3[2] will not be shown.

Yes, that makes sense.

Update on my problem:

I increased EK3_ACC_P_NSE to 0.5 (default 0.35) and descreased EK3_ALT_M_NSE to 1 (default 2).
The real altitude now follows DAlt closer and the XKF3.IPD innovations are much smaller than before, as can be seen in this log. It is still not perfect though.

Also what I noticed is that we tested the drone (all 4 motors at once) on a motor test stand and the data says the drone produces enough thrust to hover at ~40% throttle. However in flight MOT_THST_HOVER is learned to a value that’s even below 20% throttle. Additionally we get an unusually high (for 3" props) MOT_THST_EXPO value of 0.63 from the test stand data. The drone weights 600g so we (should) need ~6N of thrust to hover which would correspont to ~40% throttle.

@rmackay9 this is the issue we talked about in the Dev meeting a couple of hours ago.