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
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.
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.
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.
The thing is, I think most people interested in this kind of thing used to take a look at http://copter.ardupilot.com/, see the list on the left, and get reading. There's a huge, exhaustive library with few details left out. I spent two months on and off trying to read every page before I even purchased my IRIS, just to be sure I knew what I was getting in to. Then I probably read it all over again x2 while tuning, maintaining, and troubleshooting after I started flying. I also spent a lot of time lurking on this site, searching old posts, and picking up tips and tricks, including the fact that 9 out of 10 times there's a problem, it's user error of one kind or another. This is why it's flying better than ever after well over 100 flights. I mean, it's a flying robot with spinning blades, not an RC car. Please read up before you hurt someone, or make another scene for the media.
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.
Well the thing is that was the initial flight there. Also the drone hovered for a while about 15 seconds before flying away and it as just fling and flying at full speed i think it may have flown out naples the speed it was going.
Hi I had a similar problem. Sadly my drone flew away.
On the first attempt to fly the drone it operated somewhat normal but then suddenly took off into the air hovered for a while and stopped responding to the controller. After a few seconds it flew away very quickly. Any attempt to stop this action by the controller was off no use as the drone did not respond to the controller.Here is a video of piece of the first flight, https://www.youtube.com/watch?v=1tvQV5ePGxg
I tried resolving the matter with the company 3DR Robotics but I do not feel the matter was properly dealt with and they cannot properly explain why the Drone stopped responding to the controller.
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.
-
1
-
2
-
3
-
4
of 4 Next