Hey folks!

Yesterday I had my biggest, worst and most scary crash with my 3DR Quad.

Our local firefighters had an open day for public and presented their equipment, did some presentations, they had a jumping castle for the kids, BBQ and beer for the bigger ones.

A friend of mine who is always acting as a spotter for me when doing video flights planned to do some aerial footage of the place and in a second flight film the firefighter team during a car rescue.

So I picked up my quad with full loaded batteries, pre checked everything in my office and went to the starting locations. Here I powered the quad up und waited to get a GPS lock. I didn't need the GPS, but I just wanted to make it absolutely right, because I would be flying over a crowded place.

So after 2 minutes of patience I had a stable GPS lock, made sure I had the right flying mode dialed in, in this case I used stabilize with simple mode, so I could concentrate on the flying location while my spotter would give me advises how to align the camera.

A quick spin up test, everything was fine, so I took of, stabilised the copter in mid air 2 meters from the ground for a couple of seconds and pulled the throttle up to get some height.

First position was reached (no mission, no fpv, just plain odd manual control) so I headed to the second position and yawed the copter 90 degrees to the left. After the yaw I felt the copter beginning to drift a little so I pushed him backwards towards me and reverted yaw so the copter looked away from me.

I wanted to fly back to me whitch meant backwards for the copter but the quad started to lean more and more forward. I had fully deflected the stick backwards, but the copter would not come back, ist slowly increased pitch for some reason.

Because of the kids and the people under the copter the only way to recover safely from this situation was to apply throttle and let the copter drift away over the firehouse, keeping it in the line of sight until I could be sure it was over the building towards free space and then shut the motors down.

The result: most important: nobody injured, for gods sake!!!

2 Motors broken

2 arms damaged

GPS unit destroyed

IMU shield defective

maybe more to come, I didn't disassemble and tested everything right now

I have absolutely no clue what happened! So any help in order to understand what went totaly wrong would help!



P.S.: Board Version 1.4, Quad with 850 motors, all settings to stock, Firmware version 2.7.1

Views: 6711


Reply to This

Replies to This Discussion

Personally i don't trust any flightmodes that can confuse my orientation. Magnetometer and GPS can be disturbed by solar winds,surroundings etc. As long as i can see the aircraft (even without orientation) i don't want an irritable automatic to alter my steering commands. You always have to be prepared for sensor disturbance and have a "clean" flightmode on a switch. With enough lipopower you can always steer a copter back with just jaw and nick forward as long as you don't panic and keep concentrated. Stay away from places with active jammers (GPS etc) like prisons, hostile frontiers etc. Schiebel learned it the hard way: http://www.suasnews.com/2012/05/15515/schiebel-s-100-crash-kills-en...

let's wait until you first crash will happen where you did not dare to change anything on the flight modes because you didn't want to make things worse. Then lets talk about your perception of what happened.
As I said, this was not the first crash, bug, error, misconfiguration, etc. I had to deal with.
And, as I have mentioned, I have put too much trust in the system, a lesson that I have learned.
What is most important to me is the possibility to avoid this special situation, where a already known bug caused big trouble.
I don't blame the dev team for the occurance of bugs, but it's a shame people do not get informed (trough MissionPlanner or per Mail or similar) of newly encountered bugs and errors.

Maybe this is somewhat off topic but I think it is possibly a neglected cause of radio interferance causing all sorts of odd behavior of the copter.

RF interferance from bad bearings in the motors!

Interesting reading


Check the copter bearings regularly.





You're exactly right. In engineering, we call it the "weight" of the data, or how much a piece of data should contribute to the output of the system.

The typical tool for dealing with this in-flight is the Kalman filter, which allows the software to judge in real time which sensors to trust and how to calibrate each sensor based on disagreements between the sensors. It even allows different weights over different time scales, for example GPS can't be trusted over small time scales because of constant fix corrections, and gyros and accelerometers can't be trusted over long time scales because of drift.

The behavior of this craft makes me think that the sensor data is not integrated with a Kalman filter. With so many sensors disagreeing with the AP's internal estimation of yaw, the weight of that value should have been reduced to allow the sensors to override it more quickly.

The failsafe problem is a separate issue. It doesn't take a lot of fancy math to figure out that the reported compass heading is >10° off of the expected value or an airspeed sensor or barometer is negative. The AP should have never allowed this craft to take off.

wouldn't this be the perfect step in for you to contribute?


Jonathan, sign up.

But, FWIW, the APM doesn't have enough horsepower to run a Kalman filter.

Well I'm not an expert and we're just trying to find a possible cause to the crash. I'm flying with FM radio (I've used 2.4 and found FM to be more reliable and with longer range), and I always have the care to check if there's someone nearby flying too because we could be using same frequency. Yes, 2.4 systems are much more reliable in this situations, however they are not imune if a nearby system of great power is in use and can "cover" your radio signal. An example : My car only works with the key remote near the ignition as an RF safe measure, but if I'm in a wheel alignment shop, they must disconnect their devices for my car to start, or the wireless calibrators will mess with my remote frequency and don't let the car start. I'm not saying this is what happened, but can happen. You were near fire cars with powerfull communications systems wich may receive some call or a beep and that may be a problem, or so I think (not an expert, as I said, only trying to cover the possibilities).

The crash was caused by simple mode bearing being off by greater than 60 degrees reversing roll and pitch. It wasn't leans. It was a dcm init issue and probably mangnatometer calibration issue. These two worked together to create a yaw that was incorrect.

The Paparazzi AP can run a Kalman filter, so it should be possible on ArduPilot. It might require moving some of the algorithm to the medium loop or offloading it to a Gumstix or Raspberry Pi.

I think pre-launch failsafe might be a better place to start as it doesn't touch in-flight code.

Only for information, I did the live calibration of the magnetometer as mentioned in the MP. A erase/reset was alsomdone tomget rid of all old settings. After a firmware update, i always recalibrate everything.


I've had controls reverse on two flights in simple mode.  Can you explain how this can happpen and what we need to do to prevent it?   How did my bearing get off over 60 degress?  My compass always check's out fine.

I don't know if this means anything to anyone, but I had yaw drifts with 2.7.1 when flying in ANY mode...

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service