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!
Replies
When I say that there is the appearance of being foolproof, what I mean is not that this have been explicitly said but that is the idea transmitted to the consumer, at least it have been my personal experience ( I have had some crashes and some frightening fly away that I managed to control before it was too late). I know that this is a very difficult job but I think that we have to improve that part.
About the code:
One of the most important problems is not to have a full documentation of the code, which make a titanic task understanding the code.
A few examples that come to my mind of things that I found confusing and I found not documentation about:
-ahrs.yaw, ahrs.yaw_sensor (one of them is the yaw in rad, and the other is the degrees * 1000)
-body frame, earth frame, (when it is simply extrinsic or intrinsic rotations)
-ahrs.set_fly_forward, (no idea)
But these are just examples of a non-well documented and named code. I think that the main issue here is, as I said the structure.
Probably the main structural mistake (on my opinion) is the controller structure. The way it is does not really make any sense to me, for example one of the controllers is the rollpitchcontroller, but I wonder why are you separating the roll and pitch from yaw axis? Physically it does not make sense they are the same axis with a 90deg pahse ¿?, and at the time to tune it does not allow you to tune separately those two axis (if you have a multi with different distances between rotors, you can not optimize its behaviour), I will better explain how I see a properly designed controller structure:
The way I see it there is two options, a simple cascading one which isn’t that different of the actual one and applying control theory.
-In the first I see the controller structure in that way, there is 6d in the physical system of the drone x,y,z and roll, pitch, yaw. And they all could have 3 sub controller which would be the position, the velocity and the acceleration. And I think that the way they are connected is pretty obvious.
-The “control theory” way would be based on the idea that if you know how a system behaves, and you know how you want the system to behave you can mathematically solve for the optimal way to achieve it. In this method we could make the drone do things like get momentum and give orders not just in function of the position angle etc... But in function of time with which things like very complex obstacle avoidance or playing pin pong could be achieved ( I like to think so). But it would be difucult to adapt to any arbitrary drone because it require quite a lot of info of the drone (size, weight, motor specs) and would be a lot more difficult to develop.
But I see another very important thing too, the management of the sensors data. Now the data fusing is made chaotically, decentralized way (some is made in ahrs, other is inertial sensor and other in inertialnav with tons of functions that I don’t even know what they do) and with a non-clear structure.
How would I do it? First of all I think that a clear way on how to treat the sensor data has to be defined, I see it in this way, to fuse the data in an intelligent way and to not introduce bad measurements, every stream of data should have a Gaussian function which describes its noise, and a value that describes its reliability. So that we can use it for a more intelligent and nice looking functions of data fusing with no need of gps glitch catch or whatever other classes and functions are being used now. Obviously, every sensor will need to calculate in their own way their noise and rehabilitee but this will allow to add new sensors easily and to improve the algorithms and filters that they use in a very easy way.
Since English is not my native language and it takes me a big effort to write, I will only keep on sharing my ideas on the ideal plataform if someone is actually interested (enough for now:).
Finally I wanted to say that I an opensourse drone platform should have an API to develop applications for the drone easily. But of course is not possible to make a proper API if there is not a very clear structure of control of the drone, and even less **** if there is problems with flyaway and spinups etc…
So I think that the community and 3DR should make an effort if they want to truly exploit the potential of drones, which I think is huge!
3DR should indeed inverse on R+D of the arducopter since they are not anymore a small company that is just making hardware which is used to run this code for some hobbyist, it is becoming the one of main non-military small UAV most famous company, and should have a code that is at the expected level. What I mean is that 3DR is and should more than a hobby company but arducopter is not (yet).
So there is a lot of work guys jejeje, and 3DR have to start truly supporting the development of arducopter, if you see how, many successful opensourse projects work, you will notice that they are sponsored by companies, and by sponsored I mean that the main developers work for those companies, example: openMP, openNI, PCL etc…
Wow I just saw how long my post is ;)!
interested in your input!
Carles
My personal opinion is that alot of the problems with arducopter come from its appearence of being a reliable and foolproof plataform and it is not, I think that our responsability is to advise to everybody who uses the APM softwere of its issues, and it is a task that is not being well accomplished.
When I say that this is not a reliable plataform what i mean is that it really need you to beware of a lots of things. And that is fine, this is a open source comunity and no one is responsable of what anyone does with his multirotors, but the comunity is indeed responsable to make sure that anyone who uses arducopter is conscious of its limitations. It can not happen that someone thinks that he can buy the APM and fly it without being very carefull and taking all of the necessary cautions.
It is not acceptable for any product to have this kind of failures that although occasional are a truly potential damage which could cause serious consequences to a unprevented user, we are handling dangerous tools!
I have been looking around the arducopter code and the truth is that i can understand why that kind of mistakes happen. It is a very messy code, and is easy to say that it have been overwritten many times by many different people and without any well documented wiki. I don't want to upset any developer with my words since I dont have anything else to say to them but thanks for their work which opened the way to allowed me to research on drones, but I do believe that a restructuration is needed if 3DR and DYID wants arducopter to become a reliable plataform which can be used as a RTF, foolproof, aereal photography or any of the others fields where a drone could be usefull.
Carles.
I have been building two to four APM based units a week for the last five months. I have built countless APM based rigs over the years beginning with the APM/1280 based boards. "Almost" every situation that involved a crash was due to improper hardware setup, or operator error. Sure, there have been instances where the software was buggy, but this was almost always in beta releases, which is flown with a known risk.
It kills me at the number of people slapping hardware together after little to no experience working with it, and then trying to strike it rich selling their "frankencreations". When it doesn't work as expected they blast the hardware manufacturer for their problems, and they do this when they don't even know how to properly retrieve and evaluate log data! Really? I am all about helping people when they have problems with their drones, but not when they come out swinging. It would behoove those needing assistance to exercise a measure of civility when coming to these forums. It will get them a lot further in their efforts.
I'm sorry Thomas for your fly-away, i've thousands hours of flight with APM Copter without a single crash.
Before take off I always do a general check of the operation of sensors, tx command, altitude, HDOP and other important things pre-takeoff.
I always leave the most amount of information active in the flashlog, I always keep available the "Acro" mode as emergency and i'm fully trained to fly in manual, many times this can save me from crash or fly-aways.
The assembly of my multirotors meets quality standards high enough (mean average), following these simple rules i believe APM Copter for now the open source platform more secure in the world.
Misfortune can happen to anyone, there is too much electronic on this machine.
Wow, I didn't know I was gonna cause a such an outbreak.
Obviously, when I wrote my rant, I was pretty feakin' angry, but putting the blame totally on me is not fair, (some of you). You would have crashed too. I HAD NO TIME to make an informed decision on what to do. All I could do is initiate RTL. It didn't work. Then all I could do is try to see where it went, and PRAY!
I don't pretend to be some genius code writer, or even an expert pilot, but I am not an idiot. The barometer freaked out, and I just did not happen to notice it. That could happen to anyone. How can you visually fly and stare at MP at the same time? You can't.
I knew something was wrong, when two motors cut in and out, and I got it on the ground, and I say again, I was trying to disconnect the battery when it bolted. How is that pilot error? It was not in the air! Should I have thrown a carpet over it, as someone suggested?
New thing on checklist: even on the ground for a few seconds, disarm and do a "sanity check" on the MP. Thanks, Randy.
I am very careful about preflight check, and I had, the day before, a flawlessly performing machine, and I was singing the praises of ArduCopter. Then, not so much. Sunlight on the barometer had never been a problem before this, and one of Murphy's Laws is "if it's not broken, don't fix it". And I also know the main rule: "anything can break at any time, for any reason", but let's not devolve into a discussion of Murphy's Law. All I can say is that Murphy liked to follow me around. I used to build very expensive Home Theaters for the rich and richer, and I always seemed to pick the "defective in box" equipment out of the warehouse. Go figure. My first sets of esc's and motors---Murphy! Send 'em back.
Mr. Lefebvre, thanks for all of your positive input and analysis. I should have been more aware of this sunlight issue, and since it seems to a build problem, by me, I'm gonna try again, very, very far away from everything. Iv'e built a damn-near bullet-proof frame, I just want what we all want, flawless control and error free flying.
How about this: If the APM has to much conflicting info, or bad info, and the accels aren't moving at all, (cuz' it's on the ground), it just won't arm.
If that happens in-flight, it goes into stab and hovers, in place, giving the pilot enough time to make a decision on whether or not to hit the "panic button", if control can't be regained.
Peace everyone,
Tom
Hello Thomas,
Had 2 times! Have the same problem with a large Hexacopter.
Full throttle, it could be on pitch and roll control but not up to par.
I just got one seriously injured (when holding) (13 * 6.5 Carbon Props)
new APM 2.5 installed and the other found by 1.5 km further back.
Have 6 new 40 A Roxxi ESC soldered, now it works :)
Despite hospital surgery on her right hand and big material damage I swear on Arducopter.
Problems were always in debt through me.
Have a total of 6 air systems everything works if you clean it properly builds excellent.
Sorry for my bad english but I had the sure to tell here,
Best regards from Germany, ciao Klaus
Personally, I think it's a good thing people are expecting APM to be reliable/bulletproof. It means it's maturing from a DIY circuit board to a polished product. A stance 3DR is happy to advance, what with it's drive into agriculture. They obviously feel that ardupilot is commercial grade now.
Is it unfair for new (commercial) users to expect plug and play reliability and solid flight? No, I believe it is not. It's the reason NAZA's sell so well.
I personally believe Pixhawk & arduxxxx are an industry leading combination...but some work is needed to meet the expectation of some of the new adopters, who expect "Ipad" levels of reliability and simple usability.
MP is helping there - but there's still a long road ahead. There's no "Compassmot" program under "Mandatory" in initial setup, or in the Wizard. It's still hidden in Terminal. This is my bugbear from 2013 - my 2 crashes were due to compass inteference rendering my rigs almost unflyable, and I missed a commercial shoot because of it, trying to work round it, and effect repairs. If ardupilot is to be treated as a commercial product, upgrading the OS should not render it unflyable.
On the upside - Autotune is industry leading IMO. If/when yaw can be included, it will really make ardupilot the best controller, and make it easier to attract new uers.
As I said - as the product matures, people are going to expect more from it. They will even expect miracles from it. But in this "ipad era", most of all they will expect it to work 99% of the time, with as little intervention/tweaking/optimising from them as possible.
Edit: I know some will say "But ardopilot is a DIY product"...well, I disagree. Yes, that will be a subset of it's users who will like the this. I will be one of them. But the way 3DR is pitching itself and it's products, it's after commercial customers as well. And man hours spent tinkering/optimising, are man hour spent - not earning. That me as well. It 3DR are to succeed, the time it takes to install a pixhawk, and being able to flying an optimised rig needs to be less, and the task easier to perform.
The problem isn't when all is well. It's when confusion enters in and very quick reactions are required.
Again this is more an issue with some glitch (as opposed to fence or battery).
So first glitches should be caught and prevented (ALL INS glitches) and second
a glitch should initiate a manual mode... stab. No guessing what's going on, you save it.
The problems we've had, like this, are when it gets past a glitch, it enters some automode with bad directives, the user tries to save it, not really sure what mode it's in and where it wants to go. And it sometimes even goes in and out of modes by itself.
The worst (with auto-manual with glitch) is that you are all of a sudden in manual when you think you should be in some auto-mode. But manual recovery is completely natural at that point, and probably not too violent if the glitch has been caught.
Perhaps there could be a parametric override of the entry to stab, at your own risk.
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.
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.)
-
1
-
2
-
3
-
4
of 4 Next