hdop - Is there any indication of horizontal position accuracy from DJI Go or Litchi?

Joined
Jan 25, 2016
Messages
166
Reaction score
58
Age
86
Location
Glendale, Arizona
I have searched, and can't find it.

Is there any indication of horizontal position accuracy from the DJI Go App or from the Litchi App during a flight? I fly P3P with Litchi, and would like to be able to watch the hdop (or horizontal position accuracy) via any telemetry on my tablet. I thought I saw where the DJI Go 4 app had GPS signal bars related to hdop. (hdop = horizontal dilution of precision). If so is that available on a P3P using Litchi? Thanks.
Joe
KC7GHT
 
If so is that available on a P3P using Litchi? Thanks.
Not that I am aware of in real time. Position accuracy depends on too many variables for everything to be "viewed" in real time, and even at that it is not exact.
 
I looked at the variables names that are sent from the AC to the DJI Go App .txt file, as well as sent from the AC to the Litchi App .csv file, and did not see hdop - even though hdop is loged in real time in the P3P AC DAT file. I would think that this parameter would be helpful when flying close to large high rock formations or around the perimeter of a mountain lake that is surounded by high mountains. It might be a better measure of GPS accuracy than the number of satellites. Just thinking.
 
It might be a better measure of GPS accuracy than the number of satellites. Just thinking.
Correct, using the aircraft .dat will give you all of the information that you would need. But, IMO, it is not practical to transmit and have that available for display within the app. It would be a huge undertaking to to do that, not only with storage but for speed in processing from the device. It would surely cause more video lag which is already an issue at times with certain devices.
 
  • Like
Reactions: joeruby
I have searched, and can't find it.

Is there any indication of horizontal position accuracy from the DJI Go App or from the Litchi App during a flight? I fly P3P with Litchi, and would like to be able to watch the hdop (or horizontal position accuracy) via any telemetry on my tablet. I thought I saw where the DJI Go 4 app had GPS signal bars related to hdop. (hdop = horizontal dilution of precision). If so is that available on a P3P using Litchi? Thanks.
Joe
KC7GHT
You might be interested in the gpsLevel (aka gpsHealth or navHealth) signal. It's a measure of the confidence the Flight Controller has in the position that it calculates from GPS, IMU and magnetometer data. A high hDop value will lower the gpsLevel value.

GpsLevel has a value in the range [0, 5] with 4 or better being necessary for GPS mode. When the FC decides to lower gpsLevel to <4 it usually switches to ATTI mode.

GpsLevel can be seen in the Go App as a bar graph display with the numerical value above it. It can also be seen on the RC.
112703

I'm not sure if gpsLevel is displayed in Litchi.

IMHO gpsLevel and gpsHealth are misnomers. That's why CsvView/DatCon uses the label navHealth.
 
  • Like
Reactions: joeruby
There is no way to know the real horizontal accuracy of the gps derived horizontal accuracy of the aircraft position. This is the same issue as the accuracy of the home position accuracy without any Vision Assistance. The basic position accuracy is determined not by the Phantom or tablet, but by the actual position accuracy provided by the collection of satellites being used at that moment. That accuracy is a horizontal circle with a radius of 16 feet. The aircraft will be within that circle 95% of the time. That is the only guaranteed spec of the system, and should be used in any high risk situation. In practice, the statistics will have the accuracy much better a lower percentage of the time, for example, + or - 8 feet 30% of the time (an example not fact).

This is why the professional mapping systems use a different gps technique standard to get the accuracy required for the higher level of accuracy needed.
 
Bud,


You may be right here, but I don’t see how the intrinsic probalistic inaccuracy of the GPS position gets integrated into the accuracy forecast from theGPS location, IMU, and magnometer. That calculation simply integrates those three. Does the data from the IMU and heading cancel the GPS errors? The only way to reduce GPS errors with the system used by DJI is to average a number of closely spaced GPS Readings, which doesn’t seem possible in the time available.

Thanks,
Dave
 
Bud,


