When I start to think I understand the GRYO filters and Notch Filters, I always seem to run into a wall. Between the FFT and the new Filter Review site, I thought I had those dialed in - and maybe I still do - but the drone doesn’t seem as dialed in and my other drones have been.
I did an auto-tune that turned out okay - little wobbly on the pitch - though in wind (3 m/s) the drone doesn’t handle super well.
My assumptions on the ESC notch is to set the frequencyto the start of the peak and bandwidth to a 1/4 of that frequency. The gryo I flip between 75 (default from initial calibration tool) and bumping up to 150 (as Andy has in his 5" LR build).
You are on the right track. Yours actually looks to be working fine, but there is a bit of overkill.
Just to review:
When using ESC RPM the FREQ and BW are scaled up with the RPM, so FREQ and BW have to be in the correct proportion, and lower than the expected low frequencies.
When using multi-source, or per-motor notch, you want the bandwidth at about 1/4 of FREQ to reduce lag and adverse effects on PIDs and attitude control caused by having multiple notches.
I only specified FREQ 80 here because it is the default and would also suit your copter, almost just a visual thing.
Try BW 10 and recheck the graphs - if you have to go to 15, or maybe 20 but that should be more than enough.
I would reduce the harmonics because you dont need the extra notch so high up, the standard low-pass filter INS_GYRO_FILTER reduces that noise a lot anyway.
Keep INS_GYRO_FILTER,75
since this is working as planned, if you set it to 150 (or more than 75) it will be above the noise and ineffective in the most important part of the frequency range for your copter.
You could even go as low as 60 provided you retain the responsiveness of the copter.
Your pitch and roll attitude control looks particularly good, but yaw is the bad boy.
Try running that yaw autotune again but with AUTOTUNE_AGGR,0.1
or you could set ATC_RAT_YAW_D,0.001 and select the Yaw D autotune.
I would also advise to turn the FREQ from 85 where you have it to something like 70 or maybe even 60 (and decrease BW proportionally), because in that log there is an interval from 81s to 82.5s where one of the motors rotated slower than at 85 Hz.
You may also try to untick bit 2 “Update at loop rate” of INS_HNTCH_OPTS and see what happens - in my case the presence of this bit increased the noise significantly, although my F405 CPU might have just been too slow.
If your CPU is fast enough (it may be, based on the low CPU load in your logs), you may try setting the scheduler loop (SCHED_LOOP_RATE) to 800 Hz, which, if not getting immediately stuck, generally improves responsiveness.
Thank you both for responding. I did updates, and while it flew great, the autotune always came up poor (rates of 16ish, accels of 130k). I’ve accept those values as fine, but realized that when using an RTK setup and having the drone in RTK fixed, the drone would move more that I’d like (stays within 3ft circle). So I turned the gryo down to 50Hz and adjusted the notch filters a bit, which resulted in a higher tune. My loiter problem still persists though. I have another drone, different in design, that loiters with RTK fix in a much tighter position (body stays within a 1 ft circle) with a much worse tune. Both flown the same time, so external factors remain constant. So I don’t really think the tune is my issue (as I said before, with the configs you both mentioned, it flew great).
With that said, what can effect loiter? In the attached log, the attitude seems fairely decent. I did notice the GPS lat/lng differs from POS lat/lng greater in my drone that has poor loiter positioning compared to the drone that does better. Is this even a valid comparison?
Is there another avenue worth exploring that isn’t mechanical in nature?
because I think the wide bandwidth and per-motor notches will be possibly causing lag in the PIDs.
Also try an Autotune with aggressiveness 0.08 or 0.1
For the position issue you could try: GPS_GNSS_MODE,7 or 67
to see if that shows improvement. You can see on the map the IMU-calculated position rarely matches the GPS position.
In logged data the GPA.Delta is not showing issues, but you do have a very high number of sats and I suspect that could be an issue for most GNSS units. For example where I am Beidou gives a high number of sats but also a poorer HDOP and longer time to 3D Fix.
