Replies to This Discussion

Permalink Reply by Vernon Barry on April 30, 2012 at 5:29pm

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

• ▶ Reply

Permalink Reply by Jake Stew on April 30, 2012 at 5:50pm

   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.

• ▶ Reply

Permalink Reply by Vernon Barry on April 30, 2012 at 6:09pm

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

• ▶ Reply

Permalink Reply by Vernon Barry on April 30, 2012 at 6:32pm

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.

• ▶ Reply

Permalink Reply by Jake Stew on April 30, 2012 at 9:01pm

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.

• ▶ Reply

Permalink Reply by Richard on May 5, 2012 at 9:30am

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?

• ▶ Reply

Permalink Reply by Jake Stew on April 30, 2012 at 9:07pm

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.

• ▶ Reply

DeveloperPermalink Reply by Andreas M. Antonopoulos on April 30, 2012 at 9:24pm

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. 

To summarize:

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.

• ▶ Reply

Permalink Reply by Jake Stew on April 30, 2012 at 10:18pm

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.

• ▶ Reply

Permalink Reply by Richard on May 5, 2012 at 9:29am

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.

• ▶ Reply

Permalink Reply by Vernon Barry on April 30, 2012 at 5:38pm

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.

• ▶ Reply

DeveloperPermalink Reply by Andreas M. Antonopoulos on April 30, 2012 at 9:34pm

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.

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page