How to methodically configure and tune any ArduCopter

[aleks_od (Aleksandr Shunin)]

Thank you, I will do this calibration!

[Jai.GAY]

@Curly_Fork

Do you find 12.5m/s too fast?

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.

@amilcarlucas

And only after that you tune the outermost position control loop.

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.

PSC_ACCZ_D
PSC_ACCZ_FF
PSC_ACCZ_FLTD
PSC_ACCZ_FLTE
PSC_ACCZ_FLTT
PSC_ACCZ_I # 2 x MOT_THST_HOVER
PSC_ACCZ_IMAX
PSC_ACCZ_P # MOT_THST_HOVER
PSC_ACCZ_SMAX
PSC_ANGLE_MAX
PSC_JERK_XY
PSC_JERK_Z
PSC_POSXY_P
PSC_POSZ_P
PSC_VELXY_D
PSC_VELXY_FF
PSC_VELXY_FLTD
PSC_VELXY_FLTE
PSC_VELXY_I
PSC_VELXY_IMAX
PSC_VELXY_P
PSC_VELZ_D
PSC_VELZ_FF
PSC_VELZ_FLTD
PSC_VELZ_FLTE
PSC_VELZ_I
PSC_VELZ_IMAX
PSC_VELZ_P

@amilcarlucas

13. Position controller

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 diatone_taycan_mxc.zip suggested to change.
LOIT_BRK_ACCEL,500
LOIT_BRK_DELAY,0.05
LOIT_BRK_JERK,4000
LOIT_SPEED,250
PSC_VELXY_FF,0.85

[amilcarlucas]

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 )

[amilcarlucas]

@Jai.GAY

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.

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

@Jai.GAY

Is the outermost position control loop referring to the PSC_n parameters?

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

@Jai.GAY

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.

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

@Jai.GAY

If after autotune, under Loiter flight mode, the drone oscillates …

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.

@Jai.GAY

Will a wrong set of Loiter parameters configuration cause the drone to oscillate?

Yes, it will.

[Jai.GAY]

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.

@amilcarlucas

Load the .bin log from the first flight onto the online Ardupilot Log Viewer or into Mission Planner.
Take a look at the VIBE.VibeX, VIBE.VibeY, VIBE.VibeZ graphs they all should be below 15

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?

[Saan_Choi]

@ I appreciate your efforts!!!

[amilcarlucas]

@Jai.GAY

Should the users based on the clip or the 30m/s/s (best below 15m/s/s) as the golden rule?

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

@amilcarlucas

• Vibrations over 30 are very bad
• Vibrations over 20 are causing issues even if you don’t know it yet
• Vibrations over 15 are in a grey area - it could go either way - check clipping, it must be zero
• Vibrations below 10 are good

@Jai.GAY

It is extremely challenging for a big drone with foldable arms or attachable arms to achieve less than 15m/s/s

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.

@Jai.GAY

How effective is a vibration damper at reducing vibrations?

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.

@Jai.GAY

What can cause it to get worse?

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.

[amilcarlucas]

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.

[UnknownPilot]

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).

[MartyMcFly (MartinKeilloh)]

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.

[Janno (Jan Ole Noack)]

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.

[Janno (Jan Ole Noack)]

@MartyMcFly

also a big thank you to the Professor Susanne Steiner

I’ve forwarded it to her

[amilcarlucas]

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.

@amilcarlucas

The graphic below depicts the accelerometer drift versus time and the board temperature versus time. The temperature curve, depicted in black, is logarithmic as expected. The other curves are smooth, proving that the flight controller was not moved in the process and the calibration is valid. As can be seen, before the calibration temperature changes caused a big change in accelerometer/gyro drift. After the calibration, temperature changes will cause no significant accelerometer/gyro drift changes.

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.

[Yuri_Rage]

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.

[Jai.GAY]

@amilcarlucas

Autotuning in low-wind conditions is desirable, but if that is not possible you can increase the AUTOTUNE_AGGR parameter value to 0.110 or even 0.120.
That is a workaround and will not produce as good results as low-wind conditions autotune.

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.

[amilcarlucas]

@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.

[amilcarlucas]

@Jai.GAY

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?

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.

@Jai.GAY

when will 0.075=medium, 0.050=weak ever used?

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

@Jai.GAY

Is it when the drone is 300kg, AUTOTUNE_AGGR will have to be set lower?

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

@Jai.GAY

should the parameter be removed and hard-coded to 0.10

No, it should not

[MartyMcFly (MartinKeilloh)]

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

[amilcarlucas]

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.

[Yuri_Rage]

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.”