My 7" feels ‘ok’ in stabilty/loiter/alt hold mode so far, but I’ve not been able to get it ‘locked in’ in acro mode. I recently ran auto-tune for roll/pitch axis, which completed successfully.
It’s not an issue of sluggish response (like from under-tuned P-gain), but rather the quad seems to want to roll/pitch in random directions even when it should just be flying forward in a straight line or just hovering. May be correlated with small gusts of wind (we’re talking like 5-10mph wind)
I have a log below that shows a period with zero change in any sticks (so the quad should just be flying at whatever angle/throttle it it was left at) but there’s deviation in desired roll/pitch (I just show roll here)
I also noticed quite some angle change with some throttle ‘punch’ tests, which I believe suggests insufficient I-gain? The auto-tune seems to end up though. Here’s my PID settings. I messed up auto-tune on yaw, so that’s my next thing to try. Not sure that would help with what I’m seeing though since yaw tends to be forgiving.
I happened to be reading up on filtering and discovered the settings for harmonic notch, which I’ll give a try later. I have DSHOT with ESC RPM telemetry (I think it works since I think I see ESC report motor RPM in the log), so I have the filters set up like so. Does this look alright?
My previous log is huge because I had done yaw tuning and series of acro flights, so it’s likely hard to analyze.
I enabled dynamic notch and I’m attaching a log where I just lift off in stability, switch to acro, position the quad to ‘hover’ and let go of everything (except maybe adjust the throttle) for 10-30 seconds at a stretch. I re-positioned the quad a couple of times in this flight. If you’re interested I can also post the video feed; you’ll see the view wanders around slowly. It seems to be worse with small gusts of wind, so I’m wondering if it’s still just a tuning issue and plan to try manually tuning.
I’m familiar with PID tuning on Betaflight manually (start with P, then D, then I usually, but need I to be big enough to fix error accumulation) but I don’t have a good sense of scale for the values in Ardupilot (there’s a lot of decimal points and the D-term is magnitudes smaller than P/I term).
I’ve read the tuning guide and suggestions to try going to up 1.5x~2x of auto-tune values, but I was wondering if there’s a better starting point for acro?
It all looks pretty good, although there seems to be some pitch oscillation coming through. I wonder whether raising your filter settings might help - try raising INS_GYRO_FILT to 80 say and ATC_RAT_RLL/PIT_FLTD to 50
Thanks for taking a look! If you don’t mind, could you share what you were seeing to judge pitch oscillation was too high? I’ll try the filter settings you suggested.
Since the logs don’t tell how the quad behaves, I figured a video for the same log is worth seeing. I have chapter markers starting at when I ‘let go’ of stick input and let the quad just ‘hover’. About 40 seconds in the first stretch, and almost a minute in the second stretch. It may look like I’m giving Y/P/R input but I’m only touching throttle.
I tried the following in order. I was flighting at night so zero wind conditions
Raised the INS_GYRO_FILT to 80, FILTT to 40, and RAT_RLL/PIT_FLTD to 50 -> With hover the random-drift has reduced to maybe 20-30% of before. But quad felt sluggish and the noise drifts quite heavily with relatively gentle, straight flying.
I started tuning the PIDs up from Autotune values. I started with the following
It feels significantly better than before and I can now start pulling more aggressive maneuvers (like fly in a straight line, turn 180, fly in a line). However I’m still finding the nose drifts up and down with moderate throttle changes (up to 20% of the effect as before) and very occasionally I get some larger drift in a more aggressive maneuvers. Basically quad feels like it’s locked in 80% of the time.
I feel like I should go look at the filtering one more time, then see if I can tune the PIDs up more? Unfortunately I’m not sure how to approach this as I don’t have a good understanding of what those parameters (esp. FILTD) are doing or why they’re helping the drift. Is it because the lower values add latency?
With copter control you are basically fighting noise for control. The more control bandwidth you can give the copter controllers the crisper the possible tune, but the more control bandwidth you allow the more noise gets through. With low filter settings you are getting rid of all the noise (good) but giving less control bandwidth for the controllers to work with (bad). On bigger copters with more mass it doesn’t matter so much - the size restricts how much control you have any way and the mass is natural damping. On smaller copters you need much more control because they react very quickly to disturbances.
So as long as your motors stay cool you can try higher on the filters. On my 3" I run the gyro filter at 120Hz and the D filter at 80Hz - too high for a 7" I would think but you get the idea. When you change the filters redo autotune.
On your settings above your Yaw angle P is pretty low (5.96) that’s an indication that too much noise is getting through on yaw and that was the highest that autotune was able to take it.
Also be aware that sluggishness can also be down to input shaping - i.e. you have a good tune but your pilot input is being dialed down. Have a look at INPUT_TC for instance.
Assuming I have a reasonable LPF on the gyro already, would it be safe for me to remove FLTT (set it to zero?) since it’s just applying another filter to the rate target? The wiki recommends setting FLTT to GYRO/2, which ends up being quite low if GYRO filter is in the neighborhood of 80~120.
FLTT only really filters control input - i.e. from you or the EKF, it does not affect the PID control - so you can set it to 0 or leave it low, it will make little difference to the control or how it feels. I run with FLTT at 30 even though I have FLTD at 80 and the copter feels very responsive.
Feedforward is for helis, it does not work in the same way the BF FF does, but I think Leonard put in a patch that means its at least safe to use it. I’ve never changed it.
If you have a bad tune (because of too much noise) then low values of ATC_ACCEL_*_MAX can make the copter feel sloppy. I used to set these to 0, but now with a low noise tune its not necessary
Thanks for your settings! So I discovered I did something silly: I had ACRO_OPTIONS[1] set, which disabled angular stabilization. I had this set when I was just starting to set up ardupilot for the first time and I think I misread “disabling angular stabilization” to mean “disabling auto-leveling” which is really set in the trainer option. Changing this to zero fixed the last of the drift issue I had.
Separately from that, I’ve been able to push my filters up with motors just being luke-warm. INS_GYRO is 150hz, dynamic notch with min of 100hz, and FLTD = 70. Quad feels pretty good in acro. Auto-tune also ended up with these values.
Sorry had one more question … when I switch from acro to loiter, I get this frightening large, low frequency oscillation for 2 seconds when the quad tries to flip to level. The first period is 400ms, so it’s like 2.5Hz. Quad does hit level though.
I should add in acro, the tune felt fairly good, though at most I did sharp 30-40deg rolls… I just read up on how to properly setup air-mode authority at low throttle so I’ll try some proper flips/rolls tomorrow in acro to see if this is just a tune issue.
It seems related to tuning but haven’t quite nailed it down. I plan to get my tune better in acro mode and assume that would translate to better performance everywhere else.
So on that note, I get fairly good performance (setpoint/angle tracking) with aggressive flight, and even rolls at zero throttle. But the quad starts to shake if I’m at below-hover throttle and not pulling off a roll. I’m wondering if this is something going on between throttle vs stabilization priority.
This is a full 650deg/s roll with min-throttle stick. Tracks really well
So normally flying through propwash causing shakes is a tuning problem so I plan to check it from that perspective.
I’m finding the sampling rate in the logs is low, so log file debugging misses some overshoots; does enabling “ATTITUDE_FAST” and “IMU_FAST” in LOG_BITMASK fix this?
