How to methodically configure and tune any ArduCopter

Thank you, I will do this calibration!

1 Like

Yes, the biggest drone we ever built is a 1.88m wheelbase drone, so in a small country with limited flying space, is too fast.
Seem like from the reply and MP GUI, besides break delay, I should keep the rest to the default value and only bring down the speed and break delay.

Is the outermost position control loop referring to the PSC_n parameters in the image below? MP GUI only exposes these few PSC values, PSC_POSXY_P, ATC_INPUT_TC, PSC_VELXY_D, PSC_VELXY_I, PSC_VELXY_P, PSC_VELXY_IMAX.

In most of our previous drone configurations before this tuning guide, we keep PSC_n to the default values, except PSC_ACCZ_I to 2 x MOT_THST_HOVER, PSC_ACCZ_P to MOT_THST_HOVER.

How common and rare do users need to change these PSC_n parameters? If after autotune, under Loiter flight mode, the drone twitch during mid stick, do we change these PSC_n values? If not, what should we do next? What other possible causes? Will a wrong set of Loiter parameters configuration cause the drone to twitch? The seasoned pilot feels the autotune parameters are okay under alt-hold flight mode for the 23-inch quad 1.2m wheelbase drone.


we shall try these below values with the rest of the PSC values keep to the default except PSC_ACCZ_I and PSC_ACCZ_P. I hope is not due to Limit Cycle Detection issue, currently, all n_SMAX are zero. no other PSC values are mentioned in suggested to change.

1 Like

Those are very good questions @Jai.GAY . Thanks. I’ll answer them when I’m back to the office. It’s a lot of questions and I need a proper keyboard (currently mobile :iphone:)

1 Like

No, you start with those, test, and then iteratively set the others described in the 41_position_controller.param.

Yes, all PSC_n parameters. Both exposed and not exposed in MP GUI.

Yes, that is what most users need. But if you want performance you do need to tune them properly.

The vehicle will only oscillate in loiter flight mode in rough winds or when autotune did not worked.
Autotune works best with no wind. So my guess is that your autotune did not work well because of this.

Yes, it will.

I appreciate you taking the time to thoroughly understand my questions and the replies. Will set up a new test plan based on your input and test flight when the weather turns good after the country festival season.

on a separate note.

When looking at vibrations in a log the first thing to look at is the clipping. If the clipping is 0 that’s good. That means the vibrations that are being detected aren’t overwhelming the IMU.

Should the users based on the clip or the 30m/s/s (best below 15m/s/s) as the golden rule? It is extremely challenging for a big drone with foldable arms or attachable arms to achieve less than 15m/s/s. We can achieve that for a smaller drone with fixed arms to the drone body.

Hi users

Has anyone used a vibration damper before? how effective to reduce vibrations? What can cause it to get worse?

1 Like

@ I appreciate your efforts!!! :grinning: :+1:

1 Like

Users should use BOTH: Below 15m/s/s as the golden rule, and look at clipping. Like I said:

Yes, I agree it is challenging that is why I wrote section1. If you can not solve the challenges, I suggest you find help to do it.

Again section 1. It can be very effective if it is tuned. A vibration damper has a certain elasticity that must have a certain value depending on the mass, and the frequencies you need to dampen.

If that elasticity is incorrect it might amplify the oscillations it is meant to dampen. And so be VERY counterproductive. Again if you can not fix it, get help, there are people that can fix it for you.


We update and improve the first post on this thread using the feedback of the users.

So we would like to thank you all for your feedback.

I would also like to thank Jan Ole Noack for helping in the formalization of this method during both his Studienarbeit (Student thesis) and Bachelorarbeit (Bachelor thesis) at Ostfalia Hochschule für angewandte Wissenschaften (University for applied Sciences) in Wolfsburg, Germany. He helped in testing, writing, hardware construction, flight testing, brainstorming, streamlining and some more testing. Thanks goes also to Professor Susanne Steiner for guidance and counselling in both thesis.

I would really like to see your edited .param intermediate files (again, excluding the 03_imu_temperature_calibration_results.param , 11_mp_setup_mandatory_hardware.param and 20_inflight_magnetometer_fit_results.param ) in a .zip file.


Thanks for the extensive guide. I’ve build several Arducopters, but there are lots of things here I hadn’t even heard of!

Just one thing: I really wouldn’t recommend Diatone motors - worst quality I ever had. On 2 out of 4 motors the shaft got pushed in, simply during prop change. I’d suggest replacing them in the list of suggested parts by something like Emax Eco, which are also very budget-friendly and rock-solid (from my experience).


