Autopilot went haywire

I’m new to the APM quad world. I got my Quad set up and working great this week and I wanted to test the Autopilot function of the APM2.5. I planned a simple box with 6 way points, a take off, 4 corners, and a land point. I loaded the mission up to the APM, went and armed the motors, went to the actions tab and told it to run the mission(the UBlox GPS had been on for 3-4 mins before). It didn’t take off on its own. so I gave it a little bit of throttle and it lifted a couple feet then the APM took over. but instead of heading to the first way point it went the opposite direction then started a long arc around and up. It flew itself over a road and straight towards some buildings no where near the plan I had made. The Max alt for the plan was 15ft, it went well over 200ft. I started to try to bring it back when it was over the road, I had a little ability to direct it with my controller, After i had it over the field again I quickly told it on my computer to tell it to return to launch. it started to descend (fall really) in a direction away from the launch point and then dove into the ground breaking my rig. I’m trying to figure out why it didn’t function properly. I’m pretty upset it did such a horrible job and ended up wrecking my quad.

Anyone have any idea what I did wrong or what could have malfunctioned? i ordered new parts already and i want to get the autopilot function working.


Hi Mitch,

I was out flying my quad today when it seemed to do a similar thing. I have been flying for a while on 3.0.1 and have had no issues until today. Like you, I was trying to run a waypoint mission, but it wouldn’t take off. After a slight increase in throttle, it took off just fine and immediately began going in the opposite direction of the first waypoint climbing the whole time. I tried to switch into stabilized mode to regain control, but at that point it was so far away that it was hard to tell if it was reacting to my commands. Then, it just fell out of the sky.

I’ve been pouring over the GCS logs and the onboard logs trying to see if there is some obvious issue. So far I haven’t found anything. Instead, there are certain things that just don’t make sense, of which the major two are that the target alt as seen by the GCS is constantly 0 and the on board logs just cut out about the time the quad fell out of the sky; however, the radio signal didn’t cut out even after the crash.

My rlog, tlog, and onboard log files for the flight can be downloaded from this link. Nothing happens until around 60% of the logged time.

Mitch, would you be willing to send me your log files so that I could compare them to my own?

Thank you,

Sorry to your crash.
The copter not starting the mission until you raise the throttle is normal behaviour. This was your first time trying AUTO I guess? I’m wondering if you went through testing the flight modes in this order after putting your copter together?
Each one of these modes builds upon the other and if you just start using AUTO before ensuring that the other flight modes are working properly then horrible things can happen.
The most likely cause of your problems are vibrations and inaccurate compass. It sounds like you have perhaps both problems. The Vibration issue would be discovered during Altitude Hold, the compass issue when testing loiter.
Instructions on testing vibrations are here:
Please try running the compassmot procedure ( … ESC_motors) to see the level of compass interference.

I had a look at your logs and the copter is always in Stabilize mode so it doesn’t appear to be an AUTO failure.
It appears the copter had a brownout. There’s a link below to the “diagnosing problems using logs” page and like the example on that page, the copter’s logs just stop with the copter is 25m in the air: … wnOuts_etc
Apparently we can’t post images into this forum so I can’t give you a pretty picture but if you graph the CTUN message’s BaroAlt field you’ll see what I mean.
I guess you’re powering your copter through the ESCs? If ‘yes’, it’s possible that the ESCs were not able to provide enough power to the APM while also providing a lot of power to the motors and this was the cause of the brown-out. That’s just a guess of course. By the way, a 3dr power module is the best way to power the APM and since it’s been introduced we’ve seen a massive drop in the number of people suffering from brown-outs.

 Something suspicious in your logs is that the ATT message's RollIn, PitchIn and YawIn are all zero throughout the flight.  Did you really not touch the sticks during this flight?  Throttle does change though so it doesn't look like a radio failure....but when graphing the raw roll, pitch values in the tlogs there is a place just before the troubles start that the regular jitter disappears.  The lack of this jitter makes me worry that there was a radio failure.  I see the throttle failsafe is set-up, I'm wondering have you tested it according to this wiki page to ensure that the throttle drops below 975?