OK, THIS IS A RANT!!

I am done with Arducopter! I have been trying to get this platform to be reliable for way too long.

I don't even want to add up all the damage, time and money I have wasted trying to get this flight

control system to work as advertised.

I actually thought with the new firmware and M.P., that the developers had finally got out all of the

bugs.

NOT!!!!

As I write this, I notice that the top discussion is unexpected scary start-up.

This is what happened to me:

I dumped all programs from my computer, and reset my APM 2.5, I started over.

I downloaded the new versions clean, without any of the zillions of updates.

I was so excited to see that my project was finally working very well, a doing what I told it to, and it

worked very well for two days. On the third day, without any changes at all to anything, it did a full

throttle cut. I turned it off, rebooted my computer, and started over. It behaved normally for about two

minutes, then two motors cut out. I was only up about six feet, and over a lawn, so no damage.

As I approached my machine, to unplug the battery, two motors started to spin at different speeds.

Then they all spun up to full throttle. I always carry my Aurora 9 with my left thumb on the throttle

stick, so there can not be an accident.

OFF IT WENT, into the sun. Hit return to home, no joy. I said goodbye to it, as it went to an unknown

altitude, and into the sun, (downwind, it was just trying to go straight up).

I found it the next day, see the picture. Two miles of walking and searching and cussing.

I went over the logs, and determined that there were error codes all over the list, and it breached the

geofence, but kept going anyway. It had a mind of it's own, TOTALLY NOT COOL, and VERY, VERY

DANGEROUS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

If this had happened in a more densely populated area, I might be in jail right now, or being sued, or

worse. "Drone kills baby", on the eleven o'clock news. My machine is big, heavy and damn-near

indestructible. I do not know how far it fell, I going to guess at somewhere between 700 and 1000 feet,

(angle of sun, do the trig.) Now it's broken.

I want the FAA to let us do this, but if these kind of failures keep happening, someone's going to get

hurt, and then the Government will make it illegal!  Game Over!

What is up with all the flaws in this platform? Ardu may kill any chance for guys like us to go out and

make money with this tech, before the FAA and Congress even make their decision next year.

Oh, and by the way, I was to show and demonstrate my machine to a government contractor, with a

C.O.E., who shall remain nameless, the very next day. I got to show them a hulk. The only plus was  

they were impressed by my build, because it's still repairable, and the expensive stuff lived.

My suggestion to ARDU is to get your shit together. Something very bad is going to happen, it already

has to me, and if someone had gotten hurt the other day, and I was being sued, I would sue ARDU.

Then it's all over the news, and all over for us. This "mishap" was of no fault of mine. Does the

software rewrite itself? Did someone embed malware into it? Did the hardware just "decide" to melt

down?

You guys need to perfect this, or it's not going to go well with the FAA.

If they were to ask me if it is a safe and reliable platform, I would have to answer "HELL NO!, take it of

the market, before somebody gets killed." I am not giving up on this technology, just Arducopter,

and SO SHOULD YOU ALL!

UN-FREAKIN-BELIEVABLE!

Views: 23193

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

Chris, GPS altitude Is very variable and not really a thing you can count on....

I strongly suggest people use an independent failsafe system that you can trigger. Not that the APM has any issues, just to ensure a last resort recovery. Common sense needs to be applied.

I've never used geofence/height limit, and in two years and 8+ different APMs and rigs I've never had a fly-away.  Maybe geofence is more trouble than it's worth!

The only big problem I've had was when I went into auto with the compass miscalibrated, so the copter swung wildly off course and I had to land it in manual.  Before I switched to APC props I used the brittle black ones, and I had quite a few crashes due to broken props mid flight.  I've also had a few power failures mid flight, presumably due to my mishandling of the power supply to the APM (hint: the cable between the power monitor and the APM should be nice and long so gravity cannot tug it out of the socket.)   

completely agree on the PM cable. the one that ships is waaaay to short. Ive added some hot glue to mine so they dont pop-out. and with a little shot from the heat gun i can still get it out if i need.

i got "lucky" and had a BEC wired wrong, so somehow that gave me power, and my ground station freaked out since i suddenly had 4volts on my battery.

In Commercial aircraft autopilots AND Industrial Control Systems, a system should never enter an automatic mode by itself.

I'm not even that sure "auto-go-around" is an option, the pilot must initiate it.

Commercial aviation protects life, which we could say we may be doing as well with vehicles over people.

Things like RTL are obviously nice, after all we are not in the cockpit. But we SHOULD be under positive sight and control of the aircraft.

Also in Commercial industrial systems, it is just too dangerous that a machine starts doing things on it's own.

So we should have at least "Stabilize" as a glitch mode protection. And the whole INS system should be glitch protected.

No sudden changes outside of a reasonable amount. In aviation for instance there are no turns with more than 30 deg back, no brisk moves, so anything "violent" would set the glitch detect off and go into stabilize mode.