Thank you both Amilcarlucas andJan Ole Noaak for all the work you put into this and the help you give the community and also a big thank you to the Professor Susanne Steiner for allowing this to be done,amazing work and really appreciated by me,Once again thank’s.


The quality of our motors seems solid so far, nothing to complain about.
Regardless of that, we recently had issues with the ESC that took one motor out with it and since we can’t get a replacement atm, we are switching to t-motor F1507 3800kv. Testing and quality assessment will be done as soon as they arrive and we’ll update the guide then. And yes, they are bigger and more powerful than the original 1404 motors, but every 1404 motor we can get right now has a 9x9mm mounting pattern, which is too small for the Taycan frame which has a 12x12mm motor mounting pattern.

[Edit] lots of changes of plans.

Emax Eco are a good suggestion, unfortunately they are hard to get in Germany, either with shipping time >1month or not budget-friendly with 21€/motor. [Edit] Also they don’t fit the frame like all the others.

1 Like

I’ve forwarded it to her :smiley:

1 Like

The online and offline calibration both have significantly slightly different results. Which one we should go with?

The off line tool, because you get feedback on the quality of the compensation, and it provides better results.

Why do we need to calibrate the IMU before performing the Temperature calibration?

You do not. where have you read that?

and if I again re calibrate the IMU after performing the Temperature calibration then will it create any issue?

No, it will not:

  • IMU temperature calibration compensates temperature-dependent drift
  • IMU calibration compensates missaligments

Those are two different things.

As per I understand the Tempt calibration will calculate the IMU offsets based on the temperature change and could be helpful in the FC which do not have inbuilt heaters.

Yes, but it is helpful on the ones with heaters as well.

As my FC has inbuilt heater and it is going to heat the IMU at 45C no matter what is the outside temperature. So for me does the below 45C offset really make any difference?

Yes, because most users do not wait one minute before takeoff for the temperature to stabalize. Or do you do it? And never forget it? Even after changing batteries?

Thanks for the questions @scientist_bala , I hope it is clear now.


Regarding temperature cal, I just did an onboard calibration for my EDU450 (Cube Orange) using 4.5 beta1, and I may have encountered a bug.

During calibration, BRD_HEAT_TARG seems to be disregarded in favor of INS_TCAL1_TMAX.

I tried two different calibrations, one with BRD_HEAT_TARG=70 and one at 75.

During the first, INS_TCAL1_TMAX had been set to 65, and with the second at INS_TCAL1_TMAX=70.

Each time, the target temp followed TMAX rather than HEAT_TARG, making it a bit awkward to properly set the TMAX parameters to sensible values.

Thus, on the first attempt the calibration took a lot longer than expected, and IMU3 actually timed out at 48 degrees because the heater was only maintaining 65 rather than ramping to 70.

I have been reading posts from some expert users or developers that by setting AUTOTUNE_AGGR lower than 0.1 (range 0.05 to 0.10) high chance of producing a poor tune. Is the statement valid? So, my question is when will 0.075=medium, 0.050=weak ever used? Is it when the drone is 300kg, AUTOTUNE_AGGR will have to be set lower? If there is no forward-looking outcome for below 0.10, should the parameter be removed and hard-coded to 0.10, or default and lowest be 0.10? Curious.


@Yuri_Rage I think that is a feature. It lets you calibrate in a wider temperature than the one you will use in the end.

Set INS_TCAL1_TMAX to be a bit above your targeted BRD_HEAT_TARG. then calibrate, once done the lower BRD_HEAT_TARG is used as target and the temperature will always stay inside the calibrated interval.

1 Like

Yes, the statement is valid, wind causes havoc at low AUTOTUNE_AGGR values making it more probable that you get a bad tune because of the higher sensitivity to small perturbations.

It will get used in very low wind conditions (inside an hangar for instance) when you want a not-so-tight tune.

No, it has to do with the level of wind and the desired tune aggressiveness (how tight should the control loop be)

No, it should not

1 Like

As a Scotish Hagis Dumpling I do auto tune on 1 max strength but only do 1 mode at a time eg ail,then ele etc time consuming but just works for me

Yes, @MartyMcFly using best practices is a good way of increasing the probability of success.

Being over-creative and trying to find shortcuts when there are none, skipping steps and flying too soon with an unconfigured system is a good way of increasing the probability of failure.

This is the message that many users did not get.


That seems like an ill-conceived feature, then. The usual method for temp cal is to set the heater target 5-10 degrees warmer than the intended TMAX, which ensures that you hit TMAX before a timeout.

If the target is implicitly set to TMAX, the integrators wind down as you approach TMAX, and you risk timing out on one or more IMUs as the rate of change slows.

Sure, you can overcome this, but it seems like an odd “feature.”

1 Like