Altitude loss while repositioning (altitude vs. CR)

Firstly, I’m not sure if my issue is or is not connected to any of:
viewtopic.php?f=111&t=14150
github.com/diydrones/ardupilot/issues/1277
youtube.com/watch?v=7c6H1visOuc

I’m using Copter 3.3.1 on X quad and the issue is that my copter looses altitude (e.g. in PosHold mode, throttle in middle) when it’s flying in mid-speed as you can see here:
[youtube]http://www.youtube.com/watch?v=b_I5CjELOGY[/youtube]

I’ve noticed that even the altitude (baro, final and desired) is decreasing, climb rate values are on the maximum (desired and ?final?) when I’ve analyzed dataflash logs - see attachments.

Full log link: dropbox.com/s/oqva0wxs1x44t3v/33.BIN?dl=0 , part from from video is approximately between lines 116k and 122k.

My question - is this the issue of my parameters of is it other issue?
Here is list of my parameter values, that can affect this behavior in my opinion:

POS_Z_P,1 VEL_Z_P,5 ACCEL_Z_I,1 ACCEL_Z_P,0.5 EKF_ALT_NOISE,1
Any help appreciated.

Hello sobi

I think it is being treated in github.com/diydrones/ardupilot/issues/2568. The issue is open.

Randy was asking for some feedback, but no one has answered. Maybe if you are comfortable you could try…

I have flown with velocity up to 20m/s while my theorical speed was 13m/s in ecalc without losing altitude. I was afraid to push it harder.

PS. which system are you using to draw that nice osd?

Here’s the graph. You can see that Dalt is almost identical to alt.

Thanks for pointing me. Anyway - my problem seems to be a bit different - the desired altitude is going down, but the input throttle is kept in the mid deadband in PosHold -> so the altitude should not change.
And the calculated climb rate seems to by on positive max. value in the same time (CRt parameter of CTUN).

OSD is called PlayUAV - see playuav.com/wiki/doku.php?id … vosd:start
I’ve bought it on goodluckbuy.com

Sobi,

You’re right. It looks that it isn’t related to the issue that I have pointed. It seems that the arducopter decides to not raise the motor throttle to keep the altitude despite the fact that DCRt wants that.

I’ll parse your parameters to see if I found something that can cause this behaviour.

Thanks for pointing me out the OSD!

It looks like always when your frame is developing speed it seems to loose altitude. It also had happened a few times before line 116k

Your vibrations levels ( vibe x,y and z ) are pretty high. They increase noticeable when you raise the speed.

It could be a unbalanced motor/propeller or even air shaking the cables/pixhawk. This vibration can cause the ekf to go nuts and behave badly, most on altitude control.

I’ve noticed that too - but if you take a look at vibrations in IMU logs part - they are quite low (less than ±1 ~ ±0.1G for X a Y) - not sure what could be the reason.
There is something that causes, that EKF is not working for me as it should I think, but maybe I’m wrong.
Thanks for your time and effort.

You’re welcome!

Yeah, the imu graph looks nice. I think someone more used to efk could explain why the vibe levels are so high in contrast with imu. I don’t have any clue about that , but I trust this could be the cause.

Sobi,

Leonard has explained to me that the vibe is meant to be different than IMU logging :

Therefore, try to look for high vibrations in your copter.
How do you setup your pixhawk to isolate the frame vibrations?

Well, I’m using small kyosho gel pads under PH. I find them work well from my previous apm heli project. Propellers are already balanced, so the next thing I can try do is to use some damping under motor mounts.

I’ve took a look at IMU graphs once more and I’ve found big difference between IMU and IMU2 z vibration values - see attachment.
I’ve also noticed, that Randy did some changes in Copter-3.3.2-rc in z-axis filtering - so there are some tries to do yet.

I think Tabascoz has correctly identified the issues and in particular I think it’s caused by high vibration. The way to measure it is mentioned here but I’ve also attached some graphs.
copter.ardupilot.com/wiki/common … vibration/
The levels are regularly climbing to the 40m/s/s range for many seconds (i.e. not short-term spikes) and we can see the conradiction that appears in the altitude vs climb rate. I.e. the climb rate is positive but he altitude is falling. This is the classic sign of high vibration levels messing up the EKF’s altitude estimate.