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 @NXP: We are already biting our nails in anticipation of the #NXPCupEMEA challenge! 😉 Did you know there are great cash prizes to be won…
DIY Robocars via Twitter
RT @gclue_akira: レースまであと3日。今回のコースは激ムズかも。あと一歩 #jetracer https://t.co/GKcEjImQ3t
DIY Robocars via Twitter
UC Berkeley's DIY robocar program https://roar.berkeley.edu/
DIY Robocars via Twitter
RT @chr1sa: The next @DIYRobocars autonomous car race at @circuitlaunch will be on Sat, Dec 10. Thrills, spills and a Brazilian BBQ. Fun…
DIY Robocars via Twitter
RT @arthiak_tc: Donkey car platform ... Still training uses behavioral cloning #TCXpo #diyrobocar @OttawaAVGroup https://t.co/PHBYwlFlnE
Nov 20
DIY Robocars via Twitter
RT @emurmur77: Points for style. @donkeycar racing in @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video. https://t.co/Y2hMyj1…
Nov 20
DIY Robocars via Twitter
RT @SmallpixelCar: Going to @diyrobocars race at @UCSDJacobs https://t.co/Rrf9vDJ8TJ
Nov 8
DIY Robocars via Twitter
RT @SmallpixelCar: Race @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video. https://t.co/kK686Hb9Ej
Nov 8
DIY Robocars via Twitter
RT @PiWarsRobotics: Presenting: the Hacky Racers Robotic Racing Series in collaboration with #PiWars. Find out more and register your inter…
Oct 23
DIY Robocars via Twitter
RT @Hacky_Racers: There will be three classes at this event: A4, A2, and Hacky Racer! A4 and A2 are based around UK paper sizing and existi…
Oct 23
DIY Robocars via Twitter
Oct 23
DIY Robocars via Twitter
Oct 19
DIY Robocars via Twitter
Oct 18
DIY Robocars via Twitter
RT @NeaveEng: Calling all UK based folks interested in @diyrobocars, @f1tenth, @donkey_car, and similar robot racing competitions! @hacky_r…
Oct 13
DIY Robocars via Twitter
RT @araffin2: 🏎️ After hours of video editing, I'm happy to share a best of my Twitch videos on learning to race with RL. 🏎️ Each part is…
Oct 13
DIY Robocars via Twitter
RT @a1k0n: Fully autonomous wipeout in the corkscrew at Laguna Seca @selfracingcars today. Got some tuning to do; this car is very fast, bu…
Oct 13