I am new to ardupilot and running a 3DR hex kit, mostly stock with xBee telemetry ,5000mah 4S 50C batteries, and Spektrum DX7 controller. Here are some stats to whet your appetite for my post:
Number of test flights:2
Number of successful test flights:0
Number of broken props:12
Trips to emergency room: 1
Successful uses of any flight mode but stabilize:0
Number of times I have had to kick a quad out of the air doing “rtl” towards my co-pilot at 1m from the ground: 1
I’m going to say right off the bat that most of these errors likely occurred between the copter and the controls (i.e me), however the copter flies well in stabilize mode, and seems to be well tuned there.
My configuration files are attached, but the major changes were:
-Geo-bound and max alt. failsafes: 20m radius, 30m height, failsafe to RTL
-Comm error and low battery, set to RTL. Comm error was set by “binding” my DX7 with a PWM of 1050 on the throttle, which is 200 below my lowest throttle setting. So, when the controller is turned off (or comm disrupted) throttle input falls to the bound value, and the failsafe is engaged.
The copter has the following issues:
In stabilize mode, pitch and roll are reversed. This I feel is a fairly straightforward error, but my mappings seem to be reversed
In loiter and Alt Hold, the copter will not stay aloft. In alt hold (engaged at~3m), the throttle will oscillate, and the copter will oscillate, but slowly come to land. Loiter will cut throttle slightly and settle in to land.
The copter will take off sporadically. We are calling this “killer”mode. The we flew the copter to the geo-bound, it was doing an RTL and coming back towards us. I switched to alt hold, with zero throttle, and the copter fell out of the sky (definitely my fault..i Think). We went to the copter after it crashed, assuming that the system was disarmed (also my fault). Approximately 1 minute after the crash, the copter took off into one of us, causing a serious hand injury. There was no external input on any PWM channel, and it appears the system thought it was in RTL mode. But, would ardupilot take off in RTL mode if the props weren’t already spinning?
The copter will fly directly at us at 1m altitude. I had set up the geo bound on the mission planner software, and confirmed that the copter was shown to be at the centre of the 20m geo bound. I changed my channel mappings to stabilize->RTL->loiter in order to test my RTL functionality. I started to take off in stabilize mode, and when we reached ~1m altitude the copter pitched on its side and came directly at us, again with no external pwm input. Looking at the logs, I dropped throttle as soon as the copter pitched (ch3 PWM went to low), but the autopilot throttle continued to increase and oscillate, and the flight mode went to “unkown”. Also, at the same time as the pitch, the satellites dropped from 10 to 6, and the GPS eph (position accuracy) went from 175->375. Looking on mission planner, the location of the copter was wrong, and it thinks it was about 200m away from the home position. So, my assumption is that the GPS accuracy went down, it thought it was well outside of the geo bound, and tried to RTL back to home (even though it was at home already). However, I thought that RTL had to achieve a certain altitude before moving, and so am confused why it did RTL at this altitude. There is the minimum altitude setting, which I will now set, however I have heard that there are some issues with this setting (such as spontaneous takeoffs, which I don’t want to encourage, as above) I’ve included the telemetry from this test flight. The killer mode happened on the last flight.
Can I set a “kill all” failsafe? I can see the reason to set failsafes to RTL in order to try to preserve the copter, however I woudl like to have a failsafe that I can send which will disable everything, in those cases that the things that the copter is flying towards (ie. me) are more important than the copter itself. With the way my failsafes are set at the moment, turning off the controller would keep the copter in RTL.
So, overall, I would really appreciate help in getting this system going safely. At the moment I am pretty wary about flying my aerial lawn mower again until I have the safety settings done properly. It is not acceptable for the copter to take off, or fly quickly in arbitrary directions. these things are dangerous.
Thanks!
Replies
I am closing this discussion out. I believe that everyone has had sufficient time to make their views be know concerning the subject of this discussion. Let's move on and plan to improve the future for all of us involved in the hobby UAS community.
TCIII Admin
"Overall, I feel that I have done quite a bit of research on this platform, but haven't found a full, clear set of instructions for total newbs on this stuff............."
D Savant, It seems you have gone through the wiki completely and know what & where it is wrong or missing IMPORTANT points. Why don't you write those important things and pass it over to be added and wiki will be perfect and every dummy like me will be happy. Doing it correct is important than saying it is what I believe in. Safety first.
Cheers
Morli
Hi David, would have sent this to you via a PM but you have not accepted my friend request so this will be my last post on the matter. The keyword here is the process; it seems there was some sort of trial and judgment rendered in absentia. To be honest, in the end, it is probably better that way because I generally don`t like the direction this site has taken recently. Posts mysteriously disappear on this forum when they are judged to be bad for business. As much as I respect Chris for what he has built here over the years, I resent the fact that he is going around making speeches about APM2.5 being crash proof and that it has features like geofencing that will prevent it from leaving those confines while we all know this is not true.
As my esteemed and well informed friend Drone Savant mentioned, this is reckless behavior. The code is unfinished, very unstable and as we all know, potentially even dangerous. And another thing we all know, APM2.5 is destined to fade into oblivion very shortly so in the end, this product will have never been finished in its lifespan. The next APM will come along and the process will be repeated again. I think 3DR should concentrate on safety first. A lot of time is spent in fancy autopilot features but the basics have been ignored. There is no 100% bulletproof failsafe system that works, it was a gray area when the product was launched and still remains a gray area to this day. Other flight controllers out there are facing the same issue, some have successfully dealt with the problem, others not. I have never been a big DJI Naza fan for many reasons, the price, the locked code etc... but to this day, it is the only flight controller that has never let me down or done any unpredictable stuff. It is very limited in features but the few it has WORK.
I have been a member of this site since it started and I have tested out pretty much every rendition of ArduPilot there ever was and can report that none of them where ever finished. At this point, I have given up all hope of ever seeing a completed product come out of 3DR so I have decided to move on to other flight controllers with more promising futures, sold by people who are not out just to make a buck but actually want to make something that will work, be safe and accessible.
The price of the current 3DR products is also unjustified, it is clear the markups are high. With a manufacturing facility in Tijuana, they could drop them a bit but it does not seem to be a concern, they figure people will still buy their stuff there because of customer service. My customer service experiences with 3DR have been less than perfect. 2 weeks to get a response for an email is not right.
I am basically done with 3DR products and the never ending testing, trial and error with their AP products. I will no longer be a guinea pig for their unfinished (and never to be finished) products.
I am now working on the following boards on different quad frames:
-PX4: One successful flight with the basic code, excellent stabilization. Will know more soon since the weather is clearing up and I will be able to do further testing.
-Quanton Control: Just received it and bench tested everything, looks solid and reliable so far. Have not flown yet but will soon. It does not hand for no apparent reason and has incredible vibration tolerance.
-OpenPilot CC3D: Untested yet but in the works.
-DJI Naza M: Well over 20 flights, not one glitch, the only mishap was when I was too eager to fly and did not wait for proper GPS lock before take off, as a result, when I engaged RTL, it flew in some random direction and headed for a tree. I got out of RTL mode and recovered control and prevented complete destruction. A non event really.
My testing of the APM2.5 remained at the bench level only. I never actually flew with it because of the unpredictable behaviour observed on the bench. A friend with whom I fly often has one and has broken so much hardware trying to get it to do the most basic things I just never had enough guts to test it on one of my frames. I know there are people out there who have had reasonable success with it but pretty much all of them broke stuff to get to that level. It seems to me the development program of the APM is not structured. If I was in charge, I would do it in the following order:
-Code Failsafe until it is bullet proof
-Code the stabilization portion until it is good and failsafe still works
-Code navigation, flight modes etc…. Verify failsafe again.
-Do not release any new code until you have verified that failsafe works in every possible scenario.
Instead, we have different people coding different modules and no actual verification of the interactions when they are combined into a release. 3DR basically uses its members to do the testing and patch and fix things here and there in a fashion that doesn’t seem to be very structured.
And also, update your bloody wiki. We don`t have the time or luxury to sit down and read through a huge thread to find that one answer we need. This is ridiculous.
Like I said, I will keep an eye on developments here, I will never buy a 3DR AP again that much is for sure. There are some cool people on this site, just like there are some that need to get a life. As far as the Admins are concerned, I do not know Josh but I have been approached by Thomas about my moderating and I got the feeling I was being watched, it was clear from that day he had me in his sights. The way he did this betrays what really goes on behind the curtain here and even though it was Chris who made me a moderator, I am pretty sure Thomas had something to do with that privilege being taken away from me without any form of warning or discussion. Again, at this point, I no longer care since I have lost respect for the way things are administered around here. The timing is actually good as I was considering sending Chris a request to remove me as a moderator. It turns out Thomas or whoever else made that decision and basically lifted the rug from under my feet. I have also noted that some of the people that were the key to 3DR taking off like it did, people behind the very stabilization code that they use have been carefully and conveniently phased out of the spotlight.
We have switched from a community based site to a business oriented site, with all the ugly stuff such a switch in direction brings. Off to TauLabs, PX4 (non apm code) and other less market oriented ventures.
Best regards,
Had an uncontrolable throttle issue last night. Armed in stab, flipped to acro and applied light throttle for liftoff. Throttle went balls-out and would not respond to throttle stick. Flipped into stab and still no response. Finally, in stab, held disarm and came crashing down to Earth. APM2.5, 2.9.1, FW450. Destroyed.
Hi All,
Hoping these comments will help make the Arducopter and 3DRobitics a better experience for newbie's coming into this.
I like Rob am a new 3DRobotics Hexa C owner. I have been flying a DJI Phantom for the past 3 months with great results and been a happy DJI customer.
I wanted to take my flying to the next level, so I researched the internet and came across the "ready to fly" hexa c. I purchased all the options (DX8 radio, telem/radio, sonar, hexa c, with spare parts).
I have had my Hexa C for 4 weeks now, and I have had 4 crashes.
My issues are:
1. the throttle is SUPER sensitive from day one. As soon as the props start spinning, its like I have the entire throttle range with in the first two notches on the stick. And yes I did the calibration before flying. This was my first crash.. as the machine shot up 3-4 meters fast.. I quickly chopped the throttle.. and came down hard and brook two legs.
2. The alt mode doesn't work.. when I put the craft into ALT mode.. it immediately goes full throttle and shoots to the stars. Pulling back too hard on the throttle seems to have stop the props in the air.. and it came crashing down.
3. I did the same mistake as many.. I landed my hexac after a good flight in stable mode.. finished my juice.. turned off my radio (my mistake).. and the hexac shot across my deck into the wall.. and broke two more props and a motor.
Although I fully understand the main controller of this UAV is an open source and community project, I think it really should be better marketed so it is very clear that there are bugs in the software and new users/customers should be VERY careful.
Secondly, what I really liked about DJI with my Phantom, was that they made very good efforts to have excellent and simple video instructions. I have been in IT for 30+ years, and I know video/audio is a much better education tool than confusing and not easy to follow text/wifi.
I was a bit shocked when I received my HexaC that it referenced a web url for the manual.. I thought I was getting ready to print a PDF. But the wiki/forums is VERY confusing for a newbie...
I have since, purchased a F550/Nasa to fly... as I really feel super intimidated by the HexaC...
Really hoping to see improvements in the documentation/manual and eagrly waiting for some good 'how to videos'.
Really hope this helps by providing customer feedback.
Thank you Rob for you post and all for assistance us newbies.
Kind regards,
Chris
I ended up pinning it to the ground to stop the motors so I could safely unplug the battery.
I broke two props. I replaced them all and tested it again and now it works as normal.
I agree, this thing is a bit scary.
I was flying in stabilize mode.
I'm thinking I might add an on/off toggle switch to it. Mounted where I can easily access it from any orientation without risking my arm and hands.
FYI, I'm new to the multi copter drone stuff. I did all the calibrations as instructed. I could have overlooked something. I only have two modes set up. Stabilize and loiter. I've been flying RC aircraft since I was a kid. I'm 51 now.
In response to comments made about this product having issues, I have seen comments about the Naza product doing similar things. I don't think it is specific to the APM.
Hello everyone,
First off, thank you for the great response to this, it is apparent that there is a very vibrant community behind this project, and I appreciate the time that you have all taken to respond to this. As an update, I was able to repair the copter and take it out, I did a lot of stabilize flying (simple and non), PID tuning on alt hold, testing of loiter, and finished it all of with a simple RTL landing that went very well. I think that both of my issues came from the use of the GeoFence, which I have now disabled. This can cause erratic behavior if the GPS looses accuracy, and I think in both cases the copter thought it was outside of the geofence and so started to take matters into its own hands (killer robot style). I see that the wiki has been updated with some warnings since I last visited it for initial setup, so this is good.
Overall, I feel that I have done quite a bit of research on this platform, but haven't found a full, clear set of instructions for total newbs on this stuff. Especially important would be big bold letters talking about proper arm/disarm procedures, and startup precautions. If these resources do exist, could someone point me in the direction of this (other than the wiki)? If there is somewhere, I would be happy to start adding some stuff in from a "newbs eye veiw" on this (sometimes its hard to remember what you didn't know at the beginning), as I think that this is definately still lacking.
If you're flying a drone, or just a little R/C model, you should always do you best to put yourself in the best physical location. You could have most "fail proof" flight controller in the world, but if an ESC dies, or a prop dies, a quad can go flying in any direction quick.
How close are you standing to your copter? If it's flying or going to be flying, try to stay at least 6 meters away at all times, if not more.
Rob, I'm glad it wasn't worse. Richard and Mick have it right, aside from whatever setup issues there might be. Do one thing at a time, until it works correctly and you are thoroughly comfortable, and only then move on to the next. Flying in plain stabilize should be first, meaning you can control the aircraft in any orientation. If you have little prior RC experience that can take a while, but it can and should be fun and in itself rewarding. Next is altitude hold, including throttle stick management while entering and leaving, and during, that mode. Then loiter. When all of that is working and comfortable you can start messing around with RTL. And so on. Sooner or later just about any RC aircraft will do something unexpected, for internal or external reasons. If you have basic manual flying skills and the confidence that comes with them such events are often barely noticeable or will get a "nice save" comment from a fellow pilot. If you haven't got those skills, the outcome is always a crap shoot.
Also, a specific safety tip: Any crashed electric RC aircraft should be assumed to be armed and dangerous. Approaching the craft, if it looks flight-worthy, is best done with a jacket or blanket in hand to toss at it if it gets frisky before you reach it. The immediate desired action is to disconnect the main battery. On multicopters this can mean reaching in among a bunch of props. The bad news is that multicopter props can go from zero to a gazillion RPM faster than you can blink. The good news is that they have negligible torque at startup. So, you want your hands/arms either firmly touching the props or well within their arc, so that should they start they can't actually spin. Do this in a way that also holds the multicopter down, because if it starts up you don't want the props on the other side flipping it into your face. Also, once you're committed you don't want to pull back should it all of a sudden fire up; just follow through with the disconnect. Make this your standard everyday method for disconnecting the mains and it will be automatic when needed. An alternative is to carry trauma dressings in your tool kit, as anyone who has seen prop injuries will tell you that band-aids will not be sufficient.
Rob,
Sorry to hear about your troubles.
Just had a quick look at your logs and a few things I saw:
-
1
-
2
of 2 Next