Phantom 4 Pro Flyaway

[AlanTheBeast]

I don't (can't, won't I tell ya![1]) believe it has anything to do with wind. I was flying in some pretty hard wind last week with gusts and never got any such message (I know, I know...).

I suspect it's the first item in my list. If the programmers are Chinese then the proverb "A man with two watches doesn't know what time it is" may apply so they declare stupid.

Smart would be to at least figure out which (GPS or GLONASS) has the best signal conditions to continue (this assumes they are getting more than rudimentary status from the GPS/GLONASS sensor about the state of each receiver. (ie: which has the most sats with the best signal/noise and FOM's)). Or simply say, "GPS is always pretty good, let's go with that" as long as it is tracking well with say 6 sats or more. (Same-ish logic for the GLONASS if GPS looks suspect).[2]

[1] Going with the "wind" theory it could be that the IMU estimates and the GPS estimates are diverging too much. But that doesn't make the GPS position "bad" and it should be relied on to at least allow RTH.

[2] GPS has come a long way in 20 years. It used to be that receivers would bare a lot of their internal data to examination. That's all been obfuscated over the years as the devices have been integrated into more and more consumer devices and such info deemed not of interest by the integrator... at least in Android phones such "deep" data can be revealed by appropriate programming and apps down to the ability to do RTK with an Android phone. Apple deem this to be too deep in iOS.

 

[sar104]

I don't (can't, won't I tell ya![1]) believe it has anything to do with wind. I was flying in some pretty hard wind last week with gusts and never got any such message (I know, I know...).

I suspect it's the first item in my list. If the programmers are Chinese then the proverb "A man with two watched doesn't know what time it is" may apply so they declare stupid.

Smart would be to at least figure out which (GPS or GLONASS) has the best signal conditions to continue (this assumes they are getting more than rudimentary status from the GPS/GLONASS sensor about the state of each receiver. (ie: which has the most sats with the best signal/noise and FOM's)). Or simply say, "GPS is always pretty good, let's go with that" as long as it is tracking well with say 6 sats or more. (Same-ish logic for the GLONASS if GPS looks suspect).[2]

[1] Going with the "wind" theory it could be that the IMU estimates and the GPS estimates are diverging too much. But that doesn't make the GPS position "bad" and it should be relied on to at least allow RTH.

[2] GPS has come a long way in 20 years. It used to be that receivers would bare a lot of their internal data to examination. That's all been obfuscated over the years as the devices have been integrated into more and more consumer devices and such info deemed not of interest by the integrator... at least in Android phones such "deep" data can be revealed by appropriate programming and apps down to the ability to do RTK with an Android phone. Apple deem this to be too deep in iOS.

I agree that inability to hold position doesn't make the GPS position "bad" - but it doesn't say that it is bad - it says "mismatch". It doesn't say what is mismatched with what but, given that the FC always has a target in terms of location or course, it could be a language-challenged way of saying that the GPS location is mismatched with the intended location - that was my hypothesis.

I had not considered that it might be a GPS/GLONASS mismatch. I guess that's possible, but isn't it a single, integrated receiver that simply reports position and estimated error, rather than two distinct receivers that independently determine location from the two different systems?

 

[Meta4]

"GPS Mismatch"? What does that even mean? Does it mean:

Looking at logs in which this appears, it seems that it means nothing at all.
It turns up a lot and often in groups of 5 or 6 but there is never any problem with the GPS data.
It's just a false alarm like the strong wind warning.

 

[sar104]

Looking at logs in which this appears, it seems that it means nothing at all.
It turns up a lot and often in groups of 5 or 6 but there is never any problem with the GPS data.
It's just a false alarm like the strong wind warning.

It may well be unimportant but it presumably means something. It would be nice to rule it out as being related to the problem.

 

[Meta4]

It may well be unimportant but it presumably means something. It would be nice to rule it out as being related to the problem.

I've seen it a lot in logs including many of my own flights and carefully checked everything I can think of to work out what it's saying.
And the best I can come up with is that it has nothing to do with any problem.

 

[AlanTheBeast]

I agree that inability to hold position doesn't make the GPS position "bad" - but it doesn't say that it is bad - it says "mismatch". It doesn't say what is mismatched with what but, given that the FC always has a target in terms of location or course, it could be a language-challenged way of saying that the GPS location is mismatched with the intended location - that was my hypothesis.

I had not considered that it might be a GPS/GLONASS mismatch. I guess that's possible, but isn't it a single, integrated receiver that simply reports position and estimated error, rather than two distinct receivers that independently determine location from the two different systems?

Scanning the uBlox ICD (not even sure it's the correct one for the P4P) it appears that it is very aware of the different signals being received and that the 'client' can get both solutions separately. There are a lot of "GPS" specific outputs and there are a lot of "GNSS" outputs, but I didn't see any "GLONASS" outputs. So it could be individual GPS is available but that GNSS is merged GPS/GLONASS/SBAS.

Hard to say - the ICD is 170 pages... and it would also be impossible to know _what_ messages DJI are requesting of the GNSS uBlox receiver or how it configured it short of putting lines on the serial bus to the uBlox and recording all messages to/from from cold start to in-flight.

EDIT: Just noticed the ICD (for uBlox 6) has NMEA sentences for GPS -OR- -AND- GLONASS. Not both concurrently. Also not sure if DJI use NMEA or the binary protocol. ...

EDIT: Edited the EDIT above. NMEA would permit both sentence types to be broadcast.

 

[circpro]

Yep, from someone who's still waiting to get his back from DJI, let the intelligence of the software work for you. It knows how to return to home, if your confused, just bring it back through the automated system.
Mine stop transmitting when it hit the tree and the battery popped out. Healthy drones told me last position and a little geo cache on my phone led me to the sad site.
It was my own fault, I tried to push the envelope past the safe return just to take 3 more shots for a pano. Then it went into auto land but would of been on the side of a mountain. I tried to get it closer, I could see it, and I crashed it into the tree

 

[Clockman]

Yes, it was enabled

Colision avoidance is not active in sport mode. Another reason you should not have put it in that mode.

 

[Falcon900]

I would like to know what causes GPS off in redundant system with so many satellites available.

Unless the P4P has more than one GPS receiver, it would not have "redundant system". I do not know whether it does have more than one GPS receiver, perhaps someone on this forum does.

 

[sar104]

Unless the P4P has more than one GPS receiver, it would not have "redundant system". I do not know whether it does have more than one GPS receiver, perhaps someone on this forum does.

It has dual compasses and IMUs, but the specifications don't mention dual GPS receivers.

 

[AlanTheBeast]

Unless the P4P has more than one GPS receiver, it would not have "redundant system". I do not know whether it does have more than one GPS receiver, perhaps someone on this forum does.

It has a single device that receives GPS, GLONASS and SBAS. Possibly QZSS (Japan). But it's a single device. I've been poring over the ICD for a uBlox 6 (Same as or very similar to what's in the P4P / Mavic Pro) trying to understand it better but it's raising more questions than providing answers.

For example it's not clear if the GPS and GLONASS position (and velocity and time) data are carried to the MP's processor(s) separately or as a combined position. It is (I believe) possible for it to output NMEA messages for both GPS and GLONASS at the same time. But we don't know what is actually happening. (or if it's actually using the binary protocol and not NMEA...).

The "redundancy" is a question of perspective but you're correct that at the vehicle level if the uBlox chip goes Tango-Uniform then there is no position solution.

The thing that would be nice to know is how the MP f/w handles a "healthy/good" GPS PVT v. a "healthy/bad" GLONASS PVT and v-v.

Or a GPS with good FoM and GLONASS with poor FOM. (or v-v).

Or GPS with good SBAS aiding v. GLONASS with no SBAS aiding.

and so on.

 

[trevsdad]

Sorry for the loss, hope you find it.

That said, it does appear that pilot error and aeronautical decision making (ADM) process contributed greatly to this loss. Like many in this thread, I've experienced the sudden the loss of GPS with the Phantom dropping into ATTI for a short period of time. One of the common denominators is that it always seems to happen in high wind. The last time this happened to me, winds on the deck were 15kts gusting to 25kt, but I needed to get a job done so I made an attempt. At about 90ft AGL, the wind picked up, (...winds always higher aloft) the drone began to drift rapidly and it switched to ATTi. I descended as rapidly as possible, flew in ATTI, regained control and landed, problem solved. My point is this...due to forecasted high wind, I expected that kind of flight behavior and was prepared to do something about it. Hard to do if your Phantom is 1,000ft AGL and a half mile down wind.

At that hight and distance, it's clear with no VLOS, the pilot lost orientation. Instead of engaging 'sport mode', a more useful decision might have been to engage 'home lock', but it's not clear that fuzzylogic is aware of the feature, or its function.

Bottom line...much of this knowledge about wind characteristics and ADM came from my part 107 training. If fuzzylogic (...or anyone else for that matter) hasn't studied for and taken the test, I'd highly recommend it even if you don't plan to fly commercially. It'll make you a better pilot.

 

[Solly747400]

Sorry about your loss buddy. I hope the best possible outcome for you.

a more useful decision might have been to engage 'home lock'

Yup, homelock would've done the job, but you still need GPS for that to work, just as you do for RTH. Either of them would've brought the bird alot closer if not home.

 

[Meta4]

Colision avoidance is not active in sport mode. Another reason you should not have put it in that mode.

His Phantom was 900 ft above flat ground so there were no obstacles to be of concern.
I asked because leaving obstacle avoidance enabled reduces your speed and ability to fight wind in P-GPS mode.

 

[trevsdad]

Sorry about your loss buddy. I hope the best possible outcome for you.



Yup, homelock would've done the job, but you still need GPS for that to work, just as you do for RTH. Either of them would've brought the bird alot closer if not home.

good point...

 

[Twilightdrone]

If there are no obstacles to worry about, you gain extra speed by disabling obstacle avoidance.

What a great tip! As a newby, I'm continually amazed at what can be gleaned from the wealth of experience of other pilots. Stuff I've not come across in the manual. Cheers!

 

[Twilightdrone]

Sorry for the loss, hope you find it.

That said, it does appear that pilot error and aeronautical decision making (ADM) process contributed greatly to this loss. Like many in this thread, I've experienced the sudden the loss of GPS with the Phantom dropping into ATTI for a short period of time. One of the common denominators is that it always seems to happen in high wind. The last time this happened to me, winds on the deck were 15kts gusting to 25kt, but I needed to get a job done so I made an attempt. At about 90ft AGL, the wind picked up, (...winds always higher aloft) the drone began to drift rapidly and it switched to ATTi. I descended as rapidly as possible, flew in ATTI, regained control and landed, problem solved. My point is this...due to forecasted high wind, I expected that kind of flight behavior and was prepared to do something about it. Hard to do if your Phantom is 1,000ft AGL and a half mile down wind.

At that hight and distance, it's clear with no VLOS, the pilot lost orientation. Instead of engaging 'sport mode', a more useful decision might have been to engage 'home lock', but it's not clear that fuzzylogic is aware of the feature, or its function.

Bottom line...much of this knowledge about wind characteristics and ADM came from my part 107 training. If fuzzylogic (...or anyone else for that matter) hasn't studied for and taken the test, I'd highly recommend it even if you don't plan to fly commercially. It'll make you a better pilot.

What do you (or did he, if any one else can tell me please?) mean by the term "home lock"? Is this just another name for "RTH" or a separate feature altogether?

 

[Meta4]

What do you (or did he, if any one else can tell me please?) mean by the term "home lock"? Is this just another name for "RTH" or a separate feature altogether?

Home Lock is one of the many intelligent flight modes you find here:

And here are some more:

 

[broux2]

To elaborate a bit on home lock, pulling back on the stick will bring it directly toward the home point regardless of orientation.

 

[Brimba]

Is there a way to always start app and fly in home lock?