Autotune crash

My attempt at autotuning resulted in a crash this morning.

I fiew the quadcopter previously with a 2S battery. It was quite stable but underpowered.

After upgrading to a 3S battery I set the PIDs to what I believe is the default values:

Stabilize P: 4.5

Rate P: 0.15

Rate I: 0.1

Rate D: 0.004

Taking off and switching to Alt Hold went smooth. I then switched to Autotune and nothing happened. I believe this is because I had the throttle still a tad above hover. Closing the throttle down slightly to get it in the hover range started autotuning and on the first or second autotune roll it started oscillating ending in a crash. I was way too slow to recover it.

The way I read the log file, theses values were used for autotune:

Stab P: 4

Rate P: 0.2

Rate D: 0.005

Dataflash log attached. No CoG issues. Props and motors tuned recently, so low vibrations.


My primary question is:

What caused this crash?

My theory is that the motors may now even be slightly overpowered and I guess that an average PID settings may caused it to respond too violently. But I would appreciate if anyone else can confirm that from the log or share their own experiences.

Secondary question:

Is there a way to tell autotune to cool things down a bit and use a range of lower PID values?

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


    • Developer

      Hi Jack,

      This is very strange. The first thing I would look at is why you lost a prop. You may not have the props tightened up enough and the sudden throttle change may be making them slip.

      It doesn't look like you have included a log.

      Chat soon,


    • The log is too big for the 7MB limit. I have chunked it up now using WinRAR.


      2016-02-06 08-11-55.z02

      2016-02-06 08-11-55.z01

    • ...and the 4th and final file...

      2016-02-06 08-11-55.z03

    • Developer

      Hi Jack,

      There is something not right going on here. Normally when you do an autotune induced oscillation your oscillation is in the axis you are tuning. In your case your oscillation is in both roll and pitch. This is because the axis not being tuned doesn't move and there is nothing to get it oscillating.

      In your case the pitch axis error is over half that of the roll error and becomes equal on the second period.

      The other thing that is unusual is normally the tuning twitch moves the copter in one direction, for this example, to the right. The copter then corrects hard to the left and overshoots to the left. In your case it is keeping going right and forward.

      This looks like the front right prop is coming loose or the motor is stalling on the first test and the rear left on the second.

      Could you please provide some photos and specs of your copter? (motor, prop, size ext.)

    • Hi Leonard,

      I get what you're saying about the pitch axis oscillation being unusual when the twitch was on the roll axis.

      What I struggle to see is where you got the information from that it kept going right and forward. I probably look in the wrong spot, but if I plot roll and pitch I see this. To me it looks like it overshoots trying to correct like you described it normally happens.


      I also gave some thought to the propeller that came off. On the propeller that cam off, the collar nut didn't loosen up as I anticipated. It is still fully tightened

      and I have a lock not on it as well. It came off the motor shaft, but I cannot push it back onto the shaft even with reasonable force by hand. I cannot imagine that it just got pushed off the shaft. I think during the first crash the propeller probably came into contact with the ground while the motor was still spinning and because of this the shaft slipped in the collar and slowly moved the propeller / collar outwards. On the second flight it was probably just hanging on on the tip of the shaft and just waited for the right moment to came off. My biggest mistake was not terminating the flight after the first flight and checking everything over.


      Thanks for the info on the thread locker and damping mount. I did have some vibration issues early on and because of that I did 2 things:

      1. I found that the collars aren't true like you said. I balanced all props and motors but found that the biggest influence in dynamic balancing was the attachment between the props and the motor. So I ended up doing real time vibration monitoring on Mission Planner and keep on turning the prop on the shaft until I got the lowest vibration for every individual motor.

      2. I did experiment with some dampening on the pixhawk and ended up mounting it on the 4 corners using about 3mm thick foam tape. It did a reasonable good job of dampening vibrations. But I did observe as someone else pointed out as well that during the oscillations I experienced the vibrations went up as well. Maybe the dampening is too soft and allows it too much movement? Do you have any comparisons between the dampening mount and foam tape?


      On the autotuning: I got a fairly unstable setup after switching my 2S battery for a 3S one. So it was clear that I required some tuning. I did some manual tuning that performed fairly well, but I think autotuning may do a better job and I can see some benefits if I change the hardware that changes its weight / balance it would be beneficial to tune again for optimal performance.

      Going forward, I think I will step back a bit and while doing the repairs post some photos on what I'm doing to make sure every step is solid. I also think there is no reason I cannot do the autotuning on the bench instead of risking another crash. I will post some information as I go. First step would be to remove the broken components. I will then post some photos on the base I would build on.

      Thanks for everyone's advice.
    • I think you hit the nail squarely on the head...

  • @Jack,

    could you attach all log files ?

    To study true nature behind your ddrone crash I need to know technical specifications

    for every hardware item installed on your drone.

    I need to know at what frequency is clocked your GPS, IMU, Compass, every sensor

    and at what frequency is run PID loop and how PID loop is implemented.

    I need wire frame for PID, maybe one of developers could be of help.

    Earlier or later I hope to find true nature of Drone Fly-Away Syndrome and Drone Fly-Away Crash but I need your cooperation.

    At FabLab we plan to set up Drone Labs to study every drone crash case, if anyone is interested.

    In the meantime pls join

    Peer To Drone Crash Investigators


    • Hi Darius,

      I am using a Pixhawk controller. As far as I could figure out the dataflash log file (includedin the first message) is as detailed as it gets. All the configuration parameters are included at the start of the file. I am using a Pixhawk controller. I still have all the other files, but I think they all get wrapped up in the log file. Most of the hardware specs for the components can be googled.

      Let me know if you need any specific file or bit of technical detail.

  • From an Auto Analysis:

    Size (kb) 3650.150390625
    No of lines 46173
    Duration 0:02:32
    Vehicletype ArduCopter
    Firmware Version V3.3.2
    Firmware Hash 7f16e4d6
    Hardware Type
    Free Mem 0
    Skipped Lines 0

    Test: Autotune = NA -
    Test: Balance/Twist = NA -
    Test: Brownout = GOOD -
    Test: Compass = GOOD - No MAG data, unable to test mag_field interference

    Test: Dupe Log Data = GOOD -
    Test: Empty = GOOD -
    Test: Event/Failsafe = FAIL - ERR found: CRASH
    Test: GPS = FAIL - Min satellites: 0, Max HDop: 99.99
    Test: IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 1.77, WARN: 0.75, FAIL: 1.50)
    Test: Parameters = GOOD -
    Test: PM = NA -
    Test: Pitch/Roll = NA -
    Test: Thrust = NA -
    Test: VCC = GOOD -

    • Hi Clifton?

      How do you interpret the Auto Analysis?

      If I look at the 'FAILS':

      1. Even/Failsafe shows 'CRASH'. I know this bit already. I'm interested in what caused it.

      2. GPS: Well spotted. I did not notice it as I did not have live telemetry during this flight. But as far as I know the GPS is not used by Altitude hold or Autotune. Should be investigated, but I don't think it contributed to this crash.

      3. IMU issues: The vibration graph seems fine up to the point where the oscillation starts. There appears to be a correlation between vibration / roll oscillations, but I think the vibration may be a consequence and not a cause.

      What do you read in this analysis?

This reply was deleted.