7" quad - quad angle randomly drifts in acro despite zero stick input

ArduCopter Copter 4.1
67

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

68

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.

69

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)

70

If you trawl my GitHub history you will see all my attempts at getting @Leonardthall to buy into betaflight filtering :laughing: the implementations are very different and its not clear how scientific betaflight’s approach is.

71

:slightly_smiling_face: Unfortunately signals and systems wasn’t one of my focus points but it’s definitely interesting :sweat_smile:

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.

72

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…

73

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 :slight_smile:

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?

74

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?

75

Sure, I can try that. If I save then restore the param files, do I need to re-do any calibration?

76

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.

77

I getting this as well seems to go away though. 2x slow load today seems like it started a week or two ago.

78

+100 keep it simple.

Thank you guys for all your hard work.

1 Like
79

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

80

You still have batch logging and I think that is making your logging a bit hard.

image
image1301×730 43.5 KB

is what I was seeing before.

With any of the lower filters I don’t see this high output noise in the system when you have the throttle down.

What reduced it?

81

The main thing that helped is increase spin_min up to around 0.1~0.12 (and with it, I have tried thst_exp of 0.3~0.1).

I think I confused which setting I needed to hit to disable the batch sampling. I thought it was log_bat_opt[0][ but is it actually log_bat_mask[0]? Do I need to re-collect with this off?

82

So I think what I should do is get a log where I replicate the sound clearly, have the 100Hz filter and the FFT doesn’t show a huge 174Hz noise spike. And if I do replicate it, I’ll try 50Hz filter. Does that sound like the right step?

I’m like 90% sure I remember this log (where I have a lower mot_spin) fits the profile with 100Hz filter, but I’ll get a fresh run later just to be certain.

https://drive.google.com/file/d/1tTzvQeqTk9d5Fc1zW3H_lbb-GnRqW5nc/view?usp=sharing

83

This may also be an ESC issue at low throttle. I am trying to work out if we get this problem when we make the PID’s incapable of commanding or reinforcing that grinding problem. If we can then it is unlikely that it is primarily a tuning problem. It could be:

  1. communication problems
  2. autopilot timing problems
  3. sync problems (BLHeli settings may help)
  4. ESC electronic noise problems.

You may have done other tests that make some of these options unlikely.

no, just turn it off so our logs are nicer.

84

Yes, sorry camping right now so internet access patchy

85

I got a log with 100Hz gyro filter, and with spin_min = 0.06 (instead of 0.1) and thst_expo = 0.6 (instead of 0.3). Definitely get that grinding sound and I see the oscillation in the rate log.

https://drive.google.com/file/d/1WkF4SeNCSQjkJ5AP-ZTd9g4xKuTtezyK/view?usp=sharing.

86

You are still getting significant feedback with those filter settings.

image
image1947×704 23.9 KB

Can you do the same test with 50, 25?