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 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.)
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.
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?
First of all every barometric sensor that has holes to let sunlight pass (that directly hits the silicon) is affected severely by sunlight. Some claim that it is the "pressure of the light" but I did the math from wiki and found that this pressure is at least one magnitude smaller than the sensor noise/sensitivity - that's probably why barosensors are not used to measure the radiation/light pressure - so much for that. But the main problem is: User is taken out of control by the flightcontrol. And that seems to be a general problem of the softwareconcept. I wrote earlier some unheard infos how to prevent that. Even if the Baro or Mag or GPS goes berserk and just the gyro + RC contact is still working the user has to have the possibility to get back control by a flip of a switch (even if that is a killswitch). The platform will be always high risk (Russian Roulette with 6 bullets) for the 2km(?) surrounding population until that is ensured - otherwise fly in some desert.
Hang on guys, I need to get my popcorn..............
All I can add, my standard 3DR quad with APM 2.5 and latest code flies Auto missions like it is on rails.
So, some builds do seem to work :-)
Looks like Rob's pretty much got this fully analysed. I've had a look but it all backs up what Rob's said.
Attached is a graph of the inertial nav alt estimate and the barometer pressure. There's a very large pressure change (blue line) which pulls the barometer altitude down and the inertial nav estimate gets pulled down with it. So it thinks it's 200m below it's actual altitude. It then recovers and drags inertial nav with it. It's unclear if the inertial nav estimate then overshoots the baro alt or not (it might have). In any case this triggers the altitude fence and the copter goes into RTL. I think the pilot momentarily gets it back into alt hold but the altitude is still going up very fast (because of the baro glitches) and it breaches the fence again and goes into LAND mode and then comes down.
On the software side there are two things we should do:
- barometer reading sanity checking. similar to the recently added GPS glitch protection. it's on the to-do list.
- after a fence breach, if the pilot re-takes control (using hte flight mode switch) give him/her at least 10seconds to control the copter. The current fence breach code isn't time limited. Instead it gives the pilot 20meters so if the copter continues to move more than that beyond the fence, the autopilot will retake control again. The problem is that if the copter is moving quickly (or if the sensors are going crazy like this time) then that 20m my be passed in a very short period of time. This item is also on the to-do list.
To bring something positive out of this, is there an option to have some form of barometer failsafe introduced into the code? Its unlikely someone will be flying at -190 unless they have the UAV inverted and are tunnelling for oil ;-)
I have always run my APMs in their cases with foam protecting the barometer and each of the UAVs have a dome that is custom made from dark smoked acrylic. Some could say its going overboard, but its all about negating risk (and it looks cool).
I am about to take my commercial license in the UK and as part of the process you have to submit a "risk assessment" document. These processes do make you appreciative to what "could" go wrong and make you think more about your use, but its equally about balance and doing everything you can to negate or reduce risk.
This APM and PixHawk technology goes through rigorous testing by some very talented engineers. The only people that are going to spoil it for the masses is the users. Its like handing over a loaded gun, we have to treat it with the utmost respect. A gun will only go bang if someone does something wrong and pulls the trigger, you can't blame the gun for that !
Is there a dataflash log somewhere? I see the tlog but no dataflash...that would be helpful.
http://diydrones.com/forum/topics/kill-switch-in-auto-mode
Don't know but that Arducopter has a killswitch now? You can not have a machine that is supposed to be *somehow* autonom. without that option - just my opinion. Retired my apm for similar reasons.
What about changing/extending the has landed/isn't flying condition? If the total throttle is below a specified minimal fly throttle (maybe esc minimalvalue + 5%) for a certain amount of time (like 5 seconds) disarm - no matter what.
Maybe users should be advised in the wiki to throw a blanket over the still powered copter on the ground before approaching it.
So here's what I've got so far. Trying to line up the events with the Tlog playback. You definitely armed it, and lifted off in Stab mode, and it rotated a little bit. So if by my theory, you had landed with the sun on the baro, disarmed/rearmed, it would have saved a false off-set. Then you took off, sun came off, and the false off-set pushed the altitude way up, at which point it thought it had a fence breach. It seems to me that it actually landed WHILE IN RTL, and you didn't even know it. You dropped the throttle and thought you landed it. Unfortunate co-incidence. It was sitting on the ground with the motors running lightly right?
What you didn't realize was it was actually trying to RTL. I actually can't tell what happened after that. It's clear that it decided to throttle up and take off. I have no idea why this would have happened, as should have thought it was in the right location. Your RTL Alt is 2500, which I think is 25m, so that's fine. Why wasn't it satisfied with the landing? It might be because it thought it was too high still.
It kinda looks like it danced on the ground a couple times, rotated, sunlight maybe just coming in and out... Just a guess. But look, every time the yaw changes, the Alt makes a big change.
I know that having all your hard work destroyed, by something that seems out of your control is very upsetting. But the only benefit that comes out of it now is to look at the situation, figure out if you did something wrong so you can fix that. Or perhaps generate "lessons learned" for others. Or, it still could be a bug, or just something we could error check better. I can't make much more out of this, and we'll have to see if Randy or somebody else comes up with something.
-
1
-
2
-
3
-
4
-
5
of 5 Next