PROBLEMS WITH CTUN.Alt

I am having terrible issues with the altitude calculated by the copter. The barometer altitude and the sensor altitude are kinda good but the parameter CTUN.Alt is crazy.

I made a simple experiment to prove it:

-Put the copter on the ground (with propellers) and put throttle 40% while holding it (it stays on the ground).
-Move the copter onto a table (~1.5m approx) (When in the table, the rangefinder will read a low altitude)

this is the graph for the first part of the experiment where the copter stays in the ground:

I cant explain why the CTUN.Alt varies that way. It makes impossible to use the AltHold modes (4 crashes by the moment)

My logs: https://drive.google.com/open?id=1GsDKHgEQPjeIAZm-sOb8OaRTG6CRiKJR

Try running the same experiment as this log, but without the motors running. Use LOG_DISARMED = 1 to record a log without arming. Also please upload a log with an actual flight, if you have one.

After looking at your log, I have a suspicion that you are experiencing some vibration that is ruining the EKF’s altitude estimate. The vibrations measured in the log appear to be within tolerable bounds, but I’ve seen some situations where some frequencies aren’t picked up. There are a few moments in this log where there is a clear oscillation which might mean there is something more, but it could just be ground resonance.

Really thank you Anubis for the fast answer.

I made the experiment and this is what i got:

The CTUN.Alt is awesome now. CTUN.BAlt is constantly increasing but i think it was due to the Temperature in baro (it actually increases) so it doesnt worry me.

Before doing this experiment, i’ve also changed 2 params:

-EK2_ALT_M_NSE is 1.0m now, it was 1.5m in the last experiment.
-EK2_IMU_MASK is 1 now (I saw IMU2 more noisy so i though it would be better to ignore it)

Anyway, i will do the first experiment again (armed) with this params.
The logs: https://drive.google.com/open?id=1rULXwWdeYmEpLmTYV9HH9wjVfF9lvo38

This is the log of an actual flight, ended in crash.

The point where baro is 0 (~ x=18) is actually a ground touch.

https://drive.google.com/open?id=11nSdZSiuF9hrC0hVeRRbJNf4WCsEHNCf

Hm yes this seems to further implicate vibrations as the culprit - the EKF is handling the altitude estimation correctly when the motors aren’t running.

For your next motors-on experiment, you could enable full rate IMU logging, that might give us some more insight. Also, upload it as a .bin file, I think that’s required for an FFT analysis, which we might need to do.

But mostly, see if you can find any major source of vibration. A good experiment if your flight controller is soft-mounted is to tape some extra weight to the FC board to see if the vibrations calm down.

I did the same experiment with propellers (this time i just holded it onto the ground, didnt move it onto the table) and the variations in CTUN.Alt appear again.


The bin file:
29 01-01-2000 1-01-56.bin (990.6 KB)

Hm yes then it is almost certainly related to vibration. The EKF uses the accelerometers as a major source for the altitude estimate, so vibration can severely affect it.

When you spin up the props, does the drone feel like it’s vibrating? If so, check your motors for bent shafts and propellers for balance. If the vibration isn’t really perceptible, then you might need to change how you mount your flight controller.