It happened very fast
@msinger. I'm trying my best to remember the exact sequence of events on the screen. Communication is very important here so let me try this again to the best of my memory and I'll be the devil's advocate to myself and place doubt in every part of my memory of the events that occurred so we can look at this objectively... The log file paints a pretty accurate picture and I agree with the ascent and the direction it went after it ascended but using the log like the bible is something I don't agree with; especially due to the fact that the log doesn't record the Auth Zone and Auth Zone RTH which I think that DJI should look into recording those actions. If it was able to log the Auth Zone actions I wouldn't have to sit here and try and remember exactly the sequence and order of all the messages and pop-ups and automated Auth Zone RTH.
I'm also going to apologize for making my initial message so blameful of DJI. It was intended to be constructive criticism in their software programming. Software doesn't get better if people don't talk about it. DJI has not created perfect software and logic and it may never be perfect, in the same way that we are not perfect. There are thousands of little things that can go wrong that we cannot determine in the same way that forensic scientists cannot always decisively understand why something happened.
Instead of attacking me and one another, let's try to be scientific and work together? And yes I understand that likely there was magnetic interference, it is very possible. Let's get past that and pretend that we're software engineers and how we can better program the fail-safe procedures. Pretend that it was impossible to foresee the magnetic interference as if there was a giant magnet that was unavoidable or some other unexplainable event and see if we can improve upon the fail-safe... if I more carefully analyze the sequence of events I think we'll find that there are a lot of unknown variables and areas that could have been at fault that the log file nor myself could have recorded.
I think where the confusion lies, even for me, is when the aircraft became disconnected from the controller. The facts that I can 100% remember (including my assumptions about how the software is controlling the drone) are:
1) I turned on the aircraft and waited for green ok status and saw that the home point was accurate, close enough to where it started and was ok with that
- if you look at the satellite photo it was about 5-10 feet SE of the concrete in the grassy area for launch
2) I launched the aircraft and remember it hovering a few feet above and then i pushed it up high almost immediately to get it in position for the route and to not bother bystanders with the propeller noise
3) I then noticed the auth zone message. Not before takeoff but sometime either during the ascent or soon after. The auth zone message was coincided with a RTH message. It said something along the lines of not having authorization to fly in this area and that in the meantime the UAV will return to its home point until it's sorted out. I began trying to deal with the messages and obtaining the auth token. My assumption here is that the RTH command was sending the drone back to me so I continue dealing with the auth message thinking all is ok. This was my error for not checking visually. The spotter thought I was flying the drone in that direction on purpose, he later told me, so he didn't mention anything to me. The most likely thing that happened here is that the UAV was pushed in a direction it thought was home due to the compass error.
-
This part of the programming should be looked at (in my opinion). If the UAV detects a compass error, which it did early on it should not allow the UAV to automatically trigger an RTH on its own behalf. The pilot should have to confirm the RTH or trigger his or herself.
-
The GPS, assuming it has a decent signal, should hold the position of the UAV until the pilot decides whether to switch to ATTI or continue with GPS mode.
-
The log file apparently shows a weak GPS signal which probably triggered the ATTI mode. This action makes sense and I agree with it. The ATTI mode, in conjunction with the automated RTH for those few seconds, may have been the perfect storm for the fly away.
4) About 10-15 seconds later, maybe more, maybe less I see the aircraft moving away pretty quickly. It is already pretty far over the trees to the NE. I try to stop it but cannot. This could either have been because - the automated RTH or the ATTI mode and the aircraft being disconnected from the controller. I did not notice a disconnect status at this point but it is possible that the aircraft could have been disconnected due to interference or distance or some other technicality. I should have been more observant of the entire screen instead of paying so much attention to the Auth Zone messages and dealing with unlocking. When things happen this fast sometimes you get tunnel vision and take one thing at a time. I was definitely prioritizing the Auth Zone lock as I thought that was preventing me from controlling the drone.
5) The Auth Zone lock out remains on the screen. I assume that it is locking me because the aircraft continues to move away and I continue trying to obtain a token. I also assume that the aircraft is in a RTH routine when it is possible that it was in an ATTI drift with no connection from the controller. Maybe it was a little of both. We make the lock out assumption due to the message on the screen about the aircraft being sent home because of no authorization. We also assume this due to other users that report the same behavior in Auth Zones; that they are locked out and their UAV is grounded after takeoff. Perhaps poor cell signals are delaying people's Auth Zone groundings to after takeoff?
6) Token is received, auth zone message gone. I try to control the aircraft but it is definitely disconnected at this point as I observed the disconnect message. I attempted to recover the signal by disconnecting and reconnecting the cord. I have had success with doing that many times in the past with previous flights.
Things that are not certain:
1) That there was magnetic interference. It IS possible that the compass failed. Maybe unlikely but possible. How would we even know for sure?
2) The exact point that the craft disconnected from the controller. It had to have happened after ascent, but may have happened sooner than we thought. But it definitely did happen.
3) Why the software thought the UAV was in an Auth Zone when it was in a warning zone, but fairly close to the border of an Auth Zone. Possibly due to the weak GPS signal in the phone itself?
There are a few gray areas here and I think it is very possible that when the aircraft automatically switched into ATTI mode due to the compass error or weak GPS signal that I could not control it due to the aircraft being disconnected. Perhaps me pulling the cord out of the screen may have interrupted further recording of the log. The root cause of that disconnection could be the device I was using or some other reason, we cannot definitively say.
Regardless of all aforementioned the Authorization Zone programming needs to be re-evaluated in my opinion. Weak cell signals may mislead the software. Magnetic interference or weak GPS signals could be present in any number of situations that could misinform the software as to its proximity to Auth Zones or No Fly Zones.
1) How could the system report itself as ready to fly if it isn't sure of the quality of the GPS signal or the compass' reliability? Perhaps the compass didn't encounter an issue until after takeoff? Plausible?
2) Why would the system allow the Auth Zone RTH / Lockout after takeoff? Shouldn't the system make sure it knows where it is before making that decision? And if it isn't sure shouldn't it stay locked until it does know?
3) Perhaps the UAV was actually headed home, to the right place, but the weak GPS signal triggered ATTI and the Auth Zone messages acted as a distraction for just enough time that the pilot could not react in time before disconnection happened. Perhaps disconnection from the remote happened faster than normal due to radio interference in the area or due to the device itself (weak connection in the cable or hardware fault in the screen device).