Z Oscillation in Position hold

Hello Gents! I’m on the newer side to AP and have been working on 5-10" copters using off the shelf FPV componenets, mostly Speedybee F405’s.

One issue I’ve had with this current build as well as 2 earlier macro (8" and 10") FPV quads its a Z-oscillation in althold after getting a safe initial tune in stabilize per the Wiki.

I’ve used both the Wiki’s Tuning Process Instructions as well as TMac’s Arducopter Tuning Youtube video: Arducopter Tuning (AUTOTUNE, PIDs & FILTERS, FLIGHT TESTS!) - YouTube

I would say I used Andy’s amazing 7" LR video but I’m going to be honest, I’ve always been a bit overwhelmed by the density of (good!) information in it.

Anyways, here are 2 recent logs from my flight. Can I get some help in diagnosing where I went wrong? I fully understand I potentially need to go back and get some better default values in there so I am open to all advice other than “read the wiki”!

Per the wiki I have been reducing the PSC_POSZ_P and PSC_VELZ_P values almost down to nil, but the oscillations remain.

Hi @telamechanica,

The altitude oscillation is probably caused by the barometer or the rangefinder.

I guess the frame has short legs because the barometer reports the altitude falls by about 5m during takeoff and landing probably because of the pressure build up under the vehicle. Lengthening the legs is the simple fix.

The other possibility is the oscillation comes from the surface tracking feature perhaps due to slow response from the lidar. You could try disabling surface tracking and/or the rangefinder to see if that resolves the problem. Another solution may be to adjust the SURFTRAK_TC parameter (I can’t immediately say if higher or lower would be better but perhaps higher).

I would also suggest to try and lower your PSC_ACC_Z_P and PSC_ACC_Z_I, they are at default and you seem to have a very “powerful” quad.

restore them at default value, but lower PSC_ACC_Z_P to 0.15 and PSC_ACC_Z_I to 0.3

1 Like

A reply from one of the greats on my first post! Thanks for taking a look at my logs.

The solution turned out to be in the Wiki (partly).

As @Ferrosan recommended below, addressing the ACC_Z_P and ACC_Z_I addressed the problem.

For any future readers googling this solution, despite the oscillations, you can still review the datalog for hover or check the learned hover value, which in 4.5 appears to be much friendlier for powerful quads like FPV style.

I’ll post an updated logfile with post-tune values after I dial in the HNTCH. Thanks again for your review gentlemen.

With regards to the POSZ_P and VELZ_P values, now that I’m no longer oscillating in the Z axis, is there anything I can do beyond defaults for those two values? What will changing them higher or lower do to my quad in alt or loiter?

1 Like

you would have to perform some transient and steady rate climbs/descents, then look at PSCD TPD/PD (for POSZ_P) and TVD/DVD/VD (for VELZ_P) to check how they track. At least, that’s what I normally do. Keep a good margin from what your aircraft is capable of achieving when selecting the target velocity and acceleration (in other words, do some manual flights first and pull it to the limits to get the right numbers- don’t guess them).

1 Like

Hi @telamechanica

Randy pointed me at this question. it looks like you have already found this part of the wiki:
https://ardupilot.org/copter/docs/initial-tuning-flight.html#test-althold

We rarely need to change this unless we are dealing with coupling between attitude control and alt_hold during breaking. The reason for this is the step above tends to scale the control to the mass and thrust of the aircraft. This is also why you don’t often need to tune the position controller unless your attitude control is very slow.

You can tune up the vertical controller using a similar manual tuning approach to the rate controllers but you probably won’t see much of an improvement overall.