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
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
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
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!
Replies are closed for this discussion.
I need to point out that a lot of aircraft, hang glider and para glider instruments all use semiconductor baro's.
Also a lot of medical equipment these days !
You can bet your last cent that the manufacturers of most of these baro's has wrung out all the bugs.
I flew hang gliders from 1978 to 2012, and never ever had my instruments go belly up on me.
So unless there is a hardware problem, I would hesitate to call the code into question, since a bunch of people are flying, repeatedly, without problems.
It would be interesting, to compile some statistic on failures of stock machines, vs own design or hybrids.
We had an "interesting" problem with a 3DR Y6, that would randomly flip over and crash during flight.
Turned out to be a bad motor, Wessie posted a video somewhere here.
How about the "panic switch" turns off the motors AND deploys a parachute.
Code guys- start writing!
This could easily be a standalone system with a servo signal controlled relay on a dedicated channel...not saying its a good idea though.
Or an electronic switch that cuts the PWM lines, so you don't have to deal with high amps of the mainpower.
I can make one of those way cheaper!
Everything from Photo Higher is "higher" dig.
James, there's one issue with this, and I had wanted to reply to CP's post but didn't get to it:
The pilot always did have the option of control. He never exercised it. Not assigning blame or fault, but it's just a fact. The system entered a fence breach failsafe mode, and I'm guess he didn't know that. He could have regained control at any time by simply switching modes. But it appears he didn't. I can see the Ch5 mode switch, and it never moves, except for one time at about 21:27:52, and in fact that appears to be a Rx failsafe, as all Ch's move. They then return to their previous settings.
Now looking at how the failsafe was set... First, he doesn't have Throttle Failsafe enabled, so even though the Thr channel goes low, nothing would happen. All the controls go to the middle, except it changes to Flight Mode 4, which he has set at Alt Hold. So, with zero throttle, it will descend. Some might think this isn't a good setup, I actually think it's not horrible. It would cause the craft to basically go into "neutral" roll/pitch, and descend flat, under control.
However, I also notice that GPS Glitch protection is turned off, while fence is left on. This is probably a bad combo, as a serious GPS glitch can lead to the copter blowing through fence lines, chasing a bad GPS position. I'm pretty sure I've seen this explained as being a very bad thing. Is it in the wiki? If not, it should be.
Anyway, it does appear that he had a moment of RC control loss and his Rx went to FS, then it came back.
But really, my main point here was that he never switched modes to take back control. And he could have.
I completely understand that in the panic and confusion of the event.. this happens. But it's not fair for anybody to say that the autopilot took control, and wouldn't give it back.
All that being said... I don't use Geofence, or GPS failsafe, or battery failsafe. When an error condition occurs, I want to be the one deciding how to handle the situation. If the best thing is to kill it, I'm going to do that. If the best thing is to return under manual control, I'm going to do that. 99% of the time, I have found the best course of action is actually to climb. That buys you time to assess the situation and decide what to do. I've had it go into auto-land unexpectantly before, and I really didn't like that. I never want to be in a situation like Thomas where it suddenly changes into an auto mode, and you're not sure why. Or even aware that it happened.
That's my personal opinion, and it disagrees with the majority of the other devs. That's fine. I'm glad it's my choice to make with this software.
What I would NEVER allow would be a situation such as you show, where it passes some fence, and then just shuts off. That may seem like a great idea if you're flying small quads, 12" off the manicured lawn... It's NEVER a good idea to just crash land a helicopter or large Octo.
What would happen if, during a GPS glitch, it zips off over a crowd, and then just shuts down? That doesn't make any sense. Or, the word "crowd"... what if it flies over the pits at your field? Could be 100 feet altitude, plenty of altitude to give you time to solve the problem, think the guys will like it if just shuts down and crashes?
IMO, these systems are nowhere near smart enough to be making decisions like this on their own. I operate under the premise that the pilot should always be Ready, Willing, and ABLE to take back manual control, and make the best decision. The auto functions are pilot aids, not replacements for the pilot.
The only exception to that is RC Tx loss. But that is a failure event. If the autopilot doesn't handle it well... it's probably 50/50 that it would be better or worse than just a simple lock-out crash would be. And in the majority of cases, the autopilot will perform well, and save the day.
I've yet to ever have an RC Tx problem since I started using FrSky 2.4GHz 5 years ago.
As for the panic switch, to shut everything down, I have actually argued for exactly this myself. We already have that on helicopters. Ch8 absolutely controls the motor. If you turn it off, the motor stops. Period. No matter what mode. I think it should be an option for multirotors too. The only thing is, you need to remember to set Ch8 high on your RC Tx Failsafe. Or else if you have an RC Tx failsafe, it'll just shut the motors off and crash, instead of RTLing.
I hear you about having control all along and that's what I meant by dumbthumbing. I remember we used to talk about it when you'd watch yourself fly into the ground all the while telling your thumb to pull up. Sometimes humans just don't respond well. I think you commented earlier than you always need a computer too cause if you get disoriented as to what it thinks it is doing you'll respond even more inappropriately. Full ack!
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.
"Now looking at how the failsafe was set... First, he doesn't have Throttle Failsafe enabled, so even though the Thr channel goes low, nothing would happen. All the controls go to the middle, except it changes to Flight Mode 4, which he has set at Alt Hold. So, with zero throttle, it will descend. Some might think this isn't a good setup, I actually think it's not horrible. It would cause the craft to basically go into "neutral" roll/pitch, and descend flat, under control."
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.
"What I would NEVER allow would be a situation such as you show, where it passes some fence, and then just shuts off. That may seem like a great idea if you're flying small quads, 12" off the manicured lawn... It's NEVER a good idea to just crash land a helicopter or large Octo.
What would happen if, during a GPS glitch, it zips off over a crowd, and then just shuts down? "
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.
"As for the panic switch, to shut everything down, I have actually argued for exactly this myself."
Yea, we have an arm on switch option which some people like for this. Alternatively 1 second in the disarm position will shut it down under any more. Either way, you are right there should be a well known and robust procedure for users to bring down any bird when they panic. That's super critical. Failsafe terrifies me because by definition you lose that option.
Anyway sorry that is my opinionated rant. I think you guys are doing a great job of dissecting these cases and trying to figure out how to improve on them.
@Thomas - as someone said above, you won't get that level of support from a proprietary company. Just "you must have screwed up"
Randy, this seems very similar to the issue I had the other day. I wonder what can cause it in mine and his. Same barometer units or just plain coincidence?
I do agree with you. I too used those "stiff" props wich needed to be very well balanced and had a lot of crashes because they brake in mid flight near the hub. I begin to check them before each flight and noticed the plastic to be stressed near the center hub after 2 / 3 flights. Also had 1 or 2 problems like the one reported and after using APC and pure carbon props I never had problems again. They did generate a lot of vibration. Problems like this also happened before I decide to use a uBEC to power the board and was powering it up via ESC BEC.
As a newcomer to APM, I have wondered why GPS altitude is not used or at least referenced as an altitude data redundancy. Maybe it is and I am unaware of it but it just makes sense to me considering the apparent proliferation of problems with barametric sensors.
I do remember reading somewhere that if you disable the onboard barometer/pressure sensor, apm will take its alt from the GPS so I'm guessing there's a good reason for not using it?
@James and Rob
As you both know there are countries with regs that do separate people and flights. They also demand the operator to switch off command and control links in flight tests to prove what happens.
We absolutely need to encourage a safety minded approach to UA flight. Its not standard RC flying it requires more thought.
When its going well its boring as anything when it hits that point you know you are doing it right.