Hi, Ardupilot 2.6 (still with thermopiles) did a pretty good job in handling our solar drone (seriously, http://diydrones.com/forum/topics/lusa-low-cost-unmanned-solar?id=7...), now we bought APM2.0 to improve the results thanks to the ultra-precise IMU and other things such as the built in compass that can help controlling such a weird-handling plane like that.
But we also noticed that ardupilot code&hardware has grown so much in complexity, and this is kinda scaring us, since it will be in charge of a $1000+ 2000hrs of labor plane...
All what it will be required to do is to keep the plane loitering with excellent precision, nothing else for the moment, our main concerns are:
- Are there some timers or counter that may overflow or something causing errors after a long period of continuative use? It will probably be around 4 hrs?
-Are there known issues for APM2.0 operating in a pretty hot enviroment? (around 50 / 60 celsius)
-Are there known issues with partially-configured autopilots? (we will not explore, at least for a while, the ardupilot`s advanced functions)
-Are there any known failsafe failures? I keep the radio in my hand for the whole flight, ready to swith to manual mode if somethings goes wrong, but is the failsafe chip really bombproof or if the APM starts rebooting or something I`m screwed?
-What other things should we take great care of to ensure the APM will work realiabily?
Are there any known failsafe failures? I keep the radio in my hand for the whole flight, ready to swith to manual mode if somethings goes wrong, but is the failsafe chip really bombproof or if the APM starts rebooting or something I`m screwed?
You really need to read some of the recent failsafe threads. There are a few issues and behaviors you should understand before flying.
I looked around the whole arduPlane section and I found only one thread about failsafe and it has almost no comment. Am I missing something? May you link to me the threads / blog postts about the issue?
First, Monroe I totally agree with you.
Secondly, I have a decent understanding of how my car is made, but the only part I need to know to be perfectly working to trust it enough to drive everyday are the brakes, I know their weakpoint (failing brake pads wear sensors) and keep an eye on them.Same thing I need to do with Ardupilot in my project I think, I don`t really care if it decides to try to flip my aircraft, as long as i can flip a switch on my TX and take manual control of it. So my bad, I misformulated the question, all of the question I posed in my initial post should be referred only to the failsafe part of the autopilot. I have been following the ardupilot project since it was born and flown it almost flawlessy for at least 100hrs(not contributing because of other project/ college) and have a decent understanding of its structure, but not even close to the point of reading it all and say "yes it`s bug free" (I`d be some sort of code-god if I could).
For college reason I have been far from ardupilot flying for a while so when I decided to switch to APM2.0 I searched here and on google what the point is with reliability and I decided to open this thread because I got very puzzling results, including a lot of discussion, cancelled post, private messages made public and even some drama about failsafe issues.
I don`t really want to get into that or spark some flame (since I honestly have no knowledge at all about this issues and/or what may be going on, I only want to find more about the issues), everything I what I need is a somehow clear answer to this: what are all the know issues with its failsafe sistem? It seems weird to me that there is all this talking about failsafe issues/PPM processor and there aren`t (or at least I can t find them ) "issues" dedicated to this point in the appropriate section on google code you linked to me, so I`m asking here more information on the actual reliability of that small part of the work of art that ardupilot is which is critical for my project.
so John, this is tested and ready for general usage (APM2 only)?
I'd like to know to put a note for my customers that want the throttle failsafe. Thanks
I have tested this successfully with a stock TH-9x with original RX (the v2 model).
John's new version of PPM completely fixes the previously reported "unusual" failsafe behavior of the RX. It now fails predictably, at least for me.
Took me about 10 min to flash and test
> the only part I need to know to be perfectly working to trust it enough to drive everyday are the brakes
Then in that analogy... The brakes are broken. If the brake fluid gets too low the engine computer will hold the motor running at the last cruise speed you used and cut the brakes.
> what are all the know issues with its failsafe sistem?
If the throttle wire or any lower signal wire (aileron or elevator) comes loose you will likely have the APM hold the throttle on. The non-locking connectors used (standard RC servo connectors) make this fairly possible given the significant vibrations present. This is known to produce a fly away condition where your plane/quad flies off and potentially crashes under power many miles away.
The 9X transmitter, and possibly many others, are known to drop the throttle signal as their failsafe mechanism. This creates the same condition where the APM begins to hold the throttle on.
So there's the long and short of the APM's failsafe problems. If a signal wire comes loose or you lose signal from your transmitter the APM may step in and hold the throttle at the last setting it thinks it received. A few people have had their gear fly off, never to be seen again.
The good news is that there's a patch for this problem. The bad news it that you #1 have to figure out that the problem exists and #2 have to do a special update procedure on the PPM encoder.
This should tell you a few things about the whole APM community... There are design flaws and bugs that may be lurking around. You may be "lucky" enough to discover one of these flaws and loose some or all of your gear. You might even run into a lot of resistance and arguments when you expose the bug to the community. However, in the end you can fix problems yourself and there is a fairly large community of people here who can help. I'm not sure why this particular problem caused so much fuss here, but it did get fixed.
All in all the APM is still totally experimental, but so are all the other autopilot systems out there. The open source ones will tell you "fix it yourself" or "you should have invested in a commercial system". The commercial systems OTOH have a lot of incentive to blame you for the problem and you are entirely at their mercy as to fixing it.
It caused so much fuss because of the politicization of the issue, largely by people such as yourself. You attempted to characterize it as a problem that the APM created out of nothing, when there was no problem before.
As I have said, this problem with aircraft running away has existed since R/C was invented. It's nothing new.
Again, the Turnigy failsafe would not, will not, stop any nitro airplane from running away. It would not stop a nitro helicopter from running away. It would stop a quad from running away, if you could fly a quad without a Flight Controller, but you cannot. You need a flight controller. Ours is very safe, it did not make anything less safe than it was before the incorporation of the APM into the aircraft. This problem only exists when you chose to use the Turnigy system with the illogical failsafe system.
My blog post from the weekend solves all this. It uses an affordable Rx with an effective failsafe, and eliminates any possibility of anything "falling off". There are no cables to fall off.
It is the end users responsibility to ensure their system is safe. You are now aware of a very safe system. It is your choice to use it or not. Period.
And your analogy is completely incorrect.
It's more like... imagine a world where cars don't have ignition switches. They are just on as soon as you get in. And imagine they don't have brakes. I don't know how you stop. But the only control you have is with the accelerator pedal. Let go, and it stops, step on it, and it accelerates.
Then your throttle cable gets stuck. Now you don't have brakes, so you can't stop it that way. And you can't shut it off.
Now, if every car is made this way, who is to blame when the inevitable happens? Well I don't know, but it just is how it is.
If the brake fluid gets too low the engine computer will hold the motor running at the last cruise speed you used and cut the brakes.
> And your analogy is completely incorrect.
Actually I think it's perfect. For the sake of brevity I left out the part where the aftermarket cruise computer was intentionally designed that way, but other than that everything still holds true just fine.
> Now, if every car is made this way, who is to blame when the inevitable happens?
I hate to burst your bubble when I keep explaining legal matters to you, but... The "but everybody's doing it" defense never has and never will work.
Just for a quick review... If your actions damage property or injure someone you are liable for the damages. If you make a faulty product that causes the same you are also liable.
Hopefully, and I pray this is true for the children's sake, you understand at least that part. The only real disagreement is weather you can be held criminally liable and/or face additional punitive damages. If anyone cares about that read the law (or even wikipedia) or go back to the first two threads on the subject.
To answer your question though... anyone who starts a car like you describe (car with no brakes and no kill switch) would be liable for all damages + punitive damages, and would be criminally liable for reckless endangerment. If someone were to die they would be guilty of manslaughter in most cases and murder 2 in some instances. To operate something like this and have it kill someone would fit the definition of "depraved-indifference murder". Hopefully that's clear enough.
I said "if you make a faulty product", I wasn't saying this is the case with the APM. It may or may not be.
I know you're not a lawyers, but you and Lefebre need to understand that there's no special law that protects RC products. They're subject to the same liability laws as any other product.
It seems like you're reading someone else's posts and getting confused in your replies. Everything I said was indisputably true. I don't know if you're trolling or trying to bait me or what the deal is here?
If I make a rope and claim it holds 200lbs. and it breaks at 150... guess who's liable? If I make a fire extinguisher that claims to put out A,B, and C types of fire when in fact I'm just filling them with flour... guess who's liable? If I make a PPM encoder that claims to pass PWM signals from input to output when in manual mode, and in fact it continues to inject a signal when it is getting zero... guess who's liable?
Now before everybody gets their panties all ruffled... I'm not saying that 3DR has made that claim or that the operation isn't spelled out in better detail in the instructions somewhere. I also think the problem is cleared up to some extent with the patch and the information now available. Weather they're liable or not would come down to the specific wording in the instructions and exactly how the operation is explained.
Make no mistake though, if you claim something for your product and it doesn't deliver then it is "faulty". The manufacturer is and always will be liable for faulty products. You can't claim something for your product and then disclaim it elsewhere. You also can't slap blanket disclaimers like "experimental" on something, that does nothing for you legally.
And yes Monroe, you can have negligent operation and a faulty product at the same time. Both people can, and often do, point the finger at each other and what happens is they usually both lose against the injured party. That's actually what lawyers hope for because they get the user and the victim to gang up on whoever has the deep pockets.
As has been alluded to, the infamous helicopter accident...
No charges filed against the pilot, or Align. "The girl was in the wrong place at the wrong time."
Frankly, I think this is bull****. The pilot is 100% to blame. Not only was he flying in a stupid location (a park with people in it), but it was even illegal to fly there by local ordinance (as if that should even be required!).
It's like somebody target shooting at a public park, and then another user gets hit by a ricochet, and they say "Well, he was just in the wrong place at the wrong time."
No, let's sue Smith and Wesson!
Anyway, the case invalidates your point. NOBODY got sued. The authorities deemed it an unfortunate sequence of events.
You need to read your own links...
"there isn't enough evidence to charge anyone with a crime."
"chopper's motor did malfunction"
"911 call and prompt medical attention were instrumental in mitigating Poole's injuries"
This news story hardly invalidates any point. #1 the police don't file charges, the DA does. It's quite common to not file charges right away. #2 you don't know if charges eventually will get filed or who gets sued. Chances are good that you'll NEVER find out, even if it's a multi-million dollar settlement since these are usually covered by a gag order.
This seems to me like an unpredictable hardware failure. AKA "accident". The guys helped out the girl, who seemed to have only minor injuries, then they even helped raise money for her afterwards. They're certainly liable for the medical bills, pain and suffering, etc.. They probably realized this and payed without having to be sued.