Hi,
I am running AC3.1.5 on a 450 size quad and have had quite a good experience until now. Here is what happened.
I took the quad to my other apartment for the first time which is on the 3rd floor. Tried to arm it on the balcony but it would not arm as the GPS pre-Arm check was failing. Since I was not planning to use any GPS related features and would be flying indoors, I disabled the GPS pre-arm check in MP.
Copter Armed took off hovered for a few seconds and then al hell broke loose. The quad came directly towards me. moving the sticks had no effect on the quad and it was pretty close so I had no choice but to stick my hand out and stop it.One of the props hit my forehand and broke leaving me with a 6 inch gash in my forearm. Since I still had the TX in my other hand i killed the throttle but no luck because by then it was already in RTL (Failsafe kicked in)and heading to some incorrect location that it thought was HOME.
Looking at the logs both the GPS & the Geofence Failsafes kicked in together. It was a false Geofence failsafe because of the incorrect GPS location it registered and a completely incorrect home location too. Actual Home was about 30mts Off.
Logs are attached below however a few points I noted:
1. If I skipped the GPS Pre-Arm - Shouldn't all functionality GPS (especially fail safes) be disabled?
2. The GPS Failsafe kicked in first.My GPS failsafe is set to LAND. However the GeoFence Kicked in also and caused RTL failsafe to activate. Now if the GPS failsafe has kicked in and subsequently the GeoFence failsafe has kicked in then why did the GeoFence RTL take priority? The RTL would be useless without a GPS lock. In this case shouldnt the GPS Failsafe have overridden the GeoFence Failsafe? Also, I never noticed the LAND command that I have set for GPS failsafe. It directly went to RTL.
3. When RTL Kicked in, the Quad came straight at me. I have the RTL height set at 80mts. Shouldnt the quad have gone up before moving towards what it believed was home. Could this be cause I armed from the third floor.
So coming to my question - Is this the expected behaviour or is there a bug in there that needs fixing?
What I wanted to do was fly indoors without any GPS functionality. What is the checklist I should have followed to ensure the indoor flight was safe without interference from the GPS?
Attached are both the telemetry & dataflash logs. Please note that I take off only towards the end of the logs. at about the 75-80% progress of the logs. There are a couple of ARMS' DISARMS but please look at the last ARM which is when I actually take-off.
Any help - Guidance would be grateful. If you'll wanna see the gash in my hand let me know.. Ill post a few pics. :-)
Replies
Is there solid solution for avoiding this Fence breach-glitch-crash? Disabling Fence is enough?
I did some research of my crash which occurred in same day than Arshish accident and it looks like I had exactly same problem. My copter was just set to land. Landing failed totally.
There is one copter waiting maiden flight and this problem has caused crash once or perhaps twice for me already.
Keeping safety first is definitely the objective but your suggestion that autonomous flight should be banned is something that no one will agree with.
@Arshish - Bad news. Autonomous flight is already illegal and banned in some countries, such as Australia. Well, not entirely but it does require permission from CASA. The rules are quite clear here. Must be LOS and must be in total control of the operator at all times. I'm siding with the 'autonomous flight is not safe' camp. As far as I can see there's little to no use for it in recreational hobby use of UAVs.
Hi Thomas, man on the street here. I'm having a blast with my autonomous flight modes. The combination of cost, reliability, payload capacity, and autonomous features are pretty much a dream come true, and has allowed me to add high-def remote sensing and rapid 3D modelling to my business menu (I work in GIS). What I'm saying is, I'm tremendously grateful for the shoulders of the giants I get to stand on in terms of hardware and software, and I'm really, really glad you're not in charge :-)
Actually, Justin, I'm not sure who Thomas is. The website, thomasbutlertechonology.com, does not exist and when I Google it there is no reference to such a company. I don't think you have to worry about him being in charge. LOL
I don't agree that these things are a bad idea and sending copter pilots to jail is a GROSS overreaction. I do, however, believe that this hobby/industry will be regulated sooner than later. For commercial pilots in Canada we are well ahead of the curve with each flight requiring an SFOC (special flight operation certificate).
I do think it is time that the arducopter developers get really serious about building in more safety controls. There is some great work being done on a failure algorithm to allow quads to fly even with the loss of a motor. GPS and compass data can be analyzed for anomalies and motors shut down. A proper parachute routine should be implemented which allows for parachute launch delay to eject while somewhat vertical. I'm sure there are more ideas.
I'm pulling for Arducoper and if it were to lead the way on this it would be a big marketing plus and perhaps save its eventual demise from legal battles.
I would be great if someone who knows this site better could start a developers thread for safety implementation suggestions.
I feel you man. I had something similar happen to me. When I upgraded my Pixhawk arducopter firmware my RC3_REV parameter *"~magically~"* changed. The quad was entering ESC calibration mode at startup and I had no idea.
blue, red, green, rapid flashing. NOT in the manual.
It took off in front of my face. Luckily I caught it before it hit me in the face/neck. Unfortunately, the path my hands took to grab the center of the quad was in line of the propellers. 38 stitches total. 40% through my right pinky.
More info... And photos... Here
It's funny. I contacted 3DR about a month ago to let them know. "I was injured, your manual doesn't specify what this LED color code represents and it's dangerous... Please add it to your manual so the same thing doesn't happen to anyone else".
They haven't done anything about it.
I hope you have recovered now... That looked real real bad. The documentation does need to improve.
And to be honest.. That was the objective of posting this. I love this hobby and th guys at 3dr have done an amazing job with the APM and pixhawk. Am I gonna stop flying.. Heck No!! I'm already back on the air :)
However the documentation really needs to cover a lot more on safey
That's the spirit!
I was back in the air while I still had stitches in my hands. (I took maybe a 3 day break)
If I had known that red, blue, green rapid flashing meant ESC calibration mode, this wouldn't have happened.
I noticed the Iris's status LED while watching this video (at 1:17) only by coincidence did I find out what the issue was.
Checklists will only get you so far. There WILL be bugs or edge cases that aren't properly covered. If you are trying to fly autonomously with a PDOP of 7 there is no point in even attempting it! The software should simply realize this is an inappropriate request and something clearly went wrong, and thus it should cut engines.
I've said it before and I'll say it again: IMO the safest response for the software when there is any doubt as to whether it is doing the right thing is to simply turn off the motors. Sure, you might lose an aircraft but that is no big deal compared to launching an autonomous chainsaw at people with no way to abort. There should never be a condition where the thing is flying at you and you cannot stop it! This is the approach we take at Tau Labs and so far it has served us well.
-
1
-
2
-
3
-
4
-
5
of 5 Next