I finally bit the bullet and ordered the 3DR kit. #excited
I should preface all of this with the fact that I'm not a hardware guy, software guy, r/c guy, hax0r extraordinaire, FAA commander, or anything that would make me particularly qualified -- I ordered the kit, followed the instructions, and happen to have an experienced quad flyer friend to bounce questions off of.
To start, my experience with the ordering system was lacking -- multiple kits "in-stock" but nothing could be added to my cart because one of the items in the kit was not in-stock. I could see this being an issue if it were a major component, but it was the velcro battery strap. So if you cannot delay shipment until said part arrives, and you won't let me add the kit to my cart, then you really don't have any in-stock.
Kit arrives and I spend the next two and a half days or so building the 3DR per the instructions in the wiki. It wasn't really all that difficult, just a lot of tedious work - checking, double checking, oops and fixing, etc. Issues that I had included the instructions not matching the hardware I was sent. Cables weren't the same colors, parts were off, etc.
After the main frame assembly was complete there was a very noticeable "arch" on two of the arms. If oriented in "plus" mode instead of "x" mode you would notice that the left and right arms were both angled backwards by several degrees, while the fore and aft arms formed a straight line in relation to each other. The left/right arms had to be measured and drilled out a bit to make them straight. Poor QC imho.
It was also interesting to see that 3DR was shipping bullet connectors as from my research they are notoriously sketchy. Not that it's a show stopper, but "sketchy" is not a word I want to use for any components going into a fairly expensive flying device. Replaced all the bullets with dean connectors which seem to be pretty stable. (also per the rec of my quad flyer friend)
The configuration of everything seemed to be pretty straight forward with no major or noticeable glitches. Once the beast was built it was time to see if it would fly!
Flying started slowly until I could get a feel for how this thing works. I can say that after a few minor adjustments it was picture perfect! Hovered well, responded well, and seemed to generally be a rock solid performer. I was definitely stoked to fly more. I drained one battery in testing.
Day 4: I head to the quad flyer buddy of mine's house and we head out to a HUGE field to play around and for me to learn a bit more. Drained another battery and everything seemed grand - and then...
After putting in the second battery (3rd battery that's ever been used) I start noticing a little glitch -- the controls don't seem to respond, but only for a second. The quad is hovering nicely, bank right, nothing - being a newb I'm not sure what's going on as everything else has been spotless. Bank right again and we're back. This happened a couple times in various spots, but nothing major.
We then do a vertical assent, which I've done a couple previously, but this time was different, much different. I "gas" it to probably 75% throttle and the quad shoots straight up, fast, I let off the throttle and nothing happens. The quad continues to climb and no controls will work! There was a 2-3mph cross wind and the quad climbed and was blown sideways FOR MILES. A more or less fresh 2650mah nano-tech battery carried this bitch further than I could see it until it was nothing more than a black dot across the grey sky. Nothing worked, nothing stopped it. Gone.
I have no means of locating the craft let alone troubleshooting wth happened - could it have been a bad board? bad radio? software malfunction? short? I'm not trying to lay blame on 3DR or anything, but there are a lot of assumptions made in the assembly instructions, stuff that's just plain not there, and if I didn't have an experienced pal assisting there would have been a lot of unanswered questions. Heh, at this point there still are.
So my take away from this is - WTF. I completely lost the quad I just paid 600$ for, spent 2 days building, have flown twice - barely, and have no clue as to why it decided to full throttle to the stratosphere. There appeared to be zero issues with any of the equipment, all fresh batteries, and much to the bewilderment of my experienced friend who commented that he's never seen that happen before.
So the two flights I got out of this device were awesome and I was told it was handling very well and looked spot on. Irrelevant at this point I suppose as I don't even have a handful of busted parts to scavenge from. I lost the entire craft, a brand new battery, and radio gear.
@Andreas re: testing failsafe
I was looking at the code a while ago (2.5.0) at a way of manually triggering the fail safe and it looked rather simple. IIRC, there were two places which set a status to failsafe. It was a while back and I've been on other stuff since so memory fades. Would it be as easy as I was thinking to have a way to manually trigger the failsafe? perhaps through a channel 6 switch?
A friend of mine got it all setup as per the wiki, did a test and it RTLd but then crashed, breaking a motor and prop. He saw the test as a success because at least it crashed within walking distance. He had two previous fly-aways which lead in a couple of hours of searching for each.
I set mine up the same as him but don't really want to test it for obvious reasons.
Crispin: see Andrew Tridgell's geofence work, I could use testers on the ArduCopter port
Andreas , I saw that and think it's a cracking idea for what it is intended. Thing is, you need to set it up for each area you are going to fly in.
I can't (still skimming article though) see how that could enable a manual test of fail safe. Most of us set it up and hope it works when needed, much like the airbags in your car :|
I'll certainly give the fence some testing when the weather improves, would June 2014 be ok? Cosidering swapping the quad for a boat at the moment...
See the part that talks about auto-fence, no need to setup. It will just draw fence around your starting point. Also an altitude floor and ceiling. So you just get GPS lock, take off and arm the fence once you are at (above) the preset "floor".
No need to setup the fence in advance.
That furious little drone that was simulated bouncing off the walls for 5 hrs (the mushroom flight trail)? I never set any fence coordinates, just took off and it set up an auto-fence.
ahh, that is awesome then. Thanks. will try it.
My concern here is, if we have the code "do something" how does the untrained pilot react?
In other words, your flying, your not good at judging distance yet and you hit the limit (altitude or just distance). You think you lost control so you move the sticks to wrong positions and then it get's really bad. I'm just saying that there's more to this than just adding functions and failsafes. This is why RC guys have clubs, buddy boxes, training, and proper flight fields and rules. Because the human is in the loop, we have a whole lot of unpredictability, and further, we still have no collision avoidance and that's not something that comes cheap. The sensors alone are cost prohibitive (RADAR, LIDAR?). All I'm saying is that RTL is scary and just really dangerous if you didn't know what was happening, depending on where the aircaft was and the path, there could be obstacles in the way, and then how do we handle return of control? How does the user know they lost control? How do you train the user for the situation to not cause a crash after a failsafe occured?
Again, I don't think bounding is a bad thing, but the above questions show why it's experimental at best.
And sorry, it's just how I think about it but "predicting" a radio with invalid failsafes is a total crapshoot. It might work, but it also causes more "loss of control" events due to the pilot not knowing how to react and the "rules" for returning control after a failsafe event are going to be rather complex. The safer and proven method of ensuring the radio has proper failsafes is the best bet and minimally, should be the layered security approach always.
I will second that, I have had RTL based on power consumption for wings.
Once I was mucking about after completing a photo run, low passes etc. I had forgotten about the power based RTL.
When pre determined amount of power had been consumed the wing just headed off by itself to climb upto 100m and start its circle. It flew between two large trees on the way I wondered what on earth was happening. It all ended ok but I don't forget power consumed RTLs now.
Less is always more KISS
This has the potential of being a really interesting conversation.
This isn't just for improperly set radios. Any number of problems could cause the receiver to freeze. Even a telemetry radio could freeze and cause a problem.
The idea is that the autopilot should know that some things are NEVER right to do. When you start the flight you should pick some parameters, like a max range setting, based on what you're trying to do. If anything causes the craft to violate these the autopilot should take corrective measures.
There's all sorts of ways to handle potential problems. It would be easy to say set your max range at 1 mile. For a quad on a training/testing mission if you go over 1 mile away you KNOW something is seriously wrong and should abort flying. If you set the range reasonably you shouldn't ever have a problem. Alternately, you could have it beep or otherwise warn you, then take control if you don't respond within X amount of time.
With a sophisticated autopilot there's just no reason for it to think that it's OK to just sail off and crash somewhere far away. I'm not talking about geofencing your backyard, that could cause some problems. But if you're in a proper flying location there should be a large zone between how far you want to fly and how far it is safe to fly.
A simple distance or fence safeguard would go a long way towards avoiding legal claims of recklessness. Generally, if you take preventative measures that should have prevented endangering someone and they fail it's just an accident. If you set up a system that you know full well could sail off and crash into something or someone due to any number of problems, that's reckless endangerment.
It would be nice if we could add a voice annunciator. Disarming announces the settings (one last time) before takeoff:
Voice from copter:
FENCE ONE ZERO ZERO METERS
STAND CLEAR FOR LIVE MOTORS
Easy enough, Speakjet standalone text to speach conversion using the 2 chip combo. From a programming perspective, it's far better to not send serial or even parallel asci text out of the main loop in the mega 2560 code, but with some interfacing, either single line outputs or some simple digital status could be used and stored phrases in the speakjet.
Again, we would want to make minimal changes to the mega code, just alow for a simple interface between a second board running speakjet, as to impact the main flying code loop the least, writing serial or parallel acsi data would slow the main loop to a crawl.
This breakout shield has a tiny amp and an area to mount the asci to speach conversion chip http://www.sparkfun.com/products/9811
Bascially, it's a couple of more chips, but minimal programming even a novice could do would make this work. It's just going to be some basic serial writes out of a second Arduino(say a pro mini 328) the serial text to speach conversion chip, and then the speakjet chip + an amplifier and speaker.
Because speakjet is so versatile, this is really just a matter of following the examples with the main goal of not impacting our current flying code.
Actually, I just came up with an even better idea. We take the current code for the OSD displays since it "reads" mavlink data, thus no changes to the existing arducopter code. We then modify it to send the relavent data to speakjet (very simple).
And this can be used at either end of the telemetry link ground side or heli side.
Further, and this is the best part of the mod. Instead of modifying the ardupilot code for all these desired safety features, we instead modify the new OSD/speakjet code with USER failsafes. We put a dog shock collar on the "Pilot" (AKA stupid user), and whenever a user induced error (hit the fencing limit, wide open throttle, etc..) speakjet announces the error and shocks the piss out of the Pilot.
How about that for some "Pilot training"!!!! Brings new meaning to "system armed".
Somebody beat me to it, the exact solution I described.