For those who are working in auto/auto over remote terrain and no people they could have other options for failsafes.... the worst would be a crash.

After 5 pages of discussion, dedicated work by people helping to analyse the incident, it can be summed up in 2 words why the crash eventuated, PILOT ERROR.

Just a note, I wouldn't want to loose my RTL features.... but perhaps if the failsafe is not a glitch failsafe, the more comfortable failsafe actions could remain.

You can change when the RTL triggers, its up to you.

I heared there is some hardware designed for the demands of the UAV Outbackchallange.

http://www.millswoodeng.com.au/failsafe_device.html

However, the problem I was suggestion with the systems response was it got disoriented and was able to perform a flyaway. I'm arguing -- probably wrongly ;-) -- there should be enough defaulting to "something is weird, let's crash" that this is impossible. Of course that comes from my bias that crashing is part of life and it should just be done safely.

IMO, this is the wrong approach to take.  "Always fly as far into the crash as you can."  That applies to autopilots too.  If you just crash every time something goes wrong, you're going to be spending a lot of money.  Sensors disagree really often.  Even on a perfectly functioning Arducopter, there's disagreement.  So decided that "something is wrong here" amounts to the programmer literally drawing a "line in the sand".  Where is the line drawn?  There will always be critics who say it should have been over here, or over there.  Crashes when there didn't need to be one.

In this case, though, it was part of the problem, right? If the baro is failing in this way alt hold is going to be doing something unpredictable which is the worst thing you want as a failsafe behavior.

I didn't say it was a great thing.  I said it wasn't horrible.  Alt Hold is one of my preferred modes.  But largely because I never have Alt Hold problems.  I've only ever had one "altitude flyaway", and that was on a clone F330 frame with no damping that I knew was going to cause problems.

It should never get there IMO. You describe a situation where something is flying autonomously, blind, and over people. The moment anyone is doing that they have already made a huge mistake. There is no "correct" response. Thinking this way needs to be a culture shift in this hobby. This is why we will actually need something resembling certification to try and fly those sorts of maneuvers.

The way people should be flying anything autonomous capable IMO is to define a geofence that does not include anywhere people will be. That way if everything goes the worst, all you do is destroy an aircraft and do not risk people safety.
Then you have internal geofences etc that tell it to RTH so you never get there. You get confused or something goes wrong and great it hopefully recovers. But a hard fence simply covers cases like this where a combination of conditions and bad luck can allow a complete fly away which I consider the worst possible outcome.

Not to be too harsh but... this comment shows a lot of naivety about this stuff that is very common amongst all the people who thinks they could design a better autopilot than us, but never have.

You completely missed the point.  Say you're at your club field, doing a GPS position hold over the runway.  Over your "home point". You have a GPS glitch, and the virtual home point reported by the GPS suddenly flies out over the pits.  No Geofence will save you, because your virtual fence line moves with the GPS glitch!  It doesn't know ground truth.  It only knows GPS coordinates. If you have a geofence line 100 feet from your home point, and the home point moves, so does your geofence.

Geofence does nothing to protect against GPS glitch flyaways.  We've seen this a number of times.  GF can even cause more problems that it solves.  You can be flying in manual mode, and a glitch occurs, and move the GF fenceline over where the copter is hovering.  In our case, it would switch to RTL from manual mode, and suddenly zip off!  In your case, you're sitting there, and then it just shuts down and crashes?  Come on, nobody is going to accept that.

Now, I already know that you're going to say in the case where it suddenly darts out over the pits, that you'd take back control and kill it manually before that happens. So what happens when you're 100 feet up, it zips off, you kill it, and momentum carries it into the pits as it falls anyway?

Insta-Crash(tm) is not the answer. 

Failsafe terrifies me because by definition you lose that option.

That is not true.  The operator can always take back control from a failsafe.  The problem happens in the confusion about what is going on.  That is why I do not like these failsafes that grab control of the machine suddenly, without warning.  GCS's help a lot.  But still, in the heat of the moment...  I won't use these features until there is a warning period set up.

The only exception to that, that I have seen, is Leonard's recommendation of setting the geofence parameters to some HUGE number like 500m, which is beyond any GPS glitch I've seen.  He lost a quad because he had it in Alt Hold (a manual mode) and then lost his Rx for some reason.  It just drifted away in the wind and there was nothing he could do.  A 500m geofence might have eventually brought it back, with minimal risk of having an accidental fence trip.

I completely agree Gary.  

The problem is this industry is heading in a completely different direction.  Autopilots are being sold as replacements for piloting skills.  This is probably OK in the lightweight hobby field, with people flying 4 lb quads in safe locations.  But I think it's a huge problem in the professional field with larger machines.

If we ever get to the point where these systems have true visual navigation, then maybe.  But not yet.

Does the Google Car drive purely on GPS?  No, it has a complicated vision system, and a billion lines of code telling it how to deal with the world around it.

To whoever:  This page and this page may be useful for your searches.

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service