APM 2.6 CRASH, Log files attached

Hi, I had a bad crash with my Hquad, was running V3.1 firmware at the time.


Apm 2.6+ gps/compass combo.

Hk h4 frame

ipower 2814 750kv motors

12x3.8 props

Hk blue series 20a esc's

5000mah zippy 4s lipo

AUW was about 2200g with brushles gimbal and i had an average flight time of 16 mins

I flew one battery pack fine, no problems,

Second pack i was half way through, had about half the battery power left. 

I came down to maybe 15-20 feet, everything was fine, then suddenly the copter started wobbling, violently, and literally fell out of the sky.

I parked up what i could find and didnt touch them for months(lost my gps module, lost two motors, lost my fpv gear.)

I put in tons of time and effort, modifying my frame, making custom vibration mounts, adding a brushless gimbal researching motor+prop+power combinations etc etc, was pretty proud of myself. I was pretty bummed. 

Then that crash happened....more or less totaled the frame, was kinda down about it for a while. Now im ready to rebuild, but I have no idea what happened that day, why it just fell.

M battery wasn't dead, I had an osd with a voltage reader, double checked everything.

I have also since then, tested all of my escs, they work fine.

The flight logs don;t have IMU data, disabled that as i read somewhere that its cpu intensive.

I am unable to understand much from the flight data besides checking the map, and seeing if my vibrations are within tolerance levels. Can someone here help me understand what happened? maybe? I have attached the last two logs, one right before the crash, and i believe the second is during the crash itself. 

Thanks in advance

2014-01-25 02-40-07.log

2014-01-25 03-23-52.log

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

Join diydrones

Email me when people reply –


  • I had a violent wobbling like you mentioned on a failsafe with v3.2 firmware. It was a gcs failsafe though. I am not sure if the failsafes can cause the same problem, but there was a change to the events.ino file recently that can cause it to wobble. hal.rcin->clear_overrides(); and failsafe.rc_override_active = false' may have caused the problem. After I made a few changes to that file and added a hal.rcin->setoverrides(); then it would land properly in failsafe mode. You might want to try some other firmware and then test your quad's failsafe modes while holding it in your hand to be sure that it isn't going to wobble again.

  • Not sure why the GPS failsafe'd because you still had 11 sats and a low hdop when it triggered, even tho it was bouncing around.

    Forgot to attach the MP log Analysis:

    Log File D:/20140125024007.log
    Size (kb) 486.20703125
    No of lines 7174
    Duration 0:03:26
    Vehicletype ArduCopter
    Firmware Version V3.1
    Firmware Hash 5c6503e2
    Hardware Type APM 2
    Free Mem 1008
    Skipped Lines 0
    Test: Autotune = UNKNOWN - No ATUN log data
    Test: Balance/Twist = GOOD -  
    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 = GOOD -  
    Test: GPS = GOOD -  
    Test: Parameters = GOOD -  
    Test: PM = GOOD -  
    Test: Pitch/Roll = GOOD -  
    Test: Thrust = GOOD -  
    Test: VCC = FAIL - VCC below minimum of 4.6v (4.4v)


    • First off thank you so very much for taking your time to help Mike, and anyone else.

      I have no idea why a GPS failsafe happened. Only failsafe i had set up was through my frksy receiver. A signal loss failsafe that centered sticks and switches the mode to RTL. The actual APM failsafes, were disabled. From what you've spoken about with the voltage dropping below the minimum, can that be the cause of that eratic behavior? I powered the apm from a bec from one off my esc's. The other three esc's, i cut out the +ve power line. So i guess my 1st step would be using a amp power module.

      • I don't understand why the failsafe was triggered either. Your gps conditions were changing but you never went below 10 satellites and an hdop always less than 2. Do you know that there are failsafes now in multiple locations in MP config/tuning? I had a a similar problem and it tripped RTL and started to rise up to the return altitude. I was watching for something like that and flipped into Stab, I had not disabled all of the different failsafes. I had missed one.

        The change to powering off a ubec or 3DR power module is a very good idea. I can easily imagine a bec dropping voltage when the motor it is attached  to demands a large surge of current.

        John I think you are talking about parameters in the include files to compile the firmware? I assume these settings are not available in the advance parameters list in MP? A recompile with the changes is required?

        I am also not sure what you mean by a "gcs failsafe" ( a failsafe caused by having mission planner connected while in flight?) vs a "failsafe".


        • It is a good idea to test your quad with a new bec or 3dr power module to rule out the voltage issue, but I am not certain that was the cause of the wobbling. I think that it could be the autopilot trying to stabilize the quad while the throttle or power is low or there could be a delay. I don't understand the firmware code as well as the developers do, but I have seen wobbling before on a good autopilot. Mike, it is a firmware source file that has to be compiled, so yes a recompile would be required. For gcs failsafe I mean Ground Control Station Failsafe when the telemetry signal is lost. It is different than a gps failsafe, but I had a similar crash during that failsafe.

  • Nate,

    Since others are busy I took a look at your logs. I am not qualified by any means to advise so take my comments with "a grain of salt"

    First thing I noticed, because Randy pointed them out to me on my logs, is that your vcc is dropping out of spec. The voltage to the flight controller is dropping below 4.6v minimum to 4.4v. This could make the FC not operate correctly. Note the first graph.

    Second if you look at the GPS log right before the crash you trigger a GPS failsafe and the aircraft goes to land.

    If you look at the battery log, which tracks your throttle in vs the actual throttle out, it looks like your throttle commands are not being followed. You move the throttle but the FC does not react. I don't know how to tell but one reason for this could be that the aircraft was in an automated mode like Loiter or ALt-Hold where the FC has control of throttle. You tried to change it but could not because you were not in control the FC was. You would have needed to change to Stabize to gain manual throttle.

    So those observations are not much help but I would say that something triggered the GPS Failsafe and the FC enabled a land command, because your failsafe was set to land upon trigger. It was unable to land smoothing and crashed instead.

    This has happened to me too. I was watching it real carefully with my finger on the stabilize switch but even tho I realized it had triggered a failsafe I could not gain control before it fell.

    So no help in Determining why, unless it was the power issue, but maybe what happened.

    I know it is frustrating when you put so much time into the build but you gotta be persistent!





  • bump?

  • Nate,

    The first thing they are going to ask for is the right logs. You have posted the logs with .xml, look in the same directory with .log or .bin. Just trying to save you some time gettng your help. Here is the request I got when I made the same mistake:


    I think that's the .xml file that's sometimes created by the MP for some reason.   It's the .log or .bin file that's most useful."

    • thanks a lot, made the respective changes

