Replies to This Discussion

DeveloperPermalink Reply by R_Lefebvre on June 11, 2012 at 11:54am

You are so completely wrong about all of this.  The event happened a few years ago, 2-3 years?

Nobody has ever, or will ever be charged.  It's case closed.

This was no hardware malfunction.  Several reliable sources, surgeons and trauma doctors who also fly helicopters stated that there is no way those injuries happened unless the helicopter was powered.  The motor did not fail.

The original news stories which are now missing, indicated that the boy was "buzzing" the girl.

There is a No RC Aircraft ordinance for that park.

After calling authorities (give him credit for that), the boys packed up their stuff and fled the scene.  It took a community witch-hunt to track down the identity of the boy.

The boy did nothing to raise money for her.  THE COMMUNITY DID THAT.

The boy has never been held responsible for any part of it.

You want to play lawyer, you better darn well get your facts straight.

Permalink Reply by Jake Stew on June 11, 2012 at 12:04pm

I fail to see what your point is.  You can't show that they weren't charged and you can't prove they weren't sued into the ground.  Even if they weren't it still doesn't matter jack squat.  Not every illegal act is prosecuted and not every liable person is sued.

I'm not going to dig through hundreds of posts to follow up on your links which I already pointed out are irrelevant.

DeveloperPermalink Reply by R_Lefebvre on June 11, 2012 at 12:11pm

So now you're asking me to prove a negative.  That just proves how empty your logic is.

This discussion started because I asked YOU GUYS to prove (prove a positive) any case where ANYBODY was sued, personally, because an aircraft under their control crashed into somebody due to faulty/missing failsafes.

It HAS happened.  People have been killed.  So find the case.  Should be easy.

Permalink Reply by Vernon Barry on June 11, 2012 at 10:24am

My only response is that do you blame the STOCK ESC firmware actually driving the motor? Shouldn't it have a failsafe?

Prove this to yourself with most ESCs and specifically, the RC Timer and DIY drones brands of escs. Others seem to do this too.

Spin motor up with a servo tester, radio receiver or even the APM.

Unplug the signal cable to the ESC.

On 12 different ESCs all 12 continued to spin under power for up to a second or two after the signal cable was removed. This is due to the de-glitch filter present in most ESC firmwares.

Is this not a possible cause of crashes and flips when upon loss of signal, the motor retains the last speed for up to a few seconds? Is this not also a safety issue where you pullled the plug but the motors continue to spin for any amount of time? Wouldn't it be logical this ESC firmware interaction could throw off the PID settings making them invalid?

Luckily, the SimonK firmwares for compatible ESCs resolves those issues, but if you choose hardware that does not, then all bets are off.

The number 1 problem with the system is that we use off the shelf components to gain a cost advantage and thus each device introduces it's own quirks and problems into the system. Only with a closed system of limited hardware and firmware could one ever hope to achieve a sense of stability.

 

I'm not saying the APM is perfect in any way. What I am saying is that I don't see the same backlash against off the shelf components such as the receiver and the ESCs that also contribute to failsafe and general safety issues. Further, shouldn't every LiPo come with a  hardwired BMS to prevent overdischarge, overcharge, and short? Again, it just doesn't seem right to throw the liability card, when clearly, the pilot is responsible for the system. You chose the parts, you wired them together, you applied power.

• ▶ Reply

Permalink Reply by Vernon Barry on June 11, 2012 at 10:47am

My point here is that this entire wiki is about open source systems. You buy the APM and then attach it with other off the shelf hardware that you the pilot decided to buy.

-What other things should we take great care of to ensure the APM will work realiabily?

The OP eluded to the PPM discussion and my point here was that OTHER parts of the system that had not been brought up yet in the discussion are just as likely to not "FAIL SAFE".

You must look at this from a system view and that's why the liability statements are just out of line in this discussion.

Let's talk about Technical issues, and leave the BS at home.

• ▶ Reply

Permalink Reply by Jake Stew on June 11, 2012 at 11:23am

I've explained this too many times here already.  Let's break this down step by step so I can diagnose the logical breakdown for you.

1.  You make a product, along with this certain claims are made, such as what it can be used for.  This is a warranty of fitness for a purpose.

2.  You provide instructions how to use the product.  The instructions describe how the product is supposed to work.

3.  The user follows instructions and product fails to work as described causing damages.

Tell me what part you think is wrong so I can better explain to you what the law is.  Those three steps above are ALL I have to prove in court to get a judgement against the manufacturer.  

There's no way to get out of this.  If you make a product there are claims associated with the product... intended use, fitness for purpose, merchantability, etc..  If your product doesn't live up to the claims then it is faulty.  The manufacturer is liable for the results of faulty products.  This is totally separate from who else may also be liable.  Maybe I shouldn't have flown in the playground and this makes me negligent or reckless, but it doesn't absolve the failure of component X.  Component X is still just as liable because it failed to live up to it's claim.

So in the end all we really have to argue over is what is claimed for the APM.

• ▶ Reply

Permalink Reply by Vernon Barry on June 11, 2012 at 11:31am

The part where you choose what the other components are.

The part where you physicially make the wiring connections and solder joints.

The part where you plug in the battery and make a decision to fly.

The part where you choose the flying site and ignore safety precautions.

Fault in X doesn't make up for the fact you put it into public and powered it up.

 

 

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on June 11, 2012 at 12:08pm

Jake, please show me where on this page:

