Altitude drifting in Pos Hold and Alt hold

Hi All,

its been a week with AC 3.5 that I’m seeing quite large altitude drifting in pos hold mode,
the horizontal position is quite steady, but the vertical pos is moving up and down continuosly, I have the last log during a Poshold flight, could you explain if its a Baro problem, PID tuning , GPS(?) or what else making this up and down?
Log file

Thanks

Do you have EKF2 or EKF3 enabled ?
Do you have altitude correction activated in EKF2/3 ?
What is the altitude correction source ?

Hi,
EK2 enable
EK3 disable

What’s the name for this parameter?

Do you mean the parameter EKF_ALT_SOURCE ?
If yes, it’s set to 0 = baro

In general I haven’t change these parameter from standard 3.5 firmware.

Today I made 3 flight test in altitude hold at around 3-4 meter high, but I have severe climb down and several time the quad land (from 4 meters in altitude hold). After the first altitude hold I’ve try to change in Extended tuning the Altitude Hold P from standard 1 to 1.5 , but as you can see in the log it doesn’t help to maintein the altitude.

Today I made 3 flight test in altitude hold at around 3-4 meter high,
I have severe climb down only and several time the quad land in ALT HOLD ! It never goes up, only down, how I can resolve this ?

This is the log

@rmackay9 do you have a wiki page explaining the baro drif compensation stuff in the EKF ?

Hi all, I’m still trying to solve this problem in AC 3.5, today I’ve make a good log which shows severe altitude variation against desidere altitude in alt hold and loiter mode.


I’ve also verified in realtime with MP that when the copter was climbing up the altitude value was going down (in the Quick tab in flight data screeen) and viceversa when copter was climbing down. Is it normal this behaviour ??
I also include the log here if someone could help to understand what’s is happening and how to solve this.
Please suggest me any other test, log and I’m going to make it :wink:
Thanks!

I just scrapped a Pixhawk 2.1 with this problem.Worse actually as the barometer on that saw 8-9 metre variation and not just 6 ike yours.It’s a hardware fault.Barometer is fubar.I replaced my FC and the problem went away. (see my autotune video for 3.5.0 using the new FC)

Old

New

No :frowning: , I’ve changed the FC and the same exact problem is still affecting the Alt hold Pos hold and Loiter

After change the FC and so the baro on the same copter I have the same behaviour in ALt Hold.
Yestarday a made many logs, initially the deside altitude is set far higher than where I switch to Alt Hold, and on the graph the copter seem so slow reaching that point, and it seems have sort of low gains to overcame the altitude difference.

Seems at first the des altitude is slow to be reached, is CTUN ALt working good?
Its a light copter ( 220g ) and after several autotune I’m using flying really weel with:
Stabilize Roll P 11.64006
Rate_Roll_P 0.06581955
Rate_Roll_I 0.06581955
Rate_Roll_D 0.002

Stabilize Pitch P 18
Rate Pitch_P 0.06168013
Rate Pitch_I 0.06168013
Rate_Pitch_D 0.002548281

Do you think the autotune PID out of range could make this Alt Hold up and down behaviour?

The stabilize P Roll and Pitch are out of range, could be that Alt Hold PID need to be set also in different way??

Possible.

Your PIDs are a factor of ten lower than the ones set by a couple of autotunes on mine. Roll PI is 0.65 and Pitch PI is 0.49.The only time I saw numbers set as low as your’s the copter was nasty to fly and didn’t stay up very long.That was on a 360 class hard bodied quadcopter.

So worth looking into.

I’ve been having the same problem since upgrading to 3.5 and now 3.5.1 with erratic Poshold and Althold. It flies smoothly in Stabilize.

Platform:
PixRacer v1.4 , not a clone, from mRobotics.io
power from their ACSP5 power module
Liberty Ducted Quad frame
log files at http://www.llamatrails.com/misc/pixracer

Log File C:\Users\rick\Documents\helicopter\multirotors\flight-data\liberty-ducted-quad\2017-08-06_home-no-oled-1st\2017-08-06 13-52-09.log
Size (kb) 124988.4873046875
No of lines 2034020
Duration 0:08:00 3312 used
Vehicletype ArduCopter
Firmware Version V3.5.1
Firmware Hash 8ab1b3eb
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = NA -
Test: Balance/Twist = NA -
Test: Brownout = GOOD -
Test: Compass = GOOD - mag_field interference within limits (4.82%)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = GOOD -
Test: GPS = GOOD -
Test: IMU Mismatch = UNKNOWN - No IMU log data
Test: Parameters = GOOD -
Test: PM = NA -
Test: Pitch/Roll = NA -
Test: Thrust = NA -
Test: VCC = WARN - VCC min/max diff 0.549463v, should be <0.3v

http://www.llamatrails.com/misc/pixracer/ctun-alt-1-no_balt.png

http://www.llamatrails.com/misc/pixracer/ctun-alt-1.png

Appreciate another pair of eyes looking,

Rick

I am having the same problem.
EDIT
actually, I had lowered my throttle P and I to .5 and 1 when the ins_accel_filter param was lowered to 10 earlier in the 3.5 release… And, now w/ that param back to 20, I was getting bad alt_hold behavior.

I just increased the throttle P and I back to their defaults of .75 and 1.5, and it’s better! not perfect, but I guess I just need to play w/ those settings a bit.

I am getting similar behavior with a pixhawk 2 utilizing 3.5, Did you ever determine a cause/fix?

My issue turned out to be that my PixRacer mount was too soft. I added weight to it, and it hold position well.

Rick

Was there any fix for this issue ? i’m facing the same behavior on 3.5.5.