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.
So my take away from this is - WTF.
Ok, it's clear here you have some serious expectations that no autopilot can deal with.
Your primary failure sounds like a radio range signal was lost. When that happened, either the receiver you used or the failsafe settings in the radio receiver were completely wrong. The problem here is, if your receiver sends valid PWM/PPM coding to the APM, you might as well heve been telling it to do it with the sticks. Next, if you were in stabilize mode, the ONLY thing the APM is doing is trying to keep it level. It will not keep it from crashing because that is a manual mode meaning YOU are flying the machine. Had this been a regular heli with NO APM, the exact same thing would have happened based on your setup.
Bottom line, if you lost radio, you couldn't even switch modes unless you had remote telemetry setup and even then you wouldn't have the time.
Many get into this hobby and don't even follow BASIC radio control setup inlcuding failsafes. The instructions cannot account for this with all the different RC gear out there. That's why your RC gear has it's own manual. The settings you failed to do are in the instructions for your radio, not on the wiki.
Even professional multi thousand dollar auto pilots cannot deal with a cheap radio link issue, especially if they are in a stabilise mode. To both the autopilot and the machine, your radio was the problem. A multi thousand dollar APM aslo comes with an expensive radio with link info and properly setup failsafes.
We all feel badly for the loss and this is a hard first lesson. The bottom line is learn from this, understand the rules of radio control before you go adding an autopilot. Test your system on the ground with no props and turn off the radio. Perform radio range checks (again in the radio manual).
People are going to expect autopilots to have reasonable safeguards. There's really no reason the autopilot shouldn't have a "max_range" setting that will kill the unit, slowly descend, or RTB. That's the kind of basic stuff you would expect a simple autopilot with GPS to have.
Just because he should have known better or been more diligent in his safety practices is no excuse for an autopilot to, by default, have no proper safeguard features enabled.
It would also be a reasonable feature to have the autopilot realize that the receiver has frozen. Anytime the receiver is functioning there will be variable PWM signals. A frozen signal should be easy to detect.
You're missing the point-he was in stabilise which is a manual mode. The APM is not going to take over manual mode EVER as a safety feature. The proper assumption is the PILOT is there in control to make decisions, so if the RTB is near power lines, the APM would drive right into them. Further, while yes, you could put altitude limits (AKA Fencing one of the front page features) you'd still have to set it up. You obviously missed the FAA rules for the very few people who have a COA to legally even fly these right? They must have 2 trained pilots with alternate radio systems. They must post flight plans and report ANY equipment issues or even a hard landing. THE FAA doesn't even have the expectations you do. In fact, they are exactly as I have described, they want a PILOT in control.
IMO, you guys have some pretty wild expectations for a $200 APM. It's not that it cannot do these things, but even then, the current sensor package has no way of knowing obstacle avoidance. Because of that, many of the features you just asked for are even more dangerous. I mean think about it, you lost control and then suddenly if flys back at you where it took off from. How scary would that be? You have no control and it's coming right to probably where you are standing. Think about what you ask for in a feature and then start doing the what ifs before you complaining that it should have saved this. Further, the idea is that we are combining off the shelf hardware for cost reasons, but the tradeoff is compatibility. It's up to you the builder to KNOW what your radio is going to do-period. If you don't have control, you certainly don't want this thing to be in control.
Also, it's open source. If it's so easy to detect and build in a failsafe in the PPM encoder-have it with your programming wisdom.
Here's the link to the experimental "geo fencing" http://diydrones.com/profiles/blogs/geo-fencing-for-arducopter-keep...
So yes, some of that IS in the code, but experimental because as I stated the second problem, we have no collison avoidance so "autopilot" is not really an option. Besides, even real autopilots are there to assist the PILOT, they are not intended to "save the plane".
Also, need to shoot another hole in your PPM encoder failsafe.
A frozen signal should be easy to detect.
So when you're in Loiter, Altitude hold, or one of the other more "automatic modes" you aren't moving the sticks so wouldn't that be a "frozen" signal comming from the reciever? I mean most of the videos show the person holding the radio showing they aren't providing inputs at all and the "mode" is doing the work.
Even leaving the sticks floating there should be plenty of small changes constantly. You're bound to have some bit jitter on at least one of your channels at any given microsecond. That should be easy to detect. If you get the same values for every channel twice in a row then something is wrong.
I do agree with Vernon that a 'frozen' signal is hard to detect (and probably not worth trying), however a well-known radio that doesn't even have a failsafe in the modes used by APM is something that should be screamed from the rooftops!
Is it really true of this radio?
There should be a max range setting. If the pilot allows his craft to exceed that then obviously there is a problem with the pilot or the controls.
It's far safer to take a chance with autopilot taking control than to continue operating with a known defective pilot or controller. It's NOT a safety feature to let your UAV sail off and crash when you know there is a problem. Proper safety controls just haven't been implemented yet.
The OP already lost quite a few bucks and his favorite toy. It's something that should be done, and it probably should have been done long before now.
Jake: Geo-fencing (range limit) is in testing right now.
This being an open community, "should be done" and "should have been done", translate only into "I volunteer to do". There is no "they".
3DR makes hardware, not software. Ardupilot-mega (the software running on the board) is not commercial software, it is open source made by the community. So "they" are the volunteers who built this.
I'm not saying this to contradict your complaint, only to offer the only available solution: please volunteer to help with testing new features, such as the geo-fence. Please help with documentation if you want, by offering suggestions to improve the wiki.
When it comes to the APM software "they" is you.
- If you can code, please code
- if you can't code and can test, please test
- if you can't test and can write, please write docs
Those are the options. Or at least, those are the constructive options.
I agree with you 100%. I know there's no "they".
All I have at the moment is a couple 3DR radios to play with, and I should be working on compiling that code and getting my toolchains in order for 8051 work.
It seems a simple enough fix though that it could be implemented before I even get my APM. And it can't hurt to mention good ideas.
Sorry Vernon, but that's rubbish.
Autopilots were first used in this hobby as a safety feature - they were intended to cover the issue of "failsafe" on loss of signal and safely land the aircraft.
It is more than reasonable to expect the instructions for a quad kit to include how to set up and test the failsafe - even if you don't include the radio, testing that the failsafe works as intended is the same for every radio.
The printed instructions for the much smaller quad kit I bought did specifically say to test the failsafe function with props off before first flight and pointed out that inverted throttle would lead to a very bad failsafe value.
The receiver manual then explained exactly how the failsafe values were set.
All of that was in the printed documentation that came with the kit - not a wiki.
In the R/C hobby I started with (Robot Wars) we were (and still are) utterly paranoid about the failsafe functions so that was the first thing I checked on my quad without prompting.
However, you cannot expect your average 'first timer' to know that, and worse, you can't expect experienced people to know how to test that it's working as intended given that the autopilot is intended to do clever stuff - and might do something like a controlled vertical descent, RTL or other clever thing.
Also need to add a comment about the bullet connectors since you clearly didn't get the whole story. The reason some have issues is they are a hard connector to solder properly and worse if you have limited soldering experience and cheap soldering tools. Bullet connectors themselves are not at fault. The issue is there shear mass of the metal that needs heated means you need a big iron (40watt or more), good clean tips, and a solid way to hold the connector and the wire (helper hands). Further, the cup shape in the end when you stick the wire in is very hard to inspect afterwords to ensure you didn't get a cold joint and there is enough solder flowed into the wire and the cup. Because of this, many people have had bad solder joints and not known it. Add to that the heatshrink on top which further could mask a loose wire. That's why people have problems, it's not a bad connector, it's shoddy soldering.
I totally get it that you're pissed but at the same time, this is a DIY project. ANY radio control system (car, boat, heli, plane) has the exact same problems. The problem again here is that they sell you the aircraft kit and you add your own radio. They cannot exhaustively cover every radio out there and it's up to the radio manufacturer to give you that info and for you to follow it.
I'm thinking of adding a warning in the wiki, on the page about connecting the RX that says something about TX/RX failsafe settings and ensuring they are correctly set.
I also think there should be a big red warning in the "First Flight" section that says: until you are confident in your piloting skills and have tested the failsafe systems, do not fly above tree level/building level (as winds and distance/visibility can make the copter hard to control) and avoid high speeds (ditto).
I say this not to chastise the OP in *any* way. I am currently rebuilding my copter for the 4th time, after 3 very bad crashes all caused by runaway altitude issues because of pilot error (aka Me-the-dufus-at-the-controls). So I have been humbled by making this mistake a few times, which prompted me to try and improve the failsafe systems for ArduCopter.
I just see it as a common failure mode. We need to address this issue in two ways, IMHO: document and automate it away. Document the issues that lead to this outcome and try and get geofencing and other improvements into production.