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.

Views: 3720

Reply to This

Replies to This Discussion

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.

I think it has to be written in BOLD letters on the wiki page to get in and change an option for RTL failsafe to perform it as the current altitude. It also should be set like that by default.

as with not working/glitching baro and not working compass and not working GPS it tries to get itself to that preset altitude and, well, bye-bye drone.

I realize everyone has a different preference on how they setup failsafe. I prefer to not use it and rely on telemetry to tell me the status of my machine rather than have it lurch into the air while I'm flying in a tight space ie under trees, or a bridge, or heaven forbid (as my wife would say) inside the house. Temporary heavy load can send an autopilot into failsafe and I found it was usually at the most inconvenient time. I'm several years into no automatic failsafe and haven't had an issue (knock on wood) with DJI or 3DR products.

Is this the right file?

Attachments:

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.

I agree with you. But the Companies are very much to blame. only now that my drone flew away are they asking about calibration, sensors and warning signs etc. Like they expect me know know this information when all they provide with the drone is a booklet to get it off the ground. They market the product in a certain way but intact it is way more complicated than they are portraying it.

Agreed on that. Battery failsafe is a no no. My only exception is radio failsafe. You really need to understand and set that up in case you lose radio contact.
I agree 100%. I've seen a few pilots get lost with no video downlink turn off the controller to get the drone to come home. Me, I prefer a fail safe switch however my issue is when fly out of control range which on my Taranis is about 3200 ft out, not up.

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.

Can anyone read this log file?  Does it reveal what happened?

This has been discussed many times before, but RTL at current altitude is NOT a sensible default.  If you're flying at or below head height for whatever reason and it RTLs, your UAV then turns into a people lawnmower.  If you're flying anywhere with a hill, tree or house, you're far more likely to hit it.  The default action of RTL is to climb up out of harms way, then come back home, then land - in an emergency or uncommanded situation such as RTL usually is, it's the safer option.

However, it could do a better job of maybe of signalling RTL, like lots of beeps or a big red LED, that would probably help a lot of these situations as people would know what it's doing.  

It should be written in bold on the front of box that if your UAV climbs and stops responding, 99% of the time it's doing a failsafe action and probably doing a better job of flying than you :) (not meant to say anything against your flying skills of course)

From a technical standpoint a unit that is not yet ready or configured to fly in an automated mode should not attempt to execute an automated RTL performing any kind of maneuvers like getting to a preset altitude, etc. - that is why I say it should not be set out of the box for it to get to 25ft when an improperly configured battery level initiates RTL mode.

Keep in mind that a scope here is a discussion of a fly away scenario on the initial test flight, presuming a system is not even configured properly and a customer is unaware of requirements that should have been addressed, due to no 'deployment guide' that would list step by step what to do and how to do all that.  

Reply to Discussion

RSS

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service