Two crashes with an overpowered drone

Hi guys,

I have had a couple of crashes with my big coaxial octocopter, both of then following a very similar pattern. Here is my setup:

  • FRAME: Gryphon Dynamic XQ1400 SP
  • MOTOR: T-motor MN801 120KV
  • ESC: T-motor Flame 60 AHV
  • PROP: 28 "
  • BATTERY: Tattu 12 S 22.000
  • FC: Pixhawk Cube
  • FIRMWARE: Copter 3.6.8


In this case, the CUBE was soft mounting, because I was noticing high vibrations. The mounting was designed following some advices from the Cubepilot community (I know that is better to have it hard mounting, but the vibrations in my case is high). I managed to complete an autotune with 4 batteries (20 kg AUW), then I tried an endurance flight in loiter with two batteries (AUW about 15 kg). Almost at the end, I input a small pitch with my transmiter and it got uncontrollable for 5 second, before it recover controllability and managed to land it, so it was not a crash, but barely. Here is the log:



Following some advices, I did ESC calibration, and reduce the params MOT_SPIN_ARM = 0.8 and MOT_SPIN_MIN = 0.11. I also change MOT_THST_EXPO = 0.18. With this new params, I tried this time a new autotune with the CUBE hard mounting and two batteries (remember, last time I run Autotune with x4 batteries and then swap to x2 batteries, which was when the uncontrollable event happened). This time, the autotune finishes ok the roll axis, but after the first twitch in the pitch axis, it got uncontrallable (as the first crash), but this time it touched the ground. Heres is the log:


It is curious that both event happened with x2 batteries (i.e with 15kg AUW and a hover throttle of 17 - 20 %), which make me think that the overpower issue may have something to do.

I also dont know if the first crash was provoked by those “weird flight behaviour” that may happen when you soft mount the Cube. The mounting have the COG of the cube very low, as recommended, even if is not ideal to soft mounting the cube.

Hope you guys can help me with this,



You need to tune the aircraft with ALL of the intended payload weight aboard.

The low throttle didn’t cause the crash but it did contribute to it. What caused the crash was lack of resolution between hover and full low throttle. In this configuration the motors are not “up to speed” and the lack of resolution, motor/prop inertia and aerodynamic drag gang up and make it difficult for the flight controller to do its job.

Ideally you want the throttle to be as close to 50% as possible when the aircraft is in a hover. This gets the motors up to speed and gives the FC plenty of “throttle room” to work with. You will also find that the aircraft will be more stable, more responsive to pilot inputs, and it will not wallow through maneuvers.

Hi Juan,

The cause of the crash during auto-tune is a poor tune on Pitch. The pitch test excited a large recovery that caused an oscillation. I suspect one of the main issues here is that ATC_ACCEL_P_MAX and ATC_ACCEL_P_MAX are set way too high for your aircraft. I suspect they should be more like 30000. During initial tuning it may be wise to use a value of 15000.

You are also playing with MOT_THST_EXPO. What is your thinking behind changing this parameter?

I am sorry but this is not correct. Aircraft should always be tuned using the minimum payload. This will result in a more stable tune when you add payload (assuming a fixed payload) because the inertia of the aircraft has increased. Tuning the aircraft at full load then removing that load can result in a dangerously unstable aircraft and high hover throttle that can then cause a fly away.

I have been there and I have done that.

I stand by what I said.

I wrote the control and navigation code and tune aircraft for a living.

Sorry you are wrong.


So it is better, for example, on my 25kg quadcopter to remove the 7 kg payload to do the autotune? If so i’ll run it again. I have done it with payload attached since it’ll nevet fly without, but if i understand it correctly if i remove the payload for whatever reason i could run into trouble.

If you are never going to remove the payload then keep it on as that will tend to give you a sharper tune for that payload. Just keep in mind that if you do remove it or change it the tune may be unstable or a little over tuned.

Ok thanks for your advice!!

Seriously? What happened to your minimum payload rule?

Are you really questioning the person that actually wrote the software you fly?


I said one should tune with the full intended payload aboard. I was told I was wrong and that tuning with a minimum payload aboard is “better” because it will produce a more stable tune. He goes on about tuning with full load and then removing the load will make the aircraft unstable. Then he tells you to tune with the full payload. So which is it?

I built each of my aircraft to serve a specific purpose. Each aircraft has a unique fixed Take Off Weight (TOW). Each aircraft was tuned at that weight. My aircraft are stable, their handling and flight characteristics are consistent, and their flight times are repeatable. Is that not what tuning is about?

I think it makes perfectly sense. If you never remove the payload than tuning it with payload is the way to go. If it happens to remove and fly without payload than it is better to tune without. This is what i understand and if it comes from the person who develops the math behind it than i take it for good :slight_smile:

If you are never going to remove it that would be the minimum payload wouldn’t it.

If you are never going to remove the payload then you don’t need to worry about it becoming unstable without that payload do you.

As I said, this is wrong. Tune with the minimum payload.

No, I said if you are never going to remove it then it is safe to tune with it. (Because that would then be the minimum payload).

No, that is my idea of getting an aircraft flying before I start tuning.

To summarize for everybody:

  • Increase in aircraft weight tends to allow higher PID values.
  • Tuning with a payload and removing it can result in an unstable and therefore dangerous aircraft tune.
  • So the general rule is tune without your payload or at your minimum payload.

If you are never going to fly without your payload or you have a fixed configuration that will never change then you can safely do autotune in that configuration (your minimum payload).

The one thing to be careful about here is if your payload is on a vibration mount or is flexible. This can result in Autotune giving you a bad tune. Here you may benefit from a tune without the payload. Even then a flexible payload or vibration mount may interact with your controllers to cause oscillation. So be careful with any flexible payload or payload mount.

The other thing to remember is batteries are payload so if you intend to fly on a partial battery load it is a good idea to tune it without payload and with the partial battery load.

Generally a good autotune will be so sharp that you will never notice that it is softer at full payload.

That reminds me. An extremely important exception to all this. While you should tune the aircraft for minimum payload you should set your ATC_ACCEL_XXX parameters for the maximum payload you intend to fly. A good rule of thumb would be to reduce the values given by Autotune by
MinTOW / MaxTOW.

To give you an idea I reguly achieve a 4:1 max TOW to min TOW without any tuning changes over the full battery voltage.

If you follow these general guidelines then you will give yourself the best chance of achieving a well tuned aircraft across a wide TOW range.

Another tip is make sure you set your MOT_BAT_VOLT_MAX and MOT_BAT_VOLT_MIN. I also recommend using MOT_PWM_MAX and MOT_PWM_MIN so you don’t have to recalibrate your ESC’s if you connect a different radio.


I get it. It all depends on what your definition of “is” is.

Interesting explanation. What is TOW please?

Take Off Weight. Also known as AUW, or All Up Weight.

I think this was long overdue.


I have seen a request for a Wiki Dev weekly chat.
Do you know WHERE this weekly Dev chat is?
It wasn’t evident in Mumble where I assumed it would be.

I am happy to pitch in, just need to know the details of where and when (still Wednesday version of the Dev chat?)

I just asked Randy and he told me “there’s a wiki meeting on Wednesday mornings… same time as the dev meeting but on wed instead of tuesday”

So it looks like you may have hit one that was canceled or something.

1 Like