Weird altitude behaviour in POSCTL mode

Hey guys

I am observing some weird behaviour with the current PX4 beta when in POSCTL mode.
As soon as I start to move the copter using the right stick only (left stick neutral) it correctly starts to move in this direction, but meanwhile also gains altitude at an almost constant speed. The logs are here:

http://logs.uaventure.com/view/ZTGm2hUZg2hCSWxgvWJMtG#Local_Z_PLOT

Examples can be found at minutes 54, 55 and 56. I did already try to fiddle with the MPC_Z_* parameters, but couldn’t observe any change - even with quite extreme values. As soon as I let go of the right stick, the multicopter quickly descends back to its original height.

I also tried to replicate this behaviour in SITL, but I wasn’t successful.

Any ideas what could be happening?

Best, Alex

Off the bat it looks like tuning. You flew really fast (20 m/s, 72 km/h or 45 mph) and to keep altitude at that level of aerodynamic variation you might need a much higher MPC_VEL_Z param (but be careful when changing / testing it).

Flying fast might also have influence on the barometric measurement, indicating the Barometer a higher pressure due to dynamics, this would lead to lower Alt so the copter would compensate and climb.

Thanks for your comments!
I first thought of this, too. However, if I flew slower, the deviations got even larger. Look at the two largest spikes at minutes 57 and 00. There the top speed was only 10m/s.

Manual flight even at speeds of ~26m/s is very stable.

alright… It’s a little late now, but I think I’ve found something:
https://s33.postimg.org/4aljyna4f/Data_Velocity.png

First of all: I had MPC_Z_VEL_MAX set to 2m/s, so it limits the descent velocity.

But more important:
As far as I understand the LPSP.VZ is more or less the z-position error scaled by MPC_Z_P. This seems to be working correctly. However, why does the actual LPOS.VZ curve follow this so accurately? Because by looking at the red graph, VZ should be clearly different from what LPOS.VZ is showing.

I think you’re seeing an estimator failure case, either because of vibration or wind. Can you try to set SYS_MC_EST_GROUP = 1 to enable the LPE estimator and re-test?

I’ll give it a shot!

Hi,
I also witnessed this behaviour about a year ago when I was flying the IRIS with the exact same estimator you are using. The arms of my IRIS would get into a resonance if I would manoeuvre it a bit harder. As a result the estimator was diverging and then drone shot up in the air thinking it’s too low.
Looking the the acceleration values of your log it looks like you have some vibration problems too (IMU.AccZ). Also compare the z acceleration with x and y. The latter ones don’t seem to suffer from vibration that much. What is your setup like?
I would encourage you to fix your setup because like this you will not get a good performance.

Regards,
Roman

Hi Roman

You’re right… The z-Axis vibrations indeed look terrible. I never realized that before. Unfortunately, before reading your comment, I had a testflight with the LPE estimator and the drone crashed badly. I have no idea what happened, but it couldn’t maintain a level attitude even in manual mode. Maybe this is related, but unfortunately I haven’t been able to recover the SD card so far.

Anyways, Lorenz and Roman, thanks a lot for your help. I think I have a good starting point to further investigate from here.

Best,
Alex

@defreng Sorry to hear about your crash. Were you able to see your HUD before takeoff? If you ever get the log file working, would be very interested to see it and help you debug.

@jgoppert yes, I did see the HUD and was able to fly normally for approximately 5 minutes. Then, after moving the copter a little faster (~14m/s) it suddenly seemed to be frozen, as it slowly banked to one side and didn’t react to any stick movement in manual mode.

If I am able to get the SD card I will certainly make the log available. However, if there is nobody interested in climbing a 30m tree in the Zurich area this seems unlikely :wink: