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
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.
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.
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.