How to methodically configure and tune any ArduCopter

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

If you have very low noise copters then AGGR of 0.1 will often result in an overtune, but its also highly dependent on the environment. The theoretically best possible tune will be given by AGGR of 0.05 (5%) but this would only be in perfect conditions with a very low noise setup. 10% is a decent starting point that gives good results for a wide range of conditions, but like all parameters it can be changed for good reasons.

1 Like

I believe the noise you are referring to is where users can limit it using Dynamic Harmonic Notch Filters and the damper for vibrations. Is your definition of over-tune interchangeable with Amilcarlucas’s tighter tune?

I believe your 10% is equivalent to 0.10 (the default, highest). (10%*0.05)/5%.

I am not trying to play down the development team’s great, and contribution effort.
I have been fortunate to have the opportunity to configure and calibrate both the DJI A3 and Ardupilot drones. If not for DJI’s changes of business direction we would not have moved to Ardupilot or PX4 flight stack. I see the pros and cons of both.

For DJI A3, I usually configure and calibrate intensely and flight test together with the pilot and freeze the configuration parameters within a week. Fortunately, we have not caused the drone crash once. We cannot add external sensors to improve some flight conditions. Limited SDK capability. It is expensive, misleading documentation, language barrier, and support are not great.
For Ardupilot, I can never settle down with a set of parameters. The more I change the more I feel I do not know anything at all. We have crashed different sizes of drones a few times. Of course, before this methodically tuning guide we follow closely to the Arducopter web document. Many unselfish users are willing to give help.
Of course, in both cases, drone frame stiffness, CG, motor overall level, and vibrations contribute to the performance of the flights.

1 Like

Hi andyp1per, thanks for that we live and learn every day and become more knowledgeable

I am offering an in presence Workshop on the 13.03.2024 at IAV GmbH.

It has the advantages that only an in presence Workshop can offer.


I have some questions regarding step 3.2 Configure the throttle controller. I tried this yesterday on an Octocopter based on the Tarot X8, with a MOT_THST_HOVER of 0.24. Based on the recommendation I set PSC_ACCZ_P to 0.24 and PSC_ACCZ_I to 0.48. But with this setup I experienced oscillations.

Based on the assumption that a lot of inertia reacts slowly I significantly reduced the I Term and reached an acceptable behavior with PSC_ACCZ_P of 0.5 and PSC_ACCZ_I of 0.2. Now if I stop the ascent there are two slight oscillations visible. Only during takeoff it seems a bit dangerous, because the drone lifts off to approximately one meter, comes to a halt or even drops down a bit before ascending further.

Afterwards I read in Initial Tuning Flight — Copter documentation that if there are oscillations I should halve the value PSC_POSZ_P and PSC_VELZ_P. Should I now go back to the recommended values for the acceleration or just keep my values? Maybe this should also be added to point 3.2?

Edit: Thinking a bit about it seeing the plot I would say that my P is to high… Which would conclude to me that I should go back to the recommended values…

1 Like

May I know what is your SURFTRAK_MODE and PILOT_TKOFF_ALT values currently? Have you mounted a downward-facing optical flow or rangefinder sensor?

1 Like

Those values are both at default, so SURFTRAK_MODE is 1 and PILOT_TKOFF_ALT is 0. There is no optical flow or rangefinder present.

1 Like