Servers by jDrones

AC 3.6 Altitude Creep (increasing) in PosHold mode

Hello guys
A strange issue popped up today with my quad, 550mm frame, and pixhawk 2.4.8 running AC 3.6.
The drone is flying with optical flow only, no GPS. Altitude sensing comes from lidar only, no baro usage.

The drone took off in Poshold, but the altitude constantly creeps up. When I have the throttle stick close to 1500, the drone keeps climbing at a pretty constant rate. In the log, the altitude changes because I lowered the throttle stick. The lidar seems to be working properly, the vibration seems to be normal, i an’t figure out what is causing it. Only yesterday, I finished tunning the PID, and had a very good hover. Without changing anything, this problem came out today, at the same location, with the weather being sunny rather than overcast.

I have included here the screen shot of the log and the log it self. I’m at a complete loss on this one, I hope someone can shine some light on this.

Abnormal altitude drift.BIN (984.0 KB)

I’m also attaching the last flight log from yesterday, when everything worked normally.

Final Tunning.zip (644.1 KB)

I was doing some more digging, and noticed that the DSALT, which is the desired sonar altitude, is initially set to very high and had a few sharp jumps.

In a flight where everything is working normally, I would get the CTUN.Alt in between the DSALT and DALT.

How is the DSALT used in the altitude hold algorithm?

Looks like you need to re-do your accel calibration. The flight controller thinks it’s descending, even if the copter is hovering or even when it’s climbing:

At the beginning of the log before the copter starts flying, you can see that the climb rate is about -50 cm/s, and is -40 throughout most of the flight, even as the rangefinder reading goes up or stays the same. So the question is: why is the flight controller confused? Well, climb rate (and therefore altitude hold) is most strongly affected by accelerometer readings. Look at your Z accel reading:

The primary IMU is reading about -8.8 g’s throughout the flight. In hover, it should be about -9.8. This is consistent with the negative climb rate, as the drone feels like it’s accelerating downwards. The accel cal routine sets the expected maximums of the acceleroters; performing it will set the Z axis to read -9.8 like it should. This should fix the problem.

By the way, this problem was also present in the “good” flight log you posted, but the climb rate was around -20 or so, which I guess wasn’t wrong enough to produce noticeable negative effects.

Hmmm… you are right… even when I’m on the ground, the g isn’t correct… I will look into it! Thanks Rick.

Servers by jDrones