A 3DR developer recently tuned my Pixhawk, it flies great, but when he did he also setup my battery failsafe. Shortly afterwards I was hovering approximately 5 meters away and about 6 feet when the Pixhawk started beeping continuously and started to climb. Stick inputs had no effect until I switched from Stabilize to Loiter then I was able to gain control for a couple of seconds but then it started beeping again and started to climb so I switched it to AltHold lowered the throttle and let it drop giving it throttle to arrest the decent just before hitting the ground.
The battery was still about 15.2 volts but I thought it might have been related to the battery failsafe since it was set to RTL maybe it was trying to RTL So I disabled the RTL in battery failsafe and it flew fine with no incidence. I flew it today and it did the same thing, this time when it started beeping I immediately dropped the throttle and got it on the ground but when it touched down the motor increased and it would not immediately disarm.
Here's the video of the second crash landing, you can here the beeping start about 25 seconds into the video:
https://www.youtube.com/watch?v=ccJaJa3IyYY&feature=youtu.be
The battery was at 15.45 volts and the battery failsafe is disabled. It also had a flashing yellow LED. How can I trouble shoot this to determine the cause of this? How do you download the logs? I'd share what firmware I'm using but I don't even know how to do that?
Any help would e greatly appreciated.
Replies
Is it possible a GPS error to make it believe it's somewhere else, and hence speed up to RTL on what it thinks is home?
Isn't switching back to stabilize (or any other non-gps mode) supposed to grant back control to the radio TX?
I guess i'm just looking for a fool proof way to abort imediatelly any stupid action it tries to do.
The strange this is it was in the std mode. It completely refused to respond to the controller. 3dr team is horrible they offered 15% for a new drone. WHAT!!! The drone malfunctioned and flew away... They are claiming
"I have explained the situation multiple times but I will summarized what we observed and why we decided this was not a hardware malfunction.
First we noticed the vehicle is being flown low on the ground, at some points in the first video you sent you can see it hit the ground multiple times. This causes the vehicle to become uncalibrated and therefore makes the vehicle try to overcompensate. You can even see it hit the floor on the second video before take off.
Next thing I noticed, is you are not taking off properly, you are (as you mentioned) gently applying throttle. This is not the proper way to take off, you must apply more than 50% throttle for a successful take-off. By gently applying throttle you are causing many vibrations on the vehicle (since it is so low on the ground and you are spinning the props). You can actually see this on the first video.
Also you are flying in a residential area which we strictly advise not to do. You are supposed to fly in an open field with lots of land in case of a hardware failure or pilot error. Not only were you flying in a residential area, but you were also flying around people endangering them. This is not the responsibility we ask from our customers. To top it off you were flying in the dark, not even we fly in the dark and we are experienced flyers! We have flown in the night before and are easily able to lose orientation and track of the vehicle even with the LEDs (it has happened to us).
Lastly, in the first video you can see how the vehicle responds to the inputs you are giving. You mention that you did not intend for the vehicle to yaw, yet you can clearly see the vehicle yawing. Next we observed the radio is signaling something is wrong, whether is it bad connection or low battery, it is signaling it should not be flown. Yet you continue to use and even attempted to fly the vehicle. You ignored this warning and continued."
How was i supposed to know the warning signs. They are very unscrupulous.
Well, I work for professional services in a major telecommunication company, so I can see both points of view here, from a business user side and from a developer side as it kinda fits my shoes and what I do on a daily basis.
Major issue I see here is a lack of a good know-how best practices document that would explain step by step safe procedures and methods to tune and adjust craft before initial startup. Guys who respond to you and draw criticism as 'horrible' are actually saying all the good and correct things and I do understand it _now_ of what they say and why. take me 2 months ago when I started testing this new to me APM build - what all that would mean to me? Absolutely 0. What we kinda need here is a basic set of a step by step instructions wrote for a space alien, so people would understand precisely what to do and in what order.
What to avoid, what flying mode to set in what order, how to test failsafe with no props _before_ initial flight, etc., etc., etc.
All that being a pro-bono community project I understand 100% frustration and responses like 'you want it - step in and help us get it done', but, again, I would love to, and probably will, but not right now.
What you say - 'how was I supposed to know the warning signs' is the key here. it is indeed the key.
I flew planes before so I knew how to be careful, and still I did have damage caused by a craft out of control, and I think I had it doing same that yours did, but, how to analyze it - it beats me.
My uneducated guess is that by default set of settings in the APM/PX4 after an initial flash when unit activates RTL failsafe for whatever reason, combined with multiple 'glitch' conditions with GPS not working, compass not calibrated, ESCs not calibrated, who knows what else, and unbalanced props causing wild vibration above any reasonable limit - a whole thing gets out of control and it results in the fly away without responding to TX command.
Plus I also suspect there are other issues that still cause lack of stability if you use 3.2.1 build instead of 3.2. It exists and also, probably, adds fuel to the fire.
So from a project management perspective team is in need of a decent doc.s writer here, to put together a step by step manual of how to use it. As I can say 100% - firmware is good and craft, when tuned right, is an absolute joy to use. What it takes to get to that stage is an another story, of course.
Actually, there is quite some information available at this location, which should help preventing flyaways like these...
http://copter.ardupilot.com/wiki
But I do understand it is a lot of information to grasph....
Thanks everyone for the feedback. Got busy yesterday and today so I have not had a chance to follow anyone's recommendations. I will post the logs as soon as I get the chance.
I appreciate all of your quick responses to help me sort this out.
The sound we hear on your video is the Pixhawk beeping for low battery. If your battery was charged maybe your battery failsafe voltage level in volts was set too high.
There is an option you can set for RTL function to execute RTL at the _current_ altitude height and I do highly suggest to use that always.
I had an accident caused just by leaving this option unattended and pressing once RTL switch instead of LAND switch that caused craft to propel up in a similar manner hiting wires instead of going down as it was intended.
Whole bunch of worms can happen if your GPS sensor has interference issues with other components and it starts acting up in the air, it took me 2 weeks to figure out causes and rewire whole thing to move now most power wires well away and filter off most sources of interferences to avoid having this 'gps glitch' horror right while in the air and locked into 11 sats just fine.
Ok, the title is a little mis-leading, its not a flyaway. But that might be flyaway prevention that landed it.
I'll stick my neck out and suggest you have EKF turned on and that was an EKF failsafe.
Sorry for the misleading title. The first time this happened it started climbing on its own and I had no control but after switching flight modes I was able to regain control and land. Although in both cases once the MR touched down the motors sped up causing it to tip over and it took a bit for it to disarm.
In the video I posted with this thread I planted it as soon as I heard the buzzer. I suspect your right, this is probably a setting somewhere. I'll post my logs after I've had a chance to follow Chris's advice.
Please post your logs. If you were connected via a GCS, they're automatically saved on whatever device you were using (phone/PC/Mac). If not, they're stored on the SD card and you can pull them off with your USB cable using Mission Planner or APMPlanner.
All this is in the manual, BTW.
-
1
-
2
-
3
-
4
of 4 Next