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

good job clearing the crowd..  I know alot of people that would have been fighting to save the aircraft first without worrying about were it was.

some advice.  learn to fly in acro mode...  if an accelerometer goes out or the calibration gets wonked out, if you are proficient in acro mode, you can flip to that and take more manual control without the controller fighting you.

just my $0.02

I was wondering the same thing. I'm a software/test engineer in my day job, and every successful project I've ever worked on has had automated component and system tests running at least daily. Is there a similar structure in place here?

On a related note, is there a list of known holes in the code that developers can contribute to? I'd like to contribute, but don't know where I could do the most good. After seeing ArduPlane in action I was hoping to contribute some code to the control loop, as the  improvement opportunities were obvious there, but Jonathan Challinger beat me to that. 

Good advise Chris,
But I didn't dare to touch anything else on the transmitter than the sicks. In any other situation, on a free field for example, there would have been time to "test" what was going on. But in this very special case the only way to recover from this situation was to get the copter away from the crowd.
Remember, when it happened, I had no clue what was happening, so changing the flight mode was not an option. It could have lead to an immediate crash into someones face.
Looking backwards with the knowledge of what went wrong (yaw direction not correctly initialised) there were several options, but not as the thing happened.
So I accepted the smiles and poor looks of the people when I walked away with the crashed copter, knowing that I should have smiled back to them because I did not kill anybody.
Btw. I know how to fly in acro mode. Not super perfect, but I can handle the beast. In this case, switching back from simple mode to stabilised mode would have made a good job, but dare to touch a switch of what you don't know what it will do if you are just about to crash into a couple of kids...

Jonathan, basically how it works is that SITL testing is run continuously on the code in the repository.  Pretty much ever change is tested to make sure it builds, and then the SITL is run to see how it flies.

However, once we have a "release candidate", it is extensively test flown by a number of people on various platforms.  (this should not be misconstrued to say that the Alpha code is also not flown).  Marco, Chris, Jason, Randy, myself, and some people at 3DR also test fly it.  We are the beta testers, not the end users.  We crash so you don't have to.

Do things sometimes slip through the cracks?  Yes, absolutely.

As for what you can contribute, it's a bit of a difficult time right now.  We are winding down development on the 2560 processors.  Don't expect any new features to be included.  We'll be doing bug fixes, and incremental performance improvements.  But development will be shifting to the ARM platforms.  So it's hard to find a place to fit in at this point, unless you want to buy a PX4 and start working with it.  Tons of opportunity with it.  But, the Arducopter code doesn't even run on it yet.  There's a lot of work to do.

Chris, that is a good point.  I encourage everybody to learn to actually fly, rather than blindly trusting the autopilot.

I experienced this on the weekend, as I had been doing some testing with my quad, and had inadvertently set Ch7 to Auto_trim and thought I had switched it back to Simple Mode.  I took off and started flying around, switched to 'simple mode', and not only did the roll/pitch commands not do what they were supposed to, but it was leaning all over the place!  A bit of a rodeo ensued until I realized what I'd done, got my head back into "not simple mode", and then had to retune the Auto-trim to get it flying level again!

Not to be big headed.... but if I wasn't a good pilot, it would have ended in tears for sure.  I was actually flying over a lake.

If it was a firmware error or even an hardware error, bit's and bytes didn't nearly destroy someones health.  Flying an untested, 3 or 4 flights, over a group of people almost destroyed someones health.

I'm flying 2.7.1 on an APM 2.0.  I've probably had 40 flights, about 5 hours, with it with nothing like this happening.

Well said.

This is excellent information.  Any chance you can do a write up on log analysis.  I've been trying to figure it out but I'm finding it slow going.

Hello Marc, Everyone,

I am not an ArduCopter Expert (soon i'll order one :-) ) but I have already worked on plane UAVs and with guys with big yamaha helicopters (~100 kg) and now involved in ground field robotics.

We once had a plane crash we didn't understand at first sight: the plane just pointed to the ground from an altitude of 75 meters at speed >~ 50 m/s. Nothing much was left but fortunatly nobody was around.

Our autopilot was relying on GPS signals and altitude estimation from the GPS got wrong and the estimated was 100 meters higher than it should have been for a few second(s) so the plane decided to pitch down... The ground stopped it :/

It was too fast for the pilot to swich back to the manual mode and do something.

Now for any mission (ground or air) we are always at least two persons to operate. One pilot and One guy monitoring logs/sensors to see if everything is nominal. A third guy with the "emergency alternative/stop" is a must-have with some spectators around.

GPX : I have checked your GPX log because I didn't really understand if you didn't need GPS or if the autopilot was in fact using it (Like a default behaviour if GPS-Signal-is-present).

By checking the ArduCopter code I've seen there is a variable *initial_simple_bearing* that is updated at every GPS read.

So the GPS was used (correct me if I'm wrong, I am just a ArduCopter new-starter :D ).

I don't really understand now the mix between Stabilize and Simple mode when you say I used stabilize with simple mode but you seem to have started on a home point that is behind you, the GPS indicating a point in the the middle of the road but If I do not mistake you seem (from the video) to have started on the parking part that is the closest to the pavement, that's about 5m far from the road.

In ArduCopter.pde version 2.7.1 (yours at the time of the crash) I see this :

// SIMPLE Mode
// Used to track the orientation of the copter for Simple mode. This value is reset at each arming
// or in SuperSimple mode when the copter leaves a 20m radius from home.
static int32_t initial_simple_bearing;

And your troubles seem to appear after these 20 meters of radius (accounted from the middle of the road).. and GPS keeps "jumping". This variable, wrapped with the yaw reading, only seems to be used to update  roll and pitch  when applicable (simple_counter > 0) and jasonshort examination about Yaw looks perfect.

Well I still have a lot to read to understand everything about the flying modes so this is just my 2 cents ! You can delete if its non-sense. :)

Anyway congratulation for your manoeuvre avoiding kids and people and thank you very much for the data.

in another post inside of this thread you write you had about 40 flights with fw 2.7.1 without any problems. So you think this would have changed anything in this case? Do we use totally different setups, do you use simple mode at all? What would have been the difference if it was a harware error?
I know how to do my test flights, i have the luck to have a stock quad, so no pid tuning flights are needed. What i do test are the things i use, and this is simple mode, stabilise, rtl, loiter, acro. Everything went perfect, so I decided to keep this firmware and not revert back to 2.6.
The thing is, this will always happen, and not always will it end up only with damage on the copter. People buying these copters are interested in using them, not bugtesting them. They don't care about forums, alphas, betas, the just grab the newest version and go flying. You have to make the people aware of what is going on with the software, and not just blame the users if anything goes wrong. The will answer: hey, I didn't know there was a bug, nobody told me! And they are right.
So how to change it? Simple task. Users use the mission planner, so we have to implement an alerting function if bugs appear to keep the users up to date. Additionally, there could be a brief description of the firmware inside the mission planner. Known bugs, changes, etc.
This would help!
Imagine: I downloaded fw 2.7.1 a couple of days before the flight, tested it and everything was fine. At the day of the fatal flight I connected (as usual) the copter to the mission planner to make sure all the sensors were working correctly, and by connecting with the apm, an alert box would have said: hey, there are new bugs inside the firware you are using you don't know of! Here they are....
This would have keept me from flying or using the simple mode. In any way, I would have been informed and this crash wouldnt have happened.
Hey Redouane,
I did not use super simple mode, only simple mode. This is basically stabilised mode plus a "keep the orientation for the pilot always the same" mode. This means it does not matter hiw the copter is orientated, as long as you as pliot doesn't change orientation, pitch forward will always mean pitch away from you. For this you don't need gps, but usually wait until I get a gps lock so I can review my flights. And there was a bug in the earlier versions making the copter going mad when getting gps lock during flight.
The gps had 5 to 7 sattelites, but you are right, it has an offset of about 5 meters from the real position.
Btw, in the case of your big heli with the wrong gps altitude, a plausibility check would have helped. The copter would have compared the last height data to the new one and found out that the new data was not plausible, accels and baro must have had shown the same behaviour to make the copter accept the new position.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service