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
Hi Paul, you raise some interesting points and questions. But I think your advice to people that:
"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."
is potentially rather dangerous advice, particularly for newbies. While rather crude and not always totally accurate, altitude judged by barometric pressure is probably infinitely more reliable than either compass or GPS. One thing I've learnt about APM autopilot is that most of the default settings have been discussed, tried and tested over time and are usually by now pretty good.
I would guess if you put this particular one to the developers, they would say that any unit that is not configured to fly shouldn't be flown at all, rather than compromising it with non-standard settings to try and mitigate errors, and the reason the first thing it does in a safety/emergency scenario is to climb to a higher altitude is for safety, to get it out of the way of people or buildings. Regardless of the situation, inexperience or otherwise, the last thing a craft with lots of fast, sharp, spinning things should do is suddenly travel sideways without human control, potentially towards other humans.
I usually don't jump in on conversation like this but your suggestion is way off base. The option to perform RTL with a specific behavior is %100 dependent on how you operate. What you believe to the correct behavior may result in hitting an obstacle instead of climbing over it. More often than not people are not flying under objects but instead next to them.
There is no way to come up with default responses that will work for everyone. Instead more ownership needs to be placed on the user. These on complex systems. People using them need to understand how they work. No other place in aviation do people just pick up a plane and just try it out. That is why there are training requirements, SOPs, and checklists to ensure safety. It has always aggravated me how this tech is pitched to consumers as something they can just take out of box and go fly. That attitude is reckless and will bring more and more negative attention to the industry.
This is really great advice.
Chuck have you tried asking on the ardupilot forums? There's a dedicated forum where really experienced developers/testers help out reading logs of crashes:
http://ardupilot.com/forum/viewforum.php?f=80&sid=11a221bcd50e1...
I think the blame falls on both sides but more responsibility should be taken by the companies, in this case 3DR, to emphasize the complexity of these machines and provide a path to learn the ins and outs of how to operate and understand them. I have been apart of creating documents from flight operation manuals (the generic dos and don'ts of flying a vehicle) to user manuals for different vehicles and autopilots for the military and commercial market. None of which are small little booklets with "tips" and "suggestions" sprinkled with super high level explanations of features. They combine to hundreds of pages. Sure that is not appealing from a customer standpoint but it is naive and careless to think the consumer can safely operate these systems with very little knowledge and market it in that sense. The technology just isn't there yet, or may never be, to just open a box, glance at a pamphlet, and fly. Hell you can't just jump in a car for the first time and start driving, you have to prove you're capable of driving safely.
Sure this is only a hobby for many but this hobby has can have huge implications when things go wrong.
developers know better but during my very short range careful tests (so I was able to jump in and knock drone down) I concluded this 'fly away' scenario happens when you initiate RTL mode in combination with GPS glitch occurring or severe interference into GPS channel from other factors then then this thing goes bananas and flies erratically in the random direction unless you very fast intercept it and get it out of RTL mode.
I also understood that according to default rules - it there is any issue with GPS then RTL mode should simply do 'land' without trying to fly away. From my observation it is not what sometimes happens. Why - I do not know. By now I have learned enough of this platform not to do such things and as I am careful enough I did not have a single incident with APM doing something I would not expect it to do.
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.
-
1
-
2
-
3
-
4
of 4 Next