This reply was deleted.


DIY Robocars via Twitter
RT @a1k0n: Did I get rid of hand-tuned parameters? Yes. Am I still hand-tuning more parameters? Also yes. I have a few knobs to address the…
DIY Robocars via Twitter
RT @a1k0n: I'm not going to spoil it, but (after charging the battery) this works way better than it has any right to. The car is now faste…
DIY Robocars via Twitter
RT @a1k0n: Decided to just see what happens if I run the sim-trained neural net on the car, with some safety rails around max throttle slew…
DIY Robocars via Twitter
DIY Robocars via Twitter
RT @SmallpixelCar: @a1k0n @diyrobocars I learned from this. This is my speed profile. Looks like I am too conservative on the right side of…
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars Dot color is speed; brighter is faster. Yeah, it has less room to explore in the tighter part, and t…
DIY Robocars via Twitter
RT @a1k0n: I'm gonna try to do proper offline reinforcement learning for @diyrobocars and throw away all my manual parameter tuning for the…
DIY Robocars via Twitter
RT @circuitlaunch: DIY Robocars & Brazilian BBQ - Sat 10/1. Our track combines hairpin curves with an intersection for max danger. Take tha…
Sep 22
DIY Robocars via Twitter
RT @SmallpixelCar: Had an great test today on @RAMS_RC_Club track. However the car starts to drift at 40mph. Some experts recommended to ch…
Sep 11
DIY Robocars via Twitter
RT @gclue_akira: 世界最速 チームtamiyaのaiカー https://t.co/1Qq2zOeftG
Sep 10
DIY Robocars via Twitter
RT @DanielChiaJH: Always a good time working on my @diyrobocars car at @circuitlaunch. Still got some work to do if I’m to beat @a1k0n howe…
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: My new speed profile for @RAMS_RC_Club track https://t.co/RtLb7TcgIJ
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: Practiced at @RAMS_RC_Club today with my new @ARRMARC car https://t.co/AEu2hCx89T
Aug 28
DIY Robocars via Twitter
Aug 24
DIY Robocars via Twitter
RT @gclue_akira: 柏の葉で走行させてるjetracerの中身 #instantNeRF #jetracer https://t.co/giVvuE4hP7
Jul 4
DIY Robocars via Twitter
Cool web-based self-driving simulator. Click save when the AI does the right thing https://github.com/pncsoares/self-driving-car
Jul 4