P4 Advanced Authorization Zone Mid Flight & Compass Error

[journeyfarm]

You are correct in everything you say but your logic is off. It's one dimensional. The messages are very important to what happened and the automated RTH is also very important. As is the lockout. You're disregarding important information and that is where you and I are different. You can keep flying DJI, and I'll stay far away.

 

[Meta4]

You can keep flying DJI, and I'll stay far away.

And I'll keep flying safely by not unnecessarily calibrating my compass in a magnetically dirty area and not launching from close to a lot of steel.

 

[WWK888]

Meta4...I appreciate your patience and expertise in trying to explain this situation.

 

[microchips]

Sorry but whatever happened it's a classic case for a RF V16 or similar tracking devise, I never fly any of my drones without one..again I sympathize with your loss.

 

[eeire54]

Yes, probably me!

Ahah... and yes that is my issue with the new software. Of course it doesn't show it. I know for a fact that "Authorization Zone" messages popped up and that it forced a RTH on the aircraft. I did not have the choice to cancel it due to the "Authorization Zone" message blocking me. At least not to my knowledge. Maybe there was a backdoor somewhere to cancel the RTH but in the moment of trying to solve the Authorization Zone issue it appeared to me that I had to to obtain a code before doing anything else and that the aircraft was "taken care of" int eh meantime. Unfortunately, I could obviously see it was not being "taken care of" by DJI software.

Obviously the RTH procedure wasn't captured in the log and that's DJI's oversight. They simply didn't record the Auth Zone actions. I can prove the Authorization Message with the token's I received by text message. The software logic simply is not programmed correctly to deal with this scenario and in general it should no trigger any RTH action if there's any indication of satellite or compass issues. If you don't know where you're going, why go?

The entire issue here is the lock out caused by the Auth Zone and the automated RTH. Locking a pilot out of manual control, no matter the circumstance, is a no no. You can warn a pilot but a human mind is always needed in the process... the computer should only assist and advise.

I know from experience when a piece of equipment is acting up often the sensors recording the event have also taken a hike,.

That satellite photo is not what it looked like the day of. Those trucks we're not there. The UAV was launched from the grassy area just next to the concrete. I am aware of the issues caused by launching next to metallic objects but it is possible that there was steel or other metal either beneath the ground or a ton of it in the concrete nearby.

This still doesn't excuse the DJI software from automatically doing a RTH and locking me out. And how does it explain the GPS errors? And why was I forced to authorize when I wasn't in an authorization zone?

Sorry but if you read the link I included in post #4 and any other case of a Phantom going uncontrollable with yaw errors after launching from reinforced concrete or close to a lot of steel, that is exactly what happens.
What you experienced was not related to any authorisation zone issue or messages on the screen.
You weren't locked out by anything DJI did or programmed.

 

[Meta4]

I know from experience when a piece of equipment is acting up often the sensors recording the event have also taken a hike,.

In this case there were serious compass issues but the recorded flight data is quite accurate

 

[Russ43Phantom]

I once launched from a wooden picnic table. Under the wooden top was a metal frame. The Phanton 3 Pro went wildly into a random flight pattern immediately after take off. I brought the drone down immediately before got too far away or too high. I had to re-calibrate the compass and launch the drone from more than 20 feet away from the table. All flight problems were resolved.

Now, every time I take off, I let the drone hover at about 8 feet high for about 20 seconds to be sure that all the flight characteristics are proper.

 

[THECaptainKirk]

Wow - some of you "experts" who know for certain that DJI's flight logs are without error amaze me. Any computer, any software, any and ALL man made machines are indeed absolutely capable of completely walking off the edge. Those of you who think you know everything those who then high five the other know it also (who can even analyze if a flight log is completely accurate or not) - thank goodness you DON'T work for DJI. I thought this was the Phantom Pilots Forum - when did it become the Phantom Di*khead on his high horse forum? Get all offended by my language - you guys are jerks for treating an experienced, licensed pilot this way. He was WAY more polite than I would have been. I also have (maybe had) a P4A that is currently on its way to the DJI service center. Ironically, why my bird fell like a rock from the sky at 16.4 feet is a mystery & unexplainable from my analysis and a good friend who is at least a kind and polite know it all. If anyone at DJI talks to me about my situation the way you guys talked to him I'll be on the next plane to visit the service center in person. Unbelievable.

