Thanks Leonard for looking at this. Sorry for posting the previous log without exactly everything you had checked. I’ll give the lower pass filter a shot (as Andy had suggested earlier) when I get a chance to fly.
edit nevermind my previous question about set_throttle_zero flag. I have air mode enabled and I arm with a switch so… it should never set that flag.
I’m still fiddling with this on and off, but as far as I can tell my best feeling tune has so far been the older one with a higher gyro filter frequency, higher spin_min (which helps with the low throttle oscillation), and lower mot_thst_expo. Basically everything that’s not correct 
I may go back to this and just do some hand-tuning of D (make it lower).
The tunes around the lower filter and different mot_thst_expo have all been worse off. The autotune with filter 100Hz, spin_min 0.06, and mot_thst_expo 0.6 ended up with much lower PID values, felt sluggish, and couldn’t handle propwash.
The zero-throttle authority loss is not due to noise, so that’s not a factor in my experiments now.
I’m still wondering how I can enter a custom motor mix. Do I have to build a binary? I’d like to try this as it improved some bounce-back issues in a different deadcat 7" frame in betaflight… there’s been focus on getting the thrust function right, but we’re not accounting for the angular velocity on the arms not being symmetric.
Sorry, you didn’t make it clear if the problem went away with lower filter settings.
The buzzing didn’t go away with the lower filter settings.
If you want help solving this problem then you need to do a series of focused tests and changes and actively provide logs.
I’ve done what was suggested and lowered filter gyro to 100Hz, and FLTD to 50Hz, adjust the motor_exp to 0.6, and lower spin_min to 0.06. And re-ran autotune. The PIDs came out fairly low, the quad doesn’t fly all that well, but maybe the motor grind is less than before (but not gone).
However the grind was almost gone with a completely different group of settings that was deemed incorrect but otherwise flew amazingly well. So from my perspective, I was asked to change more variables (and issuing an auto-tune is a huge variable change) and my quad is getting progressively less performant the more ‘correct’ the settings look. So I wanted to take a step back here.
Hence I’m not sure my providing all of the logs that still have a grind sound is useful; I don’t want to just spam different logs of options which didn’t improve the issue, or declare victory when the oscillation is improved but the quad otherwise flies much worse. I can do that if we think that’s useful though. Or I can go back and try something along the lines of what I was doing before and provide those logs.
Hi.
I’m have 7inch quad but i’m using 4s battery and not 6s as you…
I’m have some pids - maybe you can try and test and maybe this pids some help you -
ATC_ACCEL_P_MAX,150000
ATC_ACCEL_R_MAX,150000
ATC_ACCEL_Y_MAX,35000
ATC_ANG_PIT_P,15
ATC_ANG_RLL_P,15
ATC_ANG_YAW_P,7
ATC_ANGLE_BOOST,1
ATC_INPUT_TC,0.15
ATC_RAT_PIT_D,0.0018
ATC_RAT_PIT_FF,0
ATC_RAT_PIT_FLTD,70
ATC_RAT_PIT_FLTE,0
ATC_RAT_PIT_FLTT,70
ATC_RAT_PIT_I,0.18
ATC_RAT_PIT_IMAX,0.5
ATC_RAT_PIT_P,0.11
ATC_RAT_PIT_SMAX,0
ATC_RAT_RLL_D,0.0018
ATC_RAT_RLL_FF,0
ATC_RAT_RLL_FLTD,70
ATC_RAT_RLL_FLTE,0
ATC_RAT_RLL_FLTT,70
ATC_RAT_RLL_I,0.18
ATC_RAT_RLL_IMAX,0.5
ATC_RAT_RLL_P,0.11
ATC_RAT_RLL_SMAX,0
ATC_RAT_YAW_D,0
ATC_RAT_YAW_FF,0
ATC_RAT_YAW_FLTD,0
ATC_RAT_YAW_FLTE,5
ATC_RAT_YAW_FLTT,40
ATC_RAT_YAW_I,0.018
ATC_RAT_YAW_IMAX,0.5
ATC_RAT_YAW_P,0.18
INS_GYRO_FILTER,90
INS_FAST_SAMPLE,1
MOT_THST_EXPO,0.6
MOT_THST_HOVER,0.24
PSC_ACCZ_I,0.48
PSC_ACCZ_P,0.24
My copter setup:
t-motor f40 pro iii 1600kv
props 7042 gemfan flash
4s 6000 lipo
geprc crocodile 7 frame
full weight - 1.045kg
Ok, to be more specific on what I would like you to do.
Starting with your filter settings of:
INS_GYRO_FILTER : 150 Hz
ATC_RAT_PIT_FLTD : 70 Hz
ATC_RAT_RLL_FLTD : 70 Hz
And the tune you were flying. Make sure ATC_THR_MIX_MAN = 0.1 to make sure an oscillation won’t cause a fly away.
Do a quick test flight to make sure the grinding is still there.
Reduce the filter settings to:
INS_GYRO_FILTER : 100 Hz
ATC_RAT_PIT_FLTD : 50 Hz
ATC_RAT_RLL_FLTD : 50 Hz
Without changing the tune check that the current tune is still safe to fly and if so check for the grinding.
If the grinding is there reduce the filter settings to:
INS_GYRO_FILTER : 50 Hz
ATC_RAT_PIT_FLTD : 25 Hz
ATC_RAT_RLL_FLTD : 25 Hz
Again, without changing the tune check that the current tune is still safe to fly and if so check for the grinding.
If you see that the tune is oscillating after any step reduce the P, I and D term of roll and pitch by 50%. I would expect you to need to do this at least for the lowest filter settings.
At the end of this you should have 3 logs or 1 log with three flights in there (plus any tune reductions that may be needed to make it safe to fly).
So to explain what we are trying to do here. We want to understand what is causing this grinding. Once we understand this and can remove it then we can look at how we can retain the performance you had previously.
Make sure the logging is correct.
And don’t just trust Autotune to get it right when there are issues like this with the aircraft.
Thanks, I got the idea. I’ll get those logs. On top of that, I wanted to try manually tuning the PIDs lower to see if that helps.
As an aside, on betaflight, I would be running a dynamic PT1 gyro filter at 200~500Hz and a 2nd pass LPF PT1 at 250Hz, and d-term PT1 dynamic filter is 90~150Hz with a 2nd pass PT1 at 195Hz. So dropping the filters that low is not something I’m accustomed to. Is the implementation significantly different from betaflight? When I switch to the H743 could I get better filtering options (I actually just finished a 2nd build with an H743 and but need a longer block of time to use the setup process to make an arducopter tutorial)
If you trawl my GitHub history you will see all my attempts at getting @Leonardthall to buy into betaflight filtering 
the implementations are very different and its not clear how scientific betaflight’s approach is.
Unfortunately signals and systems wasn’t one of my focus points but it’s definitely interesting 
I just crawled through a few of the PRs with your name. Definitely interesting. And it’s clear I jumped into Arducopter at a good time given all of the improvements.
This isn’t about tuning at this stage. We are trying to understand why this is happening. If we can’t stop this by reducing the filters this low then it points to a problem that is not filtering or tuning dependent. (I have concerns about this but we need to make sure it isn’t something simple first)
As for the betaflight filter implementation. There has been a lot of cross pollination between all the open source code bases. But because ArduPilot is a fully stabilised control system rather than a rate only control system our response requirements are slightly different. Further ArduPilot is used to fly aircraft that are worth more than luxury cars so we have to do a lot of analysis to ensure what we are doing makes sense with minimal unnecessary complexity.
Betaflight uses the pilot to do angle stabilisation so they can tolerate (even enjoy) a less linear rate response without issue. Oh, they can crash. (I remember when were allowed to crash, it was nice)
There are gains to be had from dynamic low pass filters on aircraft with very high power to weight ratio. You get enough knobs that you can change, to get good to excellent results. And everybody is flying very similar aircraft so being able to copy and paste other peoples settings works well.
However, generally the control loops are unnecessarily complex and they don’t come with a methodical engineering tuning method needed to fly such a wide range of aircraft. My personal tuning experience ranges from 150 grams to 500 kilograms. Or aircraft, multi, heli, coax copters, even submarines use the same PID loops as multi. So we just don’t have the freedom to play with ideas in the release, all the work needs to be done up front and proven to not only do what we say but improve on what we have.
Finally I will leave you with where we really pull up short on small fpv style aircraft, compared to BetaFlight. It isn’t filtering or our pid loop design (both have been demonstrated to be able to compare directly with betaflight on performance). It is our inability to run our loops at over 1 kHz (reliably anyway), and our requirement for better AHRS performance to support navigation (ie we are more sensitive to noise, vibration, and calibration).
The 4.0 release had the required components in the RATE loops to support enable them to run at a faster rate than the rest of the code and Andy is doing a great job adding support for the ESC interfaces that BetaFlight has driven forward. But ArduCopter will necessarily move forward slowly, but only ever forward…
Thanks for the background. I fully appreciate and can’t begin to fathom the complexities of having one code base serve such a wide range of system requirements. There are just some things you can do on a 7" quad that you can’t do on a 500kg craft, like disarm to land 
For the logging options, I was curious why we wanted imu_fast is unchecked. Is it to free up processor cycles and is there a drawback to keeping it checked (I’m a sucker for having more than less in logs).
Is the loop rate limitation that you’re referring to with the IMU gyro rate or the main control loop that’s set in the sched_loop_rate?
I am concerned that this is down to CPU load. If I do a custom build for you with thread statistics enabled would you be able to use it so that we can see where the CPU time is being sent?
Sure, I can try that. If I save then restore the param files, do I need to re-do any calibration?
Unrelated question… a few weeks ago I loaded a param file on my quad (saved from the quad just an hour beforehand). From this point on, mission planner would always stall at “checking for Param MAVFTP”, I have to click ‘cancel’ to continue, and it would take a while for it to load the params. Just a bit annoying to wait 10-20 seconds every time I want to connect the quad.
Is this previously known issue and would there be a fix? For weeks before I loaded a param file, it would always load the params immediately.
I getting this as well seems to go away though. 2x slow load today seems like it started a week or two ago.
+100 keep it simple.
Thank you guys for all your hard work.
Hi Leonard, I have the logs from the 3 filters here. I ran the sequence you suggested: 150Hz -> 100Hz -> 50Hz -> 50Hz + lowered PIDs by 50%
The grinding sound with the baseline is already pretty reduced, so as I lowered filtering I had to listen for it, but it’s definitely still there at 100Hz and 50Hz. Another thing I checked for was motor temperature from the oscillation; in all cases one or more of the motors were warmer than typical.
I have 2 logs with the 100/50/50; one was a long series of testing and one is a shorter one in acro for easy viewing.
https://drive.google.com/file/d/1QWp38vxo6KNInsa5TUx5yXzomwkXVMrh/view?usp=sharing
