AutoTune in 32inch quad result in strange PIDs, crash in next flight

I am in the process of building a 32" quadcopter. I have already done the initial tuning process, then a manual PID tuning, and finally I configured the harmonic notch filter. After this the quad was already able to fly and navigate on its own, not in the best or most accurate way but in my opinion well enough to be able to proceed with the AutoTune. For this first attempt to perform the autotune I configured the parameter AUTOTUNE_AGGR = 0.05, so that the process would not be too aggressive and could end in a crash. After about 20 minutes the process was successfully completed.

The first indication that maybe something was wrong was when I landed and the autotune parameters were saved, after that a PreArm error started to appear.

Capture

To get this PreArm error to clear I had to lower the ACRO_BAL_ROLL/PITCH values from 1 to 0.6.

Next I rebooted the flight controller and took a look at the new PIDs values. At first glance I found them to be very strange, P gains that in my opinion seemed very low and a brutal difference between the Pitch and Roll values, although the frame and the mass distribution is quite symmetrical.

Here is a picture of the PID values before and after AutoTune.


PIDs values pre AutoTune.


PIDs values post AutoTune.

Despite this I tried flying once again with these values. Just after takeoff the drone tip over an crash.

Any recommendations on how to proceed with the tuning of the drone? Any feedback on the PID values resulting from AutoTune? Could someone confirm that they are too low as I think they are? Should I try to make an autotune with a higher value in AUTOTUNE_AGGR, in order to try to obtain higher gains?

I add below some extra details about the drone and I attach the LOGs .bin corresponding to the flight before the AutoTune, the flight of the AutoTune and finally the flight after the AutoTune in which the crash occurred.

I would really appreciate any feedback on the subject.

Hardaware Specifications:

  • Battery: 12S - 34Ah

  • Motors: 100kv

  • Propellers: 32"

  • Total weight: 17kg

  • FC: Cube Orange

  • AC version: ArduCopter V4.0.7

LOGs: https://drive.google.com/drive/folders/12Xuvm-OGdEj-W3KmyOLHAfsQG-pTV-4F?usp=sharing

Did you autotune in Loiter or did you autotune in AltHold?

I invoked the autotune from Loiter.

The Angle Pitch P is way too low. The Rate Pitch P&I also. Your manually tuned parameters (pre-auto tune) look pretty good. I would say go back to manual tuning if you want improvement or try aggression at .1

And do it from AltHold, the results are better

UPDATE:

Finally, after repairing the damage, restoring the PIDs, adjusting some parameters and making a crude manual tune the drone is now flying well enough. I attached logs with this new tune at the end of the post.

The problem was definitely caused by an autotune with the AUTOTUNE_AGGR set way to low, that resulted in a bad tune with ridiculous low values for the PID gains. Then, me failing to recognize that the values were completely wrong and trying to fly with them, leading to the crash.

One of the parameters that I also changed for this new tune, was the MOT_THST_EXPO. At firsts this parameter had been set to 0.8, as suggested by the “Tuning Process Instructions” in the Ardupilot Wiki. This value of 0.8 is set to be a good approximation for a 30” diameter of propeller. But I was not very confident about the reliability of the parameter as the powertrain I was using is a combo motor/ESC and I was afraid that it might be compensating in some way for the exponential response of the motor thrust. So, I tested the motor/ESC in a thrust stand, collect the data and experimentally calculated the correct value.

The result was a MOT_THST_EXPO equal to 0.4, way different to the original 0.8, and also very low for almost every size of propellers, as shown in the graft of the “Tuning Process Instructions”.

In my opinion this also confirms my suspicions that the ESC was somehow compensating for the motor response.

The result of the calculations is presented below.

Capture2

At the end, I also do not know whether the effect of the adjustment of this value is appreciable or not. But the drone is flying and the mistakes are not going to be repeated hahah

LOGs: https://drive.google.com/drive/folders/12Xuvm-OGdEj-W3KmyOLHAfsQG-pTV-4F?usp=sharing

That’s interesting, which ESC’s? The Tune looks good.

It is a T-Motor combo, that comes with their “pre-made” drone chassis. The motor is a U8XL KV100 (which don’t even exist in their normal catalog). And the ESC sits below the motor in the motor mount, that is all I know about it. Little to none information is available about the combo, not even after purchasing it and asking for info.

Regarding the tune, it flies well enough, but I would like it to fly better. Also i am not use to the big size and the inertia it has.

That’s true of everything T-Motor. I did ask them if their ESC’s have a thrust linearization feature and they did reply to that saying they do not have this function. But on the other hand it has been suggested to lower MOT_THST_EXPO on certain T-Motor ESC’s and good results have been realized.

Yes, have also read posts about lowering the expo in T-Motor flame ESCs, that was the main reason why I began suspecting about mines. And in my case, based in my experimental results I can confirm that there is some sort of linearization being made in the ESC.

Hard experimental data is valuable information!

Thinking more about this it does make sense that they would have this feature for a Motor/ESC assy but that it wouldn’t necessarily make sense for a discreet ESC which could be used on a range of motors from different manufacturers. So perhaps it’s only one data point, don’t know.

1 Like

That thought also crossed my mind, and for my case, in which you have a Motor/ESC combo that is indivisible, and where is almost impossible to take it apart and use it with other different hardware, here can make a little sense. You will obtain a system with a more linear response which is always desirable. But you must tell the client!! Otherwise, as we are doing, we compensate for something that is already compensated.

And besides, as you said, compensating for an exponential response in a system that you have not fully characterized (because it is an incomplete system to which you can attach any motor) does not make any sense to me.

1 Like

@Matt_C yes the tunning results will be better because it properly “waits for level” before testing new PID values. I already oposted about that in some other threads, and gave more details why it is so.

Here is more info: https://github.com/ArduPilot/ardupilot/pull/16471

I had to manually tune a very similar (or maybe the same) copter as yours, because autotune did not produce an acceptable result. I also lowered the MOT_THST_EXPO, which gave me trouble especially during takeoff/landing.