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
I've added an inertial-nav vs baro altitude check into the pre-arm checks. So it will throw up a message, "Alt disparity" on the HUD when you try to arm if it finds that the two altitudes are more than 1m apart. This won't make it into AC3.1.1 unfortunately but it'll go out with AC3.2.
A barometer sanity checker would be even better but until then, I think that this would have caught Thomas's issue.
Just a word to cheap carbon reinforced Propellers. Beside APM I also get a NAZA v2. I built a hexacopter, first with superb Pure - carbon propellers 11x5.5 and it was flying very well. But because the flight time was quite short, I experimented a little and changed the props to 11x4.7 to see if the flight duration will be prolonged. I purchased those cheap carbon reinforced things and balanced them quite exact, thinking they would be good only if they were good balanced. But what happened was a shocking experience. I changed nothing else but the props (no settings, no calibration, definitely nothing). I started in Atti mode just like before with the carbon props. The hexa was dancing like crazy, in absolutely unpredictable behavior, not stabilizing or holding anything. It acted like a helicopter after ground contact with broken blades. I landed after a couple of seconds in a pile of dog shit on the corner of the field with shaking hands ,big eyes and two broken props. DJI claims that NAZA has an internal vibration dampening and you do not need to decouple it from the frame. Well probably sells DJI better props than those i had on my hexa. But i am sure now, balanced quality props are crucial. Dosen´t matter if you have an APM or NAZA.
Peter
Hi,
Sorry for Off Topic but this thread give me an question (i'm new to APM 2.6, flys helis only):
If i will use the shell (stock case that comes with APM) i still have to use the sponge on the baro?
And if my copter goes into RTL mode can i regain control to stabilize? I mean if i fly in stabilize mode and hit the geofence and copter goes into RTL i can switch to stabilize mode and turn off RTL? Or i have to wait as copter will go back?
Thomas.
Been trying to avoid this thread, but tossing in my 2 cents anyway,
"
"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."
A lot of people have this problem, but this response is, for this group and this place, just plain inappropriate.
This isn't an IPad or even a Nexus or a Car or a PC, this is the place where you come when you want to be on the bleeding edge.
If you fail to understand that and feel you've been mislead by rosy claims of everything working perfectly, then obviously you haven't been reading these Blogs.
This is the leading (and bleeding) edge, it bears almost no relation to a traditional business and for the most part is not trying to "sell you" anything.
The code is in a constant state of flux and improvement and so is the hardware.
By the time any portion of it is fully debugged and operating perfectly, we have already moved on and introduced more nifty new features (with more problems).
So what, for most of us that is WHY we are here.
If you want a fully debugged commercial product you can't have it, in this field they don't exist for individual human beings who are not affiliated with the government.
You can get less capable devices that are a bit more commercial, but most of them approach the same level of problems you will find here too and they don't do as much.
This is like personal computers in the 1960's, we are inventing the future, it is a rocky process.
But, God is it an interesting place to be.
I voice my gripes too (I hate DF13 connectors), but my expectancies are in line with life on the bleeding edge.
Wanting it to be otherwise will accomplish nothing and if you can't take the heat, go away and stop bothering the rest of us.
See, I get to rant too.
Best regards,
Gary
Wow have followed this from start to now and can see both points of view from experience and reading related forum/forums
I will agree that initial contact with arducopter does indeed install faith and trust in its reliability and it is!.Tthe main problem
is it is so full of features/parameter's that it is easy to make that one slip of setting and have a disaster which instantly has you directing your anger at the creators or the device itself, I have seen many changes to the software and cant think of
any that has made it more dangerous or unreliable, quite the opposite ! . I also agree that their maybe glitches that exist
and may not come to the fore until specific circumstances are met and then crashes happen but there are so many factors to
allow for and I think before you let the rants begin some perspective would come in handy.
If in any way you are misled about what apm can do then you may have grounds to rant
We all choose this platform of our own choice and understand the risks as disclosed in many you tube vids and forums posts and rants.
Yes is it easy to make a mistake! yes hardware will fail! yes this hobby/pastime/work is fraught with dangers and mishaps
All I will say is take it slow but remember even doing this will not void you from the Sh** happens phenomenon you and I are human , your not alone
Safe flying
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 found this discussion extremely facinating. In the beginning a furious pilot. After a number of replies and fruitful discussion, I hav learnt a lot on Ardupilot an possible errors and hinderings for a Ardu-beginner.
Thanks to all the contributors!
I have zero crashes after hundreds of flights directly due to anything Arducopter based. A few wobbles but all recoverable. My Naza V2 caused massive destruction of my gorgeous octo so go figure. Anything will cack at some point but so far the most reliable option has been Arducopter. Numbers don't lie.
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.
-
1
-
2
-
3
-
4
-
5
of 5 Next