https://store.diydrones.com/APM_2_0_Kit_p/br-ardupilotmega-03.htm

any of claims are made which you are suggesting.  Where does it say what the board does?  It says "allows the user to vehicle into a fixed autonomous vehicle."

Well, the same can be said about the Dell laptop I am writing this on.  Are you suggesting that if I download some software from the internet, install it on the laptop, and the laptop crashes a vehicle into somebody, that you can sue Dell?

There isn't even a link from the Ardupilot hardware page, to DIYDrones or Arducopter software.

• ▶ Reply

Permalink Reply by Cliff-E on June 11, 2012 at 1:43pm

Back on subject:

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

 

Let's set the context 1st. The s/w is part of an open source project and mainly hobbyists are using/developing it. 

If your project is commercial, has legal implications, of high dollar value, or mission critical, look at your project from a career engineer's point of view--it's not a 'buy a couple of parts from 3DR, slap it together, download some software and go'. The APM is not really built for that [yet]. Thus, one thing that needs to be addressed in your effort before analyzing any bug list (h/w or s/w):

Develop TEST PLANS and TEST, TEST, TEST..... If the error is non-repeatable, you are shooting in the dark to solve it as well as possibly giving the dev-team a red herring to chase. For cutting edge tech, white and black-box testing are safeguards and will save you coin (and keep you safe).

My company is using the APM much like your scenario--and have taken a very conservative approach in testing and s/w mods. So far so good--though we have some random errors that only functional testing should be addressed 1st before ranting to the dev team.

The APM is much like the early Linux days--would you use Slackware Linux 2.0 to power your TV, car, or even a power plant? Folks did back then, where project code reviews as well as testing were important--hence why we had so many forks and custom kernels. Heck, I'm sitting run next to a robot that interacts with the public running a custom 2.2 kernel--and testing made it happen. The dev team can only test so much against limited use cases.

• ▶ Reply

Permalink Reply by Ludovico Antonio on June 11, 2012 at 1:49pm

As the topic started i couldn`t agree more on the back-on-topic thing ;)

After reading all this I am so glad that 1) I am fully insured for damages caused by r/c aircrafts and/or drones 2)I use only top-notch (Futaba) radio gear. I cannot see myself doing differently and I really hope everybody here is insured, I think it is REALLY a hazzard flying r/c aircraft uninsured, even more if they are able to fly autonomously past the range of sight - i hope someone agrees with me about this and maybe passes this message on and I don`t get insulted as I got when I proposed a group insurance policy on an Italian forum where almost 60% of fpv/drone pilots were uninsured...

This said, back to the PPM/failsafe point :-)
As far as I understood the known issue is about signal absence from the RX.

1) Are there other known issues with the failsafe Ic?

2) Do developers reccomend to install the "PPM Patch"?

3) After patching the PPM thing do I have the same level of safety I have on my "old" ardupilot, at least about the possibility of manual ganining control of the aircraft?

4) do you reccomend me making some sort of electronic, R/C operated, manual bypass sistem of the whole ardupilot board or you believe that the added complexity from that would overshadow the advantages it can bring since the ppm chip once upgraded does its job propely?

Thank you again, Ludo

• ▶ Reply

DeveloperPermalink Reply by John Arne Birkeland on June 12, 2012 at 5:25am

1) Are there other known issues with the failsafe Ic?

Failsafe on the APM is two part. The "blackbox" PWM to PPM encoder and the FS logic in the main APM code.

Currently the only known issue with the PPM encoder (ArduPPM) is that the loss of a single channel will result in the PPM encoder maintaining the last known channel value. When balanced against the need for good general performance (stick resolution and low latency), this known weakness was deemed acceptable. Later because of the issue with 9X throttle FS, a patch for missing throttle signal was added at the cost of slightly degraded stick resolution/latency. I am looking at a possible solution for detecting single channel loss on all channels, but at the moment I am not promising anything. I will not accept FS logic that degrades stick resolution below 1000 steps.

But the PPM encoder is just a small part of the signal chain. The end result is a result of how the FS logic in the main code handles the PPM stream from the PPM encoder. ArduPilot and ArduCopter has different needs and reacts differently to certain FS conditions. Other developers are better suited to explain the details of this.

2) Do developers reccomend to install the "PPM Patch"?

If you have the 9X/receiver combination that drops the throttle signal, yes. Anything else, no.

3) After patching the PPM thing do I have the same level of safety I have on my "old" ardupilot, at least about the possibility of manual ganining control of the aircraft?

APM1 still has manual override on channel 1-4 (input signals from the receiver is muxed straight to the output pins), APM2 does not have this override hardware, and depends on manual mode in the APM code working. Both methods are totally useless (for manual control) if the receiver dies completely, which frankly is the most likely scenario if there is a electronics problem.

4) do you reccomend me making some sort of electronic, R/C operated, manual bypass sistem of the whole ardupilot board or you believe that the added complexity from that would overshadow the advantages it can bring since the ppm chip once upgraded does its job propely?

I cannot give an exact answer. You have to decide if the likelihood of manual recovery is higher then the cost of added complexity using a dual receiver and manual fail-over (R/C powerbox) system.

• ▶ Reply

Permalink Reply by Ludovico Antonio on June 12, 2012 at 7:33am

Tnks :-)

I dont really get point 3: Isnt the "output forwading" handled by the code on the ppm chip itself? So if the main cpu start rebooting I can still gain manual control??

• ▶ Reply

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