You may be right here, but I don’t see how the intrinsic probalistic inaccuracy of the GPS position gets integrated into the accuracy forecast from theGPS location, IMU, and magnometer. That calculation simply integrates those three. Does the data from the IMU and heading cancel the GPS errors? The only way to reduce GPS errors with the system used by DJI is to average a number of closely spaced GPS Readings, which doesn’t seem possible in the time available.

Thanks,
Dave
The coords computed by the FC aren't the actual GPS coords (they're really close though - see below). They are repeatable though which allows the AC to hover with very little lateral drifting. A Kalman Filter (or variant) is used to estimate the coords - it's not just an integration of GPS, IMU and magnetometer data. The KF incorporates a dynamic model along with sensor inputs to produce coord estimates that have a higher resolution, in both time and space, than the raw GPS coords.

If the FC has reason to suspect that the Yaw value is incorrect the navHealth value will drop - usually to 0. This is because a lateral movement detected by an accelerometer can't then be used to update the coords. Without knowing the Yaw it can't be determined which way the AC has moved.

I get it. The GPS data is only good to 16 feet or so. But based on my flights, it seems to always be the case the that recorded HP is within a foot or so. Usually, a HP gets recorded soon after the GPS comes on line. Then, that HP is updated with more accurate coords once navHealth gets to 4. The first recorded HP is usually within 10 feet - often closer. The second HP is always within a foot or so - at least that's the way it looks on Google Earth.
 
Bud,

The use of a Kalman filter makes it all a lot clearer. I went through the overview of how it works, and am convinced that solution would yield far higher accuracy, and a measure of the likely accuracy of a point in time. I have used many DP techniques, but somehow never connected with the Kalman filter. How do the vision position sensors get integrated into this system at low altitudes? Does altitudes below 10 meters from home point cause position sensor data to be added to the Kalman filter calculations?
 
........ How do the vision position sensors get integrated into this system at low altitudes? Does altitudes below 10 meters from home point cause position sensor data to be added to the Kalman filter calculations?
That's a good question. I would presume that either GPS or Vision System data is used but not both. There are two signals; isGPSUsed and isVisionUsed. I've never seen them both be True.
 
Interesting. I don't see why you couldn't do all of the above for a more accurate solution unless the vision system's accuracy so dominates location determination so as to make anything else irrelevant.

Certainly my background in robotics would support this notion. At a gross level, like picking up something, motion path analysis was useful to avoid breaking things, but the actual pickup relied on accurate vision sensors. At micron dimensions making semiconductors, finding the edge of something required both scanning sensor data, and a DSP convolution to determine the actual x-y a 10s of micron space.
 
Correct, using the aircraft .dat will give you all of the information that you would need. But, IMO, it is not practical to transmit and have that available for display within the app. It would be a huge undertaking to to do that, not only with storage but for speed in processing from the device. It would surely cause more video lag which is already an issue at times with certain devices.
Fly Dawg, I am wondering why it would be such a large task. I believe that the information (hdop) is available on the AC DAT file in real time. Also I understand, that in the DJI Go app it is available as green bars next to the satilite count display. I would like to understand why this couldn't be easily added to the Litchi App too. I am just looking for something that would warn me to stop as I fly into a canyon, or up close to a cliff face that would block some of the satillites.
 
I believe that the information (hdop) is available on the AC DAT file in real time.
hdop is contained in the aircraft .dat, but is not transmitted. Everyone wants everything available for viewing. The reason I say a huge undertaking is due to that fact. It would need to transmit everything and allow the user to select the display parameters they want. You can't please everyone. That is far too much data to transmit without severe latency, at present.
 
hdop is contained in the aircraft .dat, but is not transmitted. Everyone wants everything available for viewing. The reason I say a huge undertaking is due to that fact. It would need to transmit everything and allow the user to select the display parameters they want. You can't please everyone. That is far too much data to transmit without severe latency, at present.
Thank you for the answer. I don't want any more video latency either. I will just have Litchi warn me every 15 seconds when my satellite count drops below 12. That may give me enough time to abort the mission and climb for more satellites, and fly home.
 

Recent Posts

Members online

Forum statistics

Threads
143,066
Messages
1,467,352
Members
104,933
Latest member
mactechnic