Journeyfarm - your story is credible. DJI should send you a new bird at no charge. You've got more than enough evidence and experience to validate any smug, jackass who thinks flight logs are inerrant. Best of luck to you, sir. If you're not flying a Phantom or DJI product what will you be flying?

 

[Meta4]

Wow - some of you "experts" who know for certain that DJI's flight logs are without error amaze me. Any computer, any software, any and ALL man made machines are indeed absolutely capable of completely walking off the edge. Those of you who think you know everything those who then high five the other know it also (who can even analyze if a flight log is completely accurate or not) - thank goodness you DON'T work for DJI. I thought this was the Phantom Pilots Forum - when did it become the Phantom Di*khead on his high horse forum? Get all offended by my language - you guys are jerks for treating an experienced, licensed pilot this way. He was WAY more polite than I would have been. I also have (maybe had) a P4A that is currently on its way to the DJI service center. Ironically, why my bird fell like a rock from the sky at 16.4 feet is a mystery & unexplainable from my analysis and a good friend who is at least a kind and polite know it all. If anyone at DJI talks to me about my situation the way you guys talked to him I'll be on the next plane to visit the service center in person. Unbelievable.

Journeyfarm - your story is credible. DJI should send you a new bird at no charge. You've got more than enough evidence and experience to validate any smug, jackass who thinks flight logs are inerrant. Best of luck to you, sir. If you're not flying a Phantom or DJI product what will you be flying?

Captain Kirk ... if that's what you think, I'd say that you aren't qualified to say.
How many lost Phantoms have you found? How many mysterious flight incidents have you investigated and solved?
The flight record is completely believable.
We've investigated hundreds of flight records to trace the cause of incidents and there's nothing at all about this flight record to suggest it shouldn't be believed.
If you have a different idea and can substantiate it, please do.

 

[sar104]

Assumption? This is no assumption. I was there, I saw it. I saw a message that stated clearly that a RTH procedure was being initiated until an authorization token was generated. It was not recorded in the log. This is my entire point. Things happened that I witnessed in the software that you did not witness and will never be able to see in the log file.

Unfortunately whatever you saw on the screen regarding authorizations and RTH is, at best, moot in relation to final outcome. @Meta4 is correct that the aircraft did not record any transition to RTH but, even if you were correct that it simply wasn't recorded in the log, it doesn't matter. The compass errors had already tripped it into ATTI mode where RTH is not an option, and so the immediate reason that it flew away was the compass failure.

What caused the compass errors and why it lost connection at 1300 ft is unclear, and the remote log doesn't include enough detail to figure that out - that would require the aircraft DAT file. Also, the log indicates no stick inputs at all after the initial climb ending at 16.4 seconds until the end of the record at 85.5 seconds. Did you not make any attempt to control it with the remote between when it went into ATTI and when it lost connection? That was 70 seconds. The state of the tablet or phone screen has no effect on your ability to fly the aircraft with the sticks.

 

[K9VXV]

So if the RTH point was set on the map properly but the compass calibration was off then the Phantom would fly in the wrong direction to reach those coordinates? Wouldn't it make sense to true that value up once we figure out the direction we are moving via GPS over ground and then give us a compass error warning? When it is returning in this mode can we not cancel by pressing the RTH button on the RC? Maybe not because it's an override? I check the area using the flight zones tool just for this sort of thinng but if the compass calibration was off then it makes sense if just this sort of forced RTH were to happen they wouldn't want you to be able to cancel it. But in a situation like it am override for emergencies should be available. If you know it was going to fly into an auth zone you could switch it to ATTI before you get in it and fly as you need. The manual explains what happens when flying into NFZ using ATTI mode. It will not land or RTH until switched to other modes but in your case you didn't know about the auth zone before your flight. That combined with the compass errors caused your issues. I have not calibrated my P4P at all on compass. IMU though I have done a few times. Sorry for your loss, If you couldn't cancel the RTH or override with ATTI (because of a forced RTH) then I am not sure what else you could have done except fight the RTH as it tries to return home. This should always be available. You may not get the direction you want always but you can usually nose out of they area and then find where the fence ends and bring it back to you. I have had to do this a bit when the P4P detects obstacles in mid air that are not there. One time I was locked with no forward or backwards in mid air. I had to go up about 100 feet and the obstacle was cleared as far as the system was concerned and then I could move forward. Hope they help you out with this. Good luck. Jesse

 

[msinger]

@journeyfarm, I took a look at your flight log and I found it's telling a different story from what you remembered. According to your flight log, you took off near a magnetic metal object, the flight mode switched to ATTI mode, and your Phantom drifted away in the wind since you made no attempt to control it.

1) Do not allow people to lift off their aircraft if you're going to deny them the ability to fly once they're in the air.

Your Phantom stopped ascending after 17 seconds into your flight when you let go of the remote controller sticks. It was at an altitude of 208 feet. After that point, your flight log shows you did not move either remote controller stick. It appears that you just let your Phantom drift away in the wind.

2) The software should never lock someone out of controlling their drone for obvious safety reasons.

Agreed. However, it appears you made no attempt to control your Phantom after it stopped ascending. I'm certainly not going to rule out any possibilities, but I've never seen a flight log where the pilot made an attempt to control the drone and those controls were not recorded in the flight log while the downlink was still connected (like in this case).

3) Most importantly, if the software knows that there are GPS and Compass issues, do not send the drone to its home location

Your flight log shows no indication that your Phantom was attempting to return to the home point. It was actually moving further away from the home point right up to the point where the downlink dropped at the end of your flight log.

Again, I'm only telling you what your flight log is telling me. I of course have no idea what actually happened since I was not there.

 

[journeyfarm]

The flight log does not paint an accurate picture of everything that occurred. For some reason, all actions related to the Auth Zone messages and RTH were not indicated in the flight log. I was given the perception that I was unable to do anything with the aircraft until I cleared the authorization zone message.

Yes it may have had magnetic interference in the compass and that may have contributed to the fly away. The whole point of this thread was not to point out the magnetic interference but the fact that the Auth Zone lock out should behave different for circumstances where the pilot was unable to foresee environmental or other factors that may cause the drone to behave in a way that is unexpected.

We need to look at the Auth Zone process but we can't because it wasn't recorded in the log. Why does DJI not record the Authorization Zone actions in the log?

 

[journeyfarm]

This is also an important point. As I was lifting the aircraft with the vertical control stick is when the Auth Zone message popped up, I'd say about halfway to 3/4 of the way up. The Auth Zone should have came about before clearing for takeoff (that's issue #1 with the software). I spent about 10 seconds dealing with the Auth Zone message (which was precluded by an automated RTH message). I did make the assumption that my RTH point was set correctly so I did not immediately look up at the aircraft while dealing with the message. I assumed that the aircraft would have been descending back towards me. In the time I spent taking care of the Auth Zone unlock, the aircraft was able to get far enough away that it became disconnected with the controller.

I have had disconnects many times in the past, and many times I simply had to unplug my device from the remote and re-plug it in. I did attempt that to see if that was the issue but then realized it was simply too far away (possibly due to radio interference in the area). The aircraft remained in a "disconnected" state. Would disconnecting the cord and re-connecting it have an affect on the log file or the ability to continue recording log actions?

I then went back to dealing with the Auth Zone message, and I finally procured a token. I entered the token and unlocked the Auth Zone. Finally I had control, or what I thought was control. But the aircraft was already disconnected.

Also important is how fast all of this happened. The spotter was caught off guard because I hadn't even started a route yet. I've never had an issue this early into any flight. A perfect storm of the auth zone, the compass error, and the aircraft disconnecting as quickly as it did all contributed to the fly away.

Then I ran to the car with the spotter and we went down the road in the direction it went looking for a signal but found nothing after 30 minutes.

 

[K9VXV]

But you are right in the fact that the app should handle authorizations better. You should be dealing with this type of thing prior to take off unless it was temporary and signal was bad or spotty and the system didn't know about it until your cell got signal but it should have not even allowed a take off.

 

[BudWalker]

@journeyfarm let me just add that P4 didn't appear to be doing an RTH. I'm not disputing what you saw on the tablet, I wasn't there. If it had been doing an RTH the behavior would have been a lot different. With the P3 one thing that should never be done is initiate an RTH if the P3 has switched to ATTI because of a compass error. That's a guaranteed fly away. As @msinger observed you had a drift away.

In times past the Go App display hasn't always been accurate. At one point I saw a compass error indication during the flight that didn't show up in either the .DAT or the .txt. There were other indications of the problem though. My point being what's indicated in the Go App isn't always accurate. You can take DJI to task over this, but, good luck.

 

[msinger]

This is also an important point. As I was lifting the aircraft with the vertical control stick is when the Auth Zone message popped up, I'd say about halfway to 3/4 of the way up.

This is an interesting point. In your first post above, you said you couldn't control anything after the authorization message appeared. Your flight log shows you were in full control during 100% of the ascent (since your Phantom was obeying the remote controller sticks).

Whatever the case, you should at least make sure you get your story straight before speaking to DJI support again. If you claim one thing happened and then later claim something different, it might be tough to get them on your side.

 

[journeyfarm]

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 a minute later, maybe more 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 remains on the screen. I assume that it is locking me 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. 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).

 

[Meta4]

- 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.

Your Phantom NEVER triggered an RTH. And if it did, is wouldn't have flown off away from home.

- 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.

Without a properly functioning compass system, your Phantom cannot hold position regardless of GPS status.
Because the Phantom can't deal with conflicting data from the GPS and compass systems, it ignores GPS data and is then in atti mode.
There is no way around this.

- 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.

You had good GPS signal the whole time. Atti mode was triggered by the compass errors and yaw errors

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?

There is no doubt about the magnetic interference.
Your flight record shows an uninterrupted stream of compass errors and yaw errors from the time it was 25 ft above the launch point.
The compass did not fail - but it shows the result of a bad calibration - you mentioned calibrating it before the flight.
You have calibrated it in an are where the earth's normal magnetic field is distorted by a lot of steel.
While the Phantom is within the distorted magnetic environment, you calibrated it for, it appears to work normally.
Once the Phantom is out of the magnetic distortion and back in the earth's normal field, things go crazy because the comp[*** is now reading incorrectly.

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.

About 1:25.5 when the Phantom was 1352 ft away.

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?

As above, the Phantom had a full GPS signal the whole time.
The Phantom either has good GPS or no GPS, it doesn't get inaccurate position data with weak GPS signal.
The Phantom does not use your phone's GPS.
It has it's own GPS unit that it uses for all flight functions

You are in denial and clutching at straws but the facts aren't on your side.
Coming up with perhaps this ... or maybe that .. scenarios that are counter to the way Phantoms are programmed isn't going to bring your Phantom back.
The cause of the incident is very clear and this has been pointed out by some of the best in the game.
They've taken the time to properly assess and provided a more detailed explanation than you will get from DJI and much faster.
They are looking at the same data that DJI will and advising on how you can expect DJI to respond.

 

[Meta4]

For those suggesting that it seems like a lot of post here end up in a pissing contest to see whos the most knowledgeable, how about we all help one another as a hobby community and not down on a newbie who doesn't possess your superior background in flying ....
Back before the Phantom 3 series and the Go app, you could lose your Phantom 1 or 2 and not know why.
Some in that situation would say that the Phantom flew away and that was accepted as an explanation.
With the Go app, the Phantom 3 series and subsequent models have a flight data recorder that allows flight incidents to be properly investigated and work out what the cause of the incident was.
It can take a lot of effort and the members that are able to do this, do it for free for the benefit of all.
You are completely misunderstanding if you think this is a case picking on a newbie.
Finding the cause of an incident is important and helps everyone to become a better flyer.
To avoid this would help no-one.