Altitude value drifting - Pixhawk - 3.2.1

I noticed on three different Pixhawk boards, since frimware 3.2.1, that the “altitude” value does constantly drift (increases), with the boards on the bench and not moving (no air draft, no room temp changes). I can wait many minutes (tested up to 20 minutes) and the altitude still increases (ending up at a few meters high).
It can’t be a baro issue on three different boards (or still ?). So I’m left with an hypothesis on the 3.2.1 firmware : is it the EKF stuff that sets chaos here ? (although EKF is disabled on all boards)

Not certain I would expect any better to be honest if using baro and accels alone. The board will warm up even if the room doesn’t. a few meters relates to air pressure changes less than 1 milibar, Atmospheric pressure is about 1000mili bar at sea level. Atmospheric pressure can change at several milibar per hour.

Even if gps is enabled which isn’t that accurate in altitude, a few metres change wouldn’t surprise me.

These are not tactical grade IMUs :slight_smile:

I have seen this also. On my first UAV, I assumed it was a problem with the barometer but now am seeing the same issue with a second Pixhawk. While configuring on the ground with no prop wash, both of mine show that they are climbing approximately 1FPM.

This problem is the same when flying. After 20 minutes, that becomes a real issue when in the air as the UAV’s do not decelerate for auto landings thinking they are still quite high when approaching the ground.


I agree this is rather an issue for long auto mission (more than 15 minutes) as such wide altitude drifts (a few meters) would/could cause incidents.
What disturbs me is that I never saw such a phenomenon on the previous firmware (flying since 2.8). Could the firmware be the cause ?

have you got good gps? Are you using ekf?

My GPS HDOP is typically sitting at around 2 - 4 when in the house seeing this issue with the altitude climbing. I am seeing this on all 3 Pixhawk’s that I own now that I am paying attention. All are running 3.2.1

Are you seeing this outdoors? HDOP is just an indicator, GPS indoors is not going to be accurate enough to allow the brain to keep altitude in check.

I would be concerned if the pressure doesn’t change by the same amount. Even though the temperature doesn’t change the barometric pressure could be going up or down causing a change in altitude.


I am seeing the same issue outdoors where GHDOP is below 2 at all times. After a 10 to 15 minute flight, I have landed with the UAV indicating I am 18 feet off the ground. This is a real problem when conducting auto missions 20 or 30 feet above the treetops. It is also an issue when landing in auto mode as the final dissent speed is just getting established when I reach the ground.

With regard to the Extended Kalman Filter, that is a good question. I am out of town for a couple of days. When I return, I will see I the new filter is in use and if so, if adjustments to the EKF_ALT_NOISE will stabilize the altimeter. Thanks for the suggestion. I had not considered that. Is it in use by default in 3.2.1? If so, this is a likely cause.

jg71q & iseries, the discussion is not about EKF nor GPS HDOP. It is about a potential HW barometer and/or firmware issue about altitude (calculated from barometer). The problem arises inside with the pixhawk sitting on the bench (no GPS, EKF disabled) and also outside. Use of EKF might help (i never tried it) but that would only mask the root cause(s).

Therefore , I would really like some 3DR hw people and APM:Copter dev to analyze this issue.

if you do one of your tests for 20 mins, is that from the unit being off for some period? If you re run the test after power cycling does it happen still with a warm unit? the baro log has temp in it…does the temp change in these files?

I still think a few meters change going on baro and accel alone for 20 minutes is acceptable given the grade of sensors, environment etc.

3D Robotics support is analyzing a couple of my logs and said they would get back to me later this week. I had submitted the issue related to one of my Pixhawks last week before reading your post and confirming the problem was the same in all of my Pixhawks. Will post if/when they have feedback for me.

One thing is for sure, changes in the local atmospheric pressure are not the issue here. I did confirm when the pressure was steady and with everything unplugged before the support guys agreed to review my logs.

OK cool.

I wondered about repeating after 20 minutes with a fresh log as if it didn’t rise or rise as quick it may indicate a warming up issue on the bench. Just because the room was the same doesn’t mean the flight controller isn;t warming up due to power dissipating in the CPU etc.

Hope 3DR sort it either way.

Yes I hope 3DR will come to a (positive) conclusion. PLease post as soon as your get their analysis back.

I have the same problem with fluctuating barometer values in 3.2.1 firmware. The altitude drifts from -1m to +3m when the APM 2.6 controller sits on the table. Flying in a barometer enabled modes is also unstable. Then I tried 3.1.5 firmware and the altitude fluctuated only around 0.1m during a 20min test. I think it’s a firmware issue.

Additional investigation info:
-on a given pixhawk board that I use a lot in the last year or so, old firmware 3.1.2 installed, baro behaves correctly and mission planner displays normal stable values around 0 meters when sitting on the bench.

-Then I install new firmware 3.2.1 on this same board, same craft, same bench. I then observe large and rapid barometer altitude drift (going from 0 to a few meters, sometimes more than 10 meters) in a few minutes, still sitting on the bench (same room, same conditions).

I oberved this same drifting behaviour with the same 3.2.1 firmware on three different pixhawk boards. So I also suspect an issue with the current last firmware release and/or mission planner about baro altitude.

Let’s post more observed cases to attract the attention of developers on this potential issue.

Would be interesting to see if ekf changed things. It isn’t masking issues, just fusing the different data sources in a different way. Given that ekf will be default next version that’s the way its going anyway. If it doesn’t happen with 3.1.2 its not HW anyway.

sent from my phone so apologies for any typos

Experiencing similar issues after upgrading to 3.2.1,

First noticed on autonomous mission there would be a pause on flight legs where the discrepancy in altitude was outside permissible range, flight would pause(hover), then continue on.

Next day, took the rig out to do an autotune, which then created a pulsing action in AltHold and in Loiter, and flight is Stabilize was ok. Did multiple tweaks to PID’s to smooth out the pulsing to no avail.

The Z axis vibration values appeared to be high, thus removed the foam shipped with the Pixhawk and used the Kyosho Z8006 gel. The vibration values did decrease some, and still getting the pulsing action in AltHold and Loiter.

May roll back to 3.1.5 if not able to remove the pulsing.


Timvan, how much of altitude or baro drift did you experience and over what duration ?

Well 3D Robotics support reviewed my logs and does not think the drift is an issue. I am quite disappointed with this. For now, my fix is to land frequently and rearm my drone. That resets the altitude. Until this is fixed in the firmware, I am not executing auto landings as occasionally the altitude is off far enough that the rate of decent has not yet dropped to the final decent rate and I did damage one landing gear on one of my auto landings. With regard to the new EFK filter, I am not using it yet.