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!

Greets

Marc

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

Views: 6711

Attachments:

Reply to This

Replies to This Discussion

First, let me say you were very conscientious.  You moved your quad to a safe area.  Just imagine if you'd have hit one or more people.  You and likely 3DR would be opened up to huge liability lawsuits.

I use the following modes.  Simple, stabalize, ACRO, RTL, auto, Alt Hold and Loiter.  I built my frame based on the Arducopter.  AC2217-9 motors, 18A ESCs, APM 2.0, Spektrum DX7s TX, Spektrum 7 channel RX and a Hyperion 4A Lipo and a small HD camera. Fully loaded it weighs 1468 grams.  I can fly casually for about 8 minutes.

I realize people want to use their quads. People are buying these thinking they are toys that can be flown by unskilled pilots. The certainly aren't advertised as such. I flew RC planes 35 years ago.  I got back into RC a couple of years ago with micro-copters to regain skill.  I then moved to a blade mQX to get quad experience.  Only then did I move to the much more dangerous larger motors, props and APM.  In my opinion, 3 to 4 flights are not sufficient testing to have confidence in the quad.  I fly with people around but I didn't do so until I'd flown about 30 flights.  I'm now comfortable flying my quad within a foot of my person. Only I am in danger.  I would not fly that close to anyone else ever.  When I get a new quad, I'll do the same.  I'm also not telling anyone where or how to fly their quads, that is up to them.  However, don't blame the bits and bytes if someone gets hurt.

Saying everything was perfect shows a lack of understanding of what you are using.  Even with deadly vehicles that have been around for decades, nothing is perfect.  Last weekend there was a crash at a truck race. The truck, with a driver inside, veered into a crowd.  There are airshows in which people in the crowd have been injured and killed.  Does that mean we shouldn't use them around people?  Of course not.  We shouldn't be using them around people until we are confident in their behavior.  Even with confidence, there will be failures and accidents.

I agree with you on bug notices and changes. The are there but you must dig to find them. I also feel the documentation is lacking.  However, Chris has committed to fixing the documentation.

3DR doesn't have any liability in the mater. This was a pilot and/or software related failure, and 3DR does not make the software.

I agree with the rest of what you wrote.  Despite best efforts, sometimes stuff happens.

If it could be proven that there was a bug or other defect in the hardware/software 3DR would have liability.  There are many companies that have found this out the hard way.  Many U.S. legislators and lawyers want gun companies held accountable for the crimes in which their products get used.  We, the users of this product, should do all we can to limit this possible eventuality.

I'm not a lawyer but I've seen the cases before.

Remember that this community actually started as a bunch of like-minded enthusiasts discussing auto-pilots, and that Jordi and Chris found they could save people a few bucks if they went in together and ordered a few parts in batches and then custom built a few boards, and eventually 3DR was born.

The software is the responsibility of the open-source community and is contributed to by everyone.

Liability in this community setting would be difficult to prove.

I agree, liability is nothing we should discuss here. Let's concentrate on what caused the crash and how future crashes because of not known bugs (by the user) can be avoided.

marc, I agree we shouldn't discuss it in this thread.  I just brought it up as something to think about.  However, whistling past the graveyard does not make it go away.

I personally don't care where this all started from.
I am interested in where it goes. Nothing against open source, i consider it as good and productive.
But if one special product is being developed on the top of one special open source software, is this the excuse if thing go terribly wrong?
Or I say it in other words: I buy a piece of hardware, i have a warranty claim. I use the one and only appropiate software and the warranty is gone? Nice.
Don't get me wrong, but people will think like that and they are more than half right with that as long as the docs are incomplete, the bugtracking a journey for the brave and the foolish and the usage of the software at their own risk.

Actually, looking at Jenkins, most of the testing has not completed successfully for around 3 months. That means that all of your recent releases went out basically untested.  ArduCopter has some recent test runs (good for them) and there's an autotest for something called "skel", but the rest aren't even building.

Are the test procedures documented somewhere?

Can someone describe how sensor data in integrated in ArduPilot? This craft came down due to a poorly estimated yaw value, but this condition should have been obvious to the software. There was enough sensor data to prevent this:

  1. The compass heading initially was close to correct, but the AP didn't use this in its initial estimation of yaw. (Glad to see that's fixed now.)
  2. The gyros did not sense the same yaw that the compass did but were ignored, whereas the gyros should be considered more precise at these time scales.
  3. In simple mode, the commanded movement should have directed the craft on a particular GPS heading relative to home, but the GPS correctly read the craft as moving in a completely different direction.

A properly filtered IMU would have quickly ignored the anomalous compass data.

At the very least, the AP should have detected that the compass reading was not nominal at launch and refused to arm the motors. I understand that in-flight failsafe may not be feasible in ArduCopter, but keeping this craft on the ground would have prevented this loss and many others.

Tony,
I am really astonished that from one simple sentance "everything was perfect" you are able to conclude that I have no or little idea of what I am using. Tha ability to interpret these simple words into a rating of my knowledge realy made me think for a while.
Well, I am not god, neither one of the developers of this nice project. But I am developing myself on Atmega platforms, and be sure I have my test routines before the copter lifts off for the first time with a new fw version. I know how easy bugs can appear or show themselves or how long thei can lie sleeping until something wakes them up.
And if something goes wrong, I will always blame the bits and bytes, because those creepy little things did not behave like their creators had told them!
Jonathan,

for me the most interesting point is number 2 of your list, because this leads to the question of plausibilty.
Only if the new data is plausible, it should be used.
Some time ago I was programming an enhanced door control to read out the state of an electromechanical door lock and used this plausibility check to make sure I don't get a state the main loop could not handle. Worked likema charm. Well, this baby is a little bigger than a door control, but maybe because of that it should double check the data it is depending on.

First, you flew over people with, in my opinion, an untested craft. The following comment you made shows you weren't confident flying this craft yet. “But I didn't dare to touch anything else on the transmitter than the sicks.” Another comment shows you weren't in the correct frame of mind. “you are absolutely right that the firmware is still experimental. The only person I can blame is myself, that I forgot about that“ The “everything was perfect” comment is just another indicator of the frame of mind you were in.

I'm really not judging you. You did an excellent job of avoiding the people, even at the cost of your craft.  As I said, I am not telling anyone how, when or where to fly their crafts. The main reason I commented was that you were trying to blame “bits and bytes” if someone had been hurt. I was just pointing out that the bits and bytes can't control where people use them.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service