How do I reduce camera shake in Loiter?

After properly tuning my 7" quad to a decent spot, I get pretty nice flight performance in stability/alt-hold/acro mode. There’s practically no bounce with sharp stick inputs in all modes, wind handing is great, and propwash handling is good.

With Loiter, I expect the quad to pitch/roll to maintain position hold, which will look like “shake” in the camera. But I get this low frequency bobbing that that I don’t know how to get rid off; it seems to be on top of the normal flight behavior.

I tried lowering the stabilization P to 4 and ACCEL_MA to 78000, and the LOIT_ACC_MAX to 100 but it’s still there.

Need a .bin log to tell

Log is here: https://drive.google.com/file/d/1a-UmSnRyYxcFNuXe-qmyyQqg8pj9jYQE/view?usp=sharing

Many thanks for taking a look!

Tuning looks very good to me. Loiter mode is quite steady when you select it.
Maybe try running Autotune?
Or tuning the PSC position parameters?

Also try these Loiter params
LOIT_ACC_MAX,600
LOIT_BRK_ACCEL,300
LOIT_BRK_DELAY,0.3
LOIT_BRK_JERK,300

So I tried the loiter settings but it didn’t seem to make much of a difference. What’s happening is the quad seems to enter bobbing-like oscillation, in Loiter only. So it’s got to be some control loop that turns on with Loiter.

I fiddled with a few PSC setting which affected the accuracy and responsiveness of loiter (like drop POSXY_P, or lower ACCZ_P/I will make it more drunken) but it’s not making this perpetual bobbing that the quad gets into any worse or better. It seems like an orthogonal behavior. So it feels like I’m not touching the right control loop… I’m also certain I don’t understand the control loop behavior all that well either.

I was wondering anyone could share their PSC settings for loiter for a 5~7" mini-quad for me to try a different starting point?

There are 5 barometer errors in that log. If you plot Baro Health you will see them in addition to the error messages.

Perhaps you can see the effect of a vertical position error problem here:

Here is a reference graph from one of my 5" models:

Actually Baro and compass errors occur simultaneously. Not sure what to make of that.

I would think the noise with barometer should also show up in alt-hold, but except for some altitude drift, my alt-hold looks locked in.

I have a video going from alt-hold to loiter, and flipping back and forth between alt-hold (no bobbing) and loiter (bobbing).

For altitude, I have a small piece of open foam (the ones they use in the retail boxes for lipo batteries) over the barometer but I’m wondering if I should use something denser or maybe wrap some tape around the frame to block propwash.

I had such problems years ago with my Octocopter. In my case wasn’t any setting that caused it but rather interference caused by wiring close to the FC and also the telemtry transmitter.
The fix was to move the wires away if possible or at least wrap them in aluminium foil and I also did the same to the actually telemetry transmitter board (obviously not the antenna)
Speaking of antenna, also this caused once an interference problem as it was originally pointed up causing RF signal to interfere with FC. …solution? Simply pointed antenna downwards and hence signal was directed down and not into FC.

Thanks for the feedback. I was a bit hasty in my reply to Dave (sorry Dave) and missed the compass error.

I now seem to be getting very frequent baro/compass error-4 then error-0 together (that’s an unhealthy EKF error?), whereas weeks ago I wasn’t getting this. Kind of snuck up on me because I had errors disabled in logger.

I’ll look at wiring around the FC; seems like if the baro is erroring out with compass, it’s not some interference on the compass or propwash on the baro.

The Baro Health message wouldn’t be from propwash. A communication problem I would think. The Baro is on the I2C bus, perhaps that’s why there is simultaneous Compass errors.

Good point. The matek f405-se has baro on i2c1, so I have my compass on i2c2. So unlikely a contention issue, but maybe something with i2c setup. Could insufficient cpu cycles also cause this?

I did unfortunately did two variable changes so can’t 100% say which helped but after adding some copper tape under my gps/compass mount for electromagnetic isolation (which lead to less EKF errors) and updating my copter version from 4. 1beta to rc2 I’m not seeing this problem as much.

So many thanks for suggesting copper foil tape!

So this problem occurs on my 2nd 7" build after I did some manual PID tuning. Having loose RPY and ACCEL tunes actually masks this (kind of makes sense since it’s dampening). Same frame and M9N, but using an H743-slim instead of F405-SE FC.

I significantly improved this by reducing the PSC_POSXY and PSC_VELXY PD gains from default. The accuracy of position hold was remained good.

I’ll share my full dump below.

PSC_ACCZ_D,0
PSC_ACCZ_FF,0
PSC_ACCZ_FLTD,0
PSC_ACCZ_FLTE,20
PSC_ACCZ_FLTT,0
PSC_ACCZ_I,1
PSC_ACCZ_IMAX,800
PSC_ACCZ_P,0.5
PSC_ACCZ_SMAX,0
PSC_ANGLE_MAX,0
PSC_JERK_XY,5
PSC_JERK_Z,5
PSC_POSXY_P,0.2
PSC_POSZ_P,0.35
PSC_VELXY_D,0.4
PSC_VELXY_FF,0
PSC_VELXY_FLTD,5
PSC_VELXY_FLTE,5
PSC_VELXY_I,1
PSC_VELXY_IMAX,1000
PSC_VELXY_P,1
PSC_VELZ_D,0
PSC_VELZ_FF,0
PSC_VELZ_FLTD,5
PSC_VELZ_FLTE,5
PSC_VELZ_I,0
PSC_VELZ_IMAX,1000
PSC_VELZ_P,5