Altitude Issue When Surveying with the DJI Inspire

PIX4Dmapper PIX4Dmapper Questions/Troubleshooting
1

 

 

 

 

 

Notice: I was unable to post the following article on the DJI Support Forum, but thought that this article may still be of interest to Pix4Dmapper users as well, though the issue discussed pertains specifically to bogus altitudes written to the EXIF by DJI’s Inspire air frame.

Our second test flight for survey grade aerial mapping may have seemed like a bust given that we’ll need to take another go at it; however, the lessens learned from this begin with visualizing in Pix4D the importance of well placed surveyed ground control points. In the image above, we are viewing towards the west at about normal eye level when standing level on the road surface. The three blue precisely surveyed points are in the distance beyond the limits of the flight. I believe that this height anomaly is largely or entirely attributed to the enormous difference between the geotagged camera altitude and its true altitude.

Note to pilot in command: You should check to see that you have the latest firmware and that it has been properly installed. Currently (20160305) DJI page lists:

Inspire 1 Firmware v.1.6.0.40

2015-12-22

Crazy east-west flight path due to the DroneDeploy app’s limited functionality (v1.4.7) after Pix4D Capture failed to process flight path.

In addressing this issue yesterday after we returned from the field, I called DJI tech support (1.818.235.0789) and eventually spoke with Mike on both occasions, who in both instances supposedly tried to connect me with the so-called tech support for the Pro product Inspire as he was admittedly unqualified to give technical support for the Inspire. In both instances, the signal immediately changed to a busy signal. Mike refused to provide a direct phone number to that DJI department when asked during my second phone call.

Next I tried posting on the DJI forum after having first successfully registered and signing in; however, am thwarted from posting: "

Hi, Kelly Bellis.

An email has been dispatched to kellybellis@gwi.net with details on how to active your account. Please check your email and follow the link in that email before you can post on DJI Forum.

Haven’t receive the email? Please click here to send the email again.

"
Even after clicking to send email several times, no such email has been received on my mail server. Had I been successful in posting, here is what I’d post and for informative purposes am posting on the Pix4D support forum. Also cc:'ing to us.support@dji.com:

Altitude off significantly - What’s up with that?

 

Noting EXIF field names and values for image [DJI_0514.jpg]

Airframe: DJI Inspire
Camera: FC350

The geotagged images produced by the DJI Inspire are in reasonable agreement horizontally with the precisely surveyed ground control; however, the recorded altitude of the camera (FC350) is quite a bit off; e.g., one nadir image (DJI_0514.JPG) reports the altitude of the camera at -47.4 meters or about -155.5 feet below sea level, whereas the actual ground elevation was about 112.7 feet NAVD88 (Ellipsoid height near this location was 28.1 feet). The flight plan was supposedly at an altitude of 150 feet above ground, making the actual elevation of the camera at about 262.7 feet NAVD88.

If we assume, for the sake of discussion, that in theory, _ zero _ altitude to be determined at ground level of the location where take off occurred, then the algebraic sign recorded in the geotagged image looks like a possible chief suspect as being incorrect.

The Inspire’s User Manual (dated 12/17/2015) v2.0_1218.pdf offers a little in terms of only suggesting how the altitude is derived for geotagging. It states  (on pages 12 and 28) that height above ground; i.e., altitude, is barometrically linked. On the other hand, if the height that gets recorded is based on GPS, then there is way too much error, particularly given the wide open unobstructed view of the sky and 11 SVs all easily within the Inspire’s line of sight to them.

Has anybody else run survey grade ground control and observed similar errors in geotagged heights?

In the EXIF data of the photo, there should be clear indication that altitude is neither determined by nor associated with GPS, and that it is solely based upon the device’s internal barometric reading. Furthermore, there ideally should be an EXIF field and value for GPSEllipsoidHt once a 3D fix is known.

Kind regards,

Kelly

Mr. V. Kelly Bellis, ME PLS 2099 :: WQTS485
17 Union Street :: Ellsworth, ME 04605
(207) 667-6912

 

 

2

Has anybody else run survey-grade ground control and observed similar errors in geotagged heights?

And in followup; to Pix4D Support, how important is it in having reasonably correct altitude values?

 

3

Hi,

I was doing a survey of 49 acre land - I am getting similar results , The altitude is around 300m and i flew the drone at about 60m approx.

I will be taking GCP’s for more accurate data.

 

At the moment i am getting accuracy of 7m which is huge, however i am looking for accuracy less than 5 cms.

 

 

4

We are experiencing similar issues with every project using the inspire. This is new to us as it didn’t use to happen. Perhaps it is in the latest firmware. Does anyone have a solution? We are ok using the basic editor with ground control points, but it takes a bit longer to process each project. Could it be to do with using a different app to fly the area?

5

Hi all,

According the latest news on our side that refer to the firmware v.1.7.0.90 and v1.7.0060 for the Inspire I and Phantom 3 Pro respectively, DJI now measures the absolute elevation above sea level using EGM 96 as the reference. They used to record the elevation above ground level but this is no longer the case.

However the vertical coordinate is still not fully reliable. Indeed, we made testing in our office here and we found that the vertical coordinate is off by several meters that can reach an error of 100 meters. Some users noticed the same. Therefore our developers suspect something wrong in the DJI EXIF regarding the vertical coordinates.

As a consequence, we always recommend to process with ground control points (GCPs) in order to fix these uncertainties.
About using GCPs: https://support.pix4d.com/hc/en-us/articles/202558699

Note that DJI just released on April 7th new drone firmware, v1.8.1.00 and v1.8.80 for the Inspire I and Phantom 3 Pro respectively, that could fix the vertical coordinate issue. So far we do not have any feedback.

Which firmware did you use when experiencing the same issue?

 

6

Because of the shift between the model and the GCPs it can be impossible to use the rayCloud in order to mark the GCPs. Instead of using the basic editor that requires some manual work, we suggest to do the following.

Once the project is created and the images are imported:

  1. Run step 1. Initial Processing.
  2. Create 3 Ground Control Points (GCPs) manually using the right sidebar of the rayCloud. The mark of these GCPs should correspond that of GCPs that are intended to be imported later. For more information: https://support.pix4d.com/hc/en-us/articles/202560109

For each point that is manually added:

  • In the Label field, write the name of the GCP and make sure it is the SAME as the one written in the input GCP file containing the coordinates.
  • In the Type field, select 3D GCP or 2D GCP from the drop-down list.
  • Do NOT edit or enter the point coordinates.
  1. Import the GCP coordinates into the project from the file using the GCP/MTP Manager. For more information: https://support.pix4d.com/hc/en-us/articles/202560039
  2. Just after importing the coordinates a window pops up. Click Yes to All, so that the previous coordinates of the 3 GCPs that were created are replaced with the information contained in the input file.
  3. On the Menu bar, click Process > Reoptimize. The model should adjust to the 3 GCPs.
  4. Mark the other GCPs (if any) in the rayCloud following: https://support.pix4d.com/hc/en-us/articles/202560769

Hope this is helpful.

Regards,

7 
Hello everyone. I used the ghost DJI 4 in a recent article for cutting and lifting landfill in an area of 200,000 m2 . The greatest difficulty that our company faced was to determine the correct elevation of the photos captured by Phantom 4. Does anyone know if the problem found in the DJI Inspire also occurs in DJI Phantom 4? Thank you.
8

Hi Bruno,

Yes indeed, the inaccuracies found for Inspire 1 drones regarding the vertical coordinate also apply to other DJI drones, including Phantom 3 series, Phantom 4, and other most recent ones.

Regards,

9

I wish that I have had more time to do further tests and the analysis of the data, but here is a start.

The Vetting of Phodar

The results of the aerotriangulation performed on the six test projects are available at http://aerial.panocea.us/notes/vetting-of-phodar/. In particular, the adjusted camera locations have been contrasted with the geotagged locations of the cameras (Δx, Δy, Δz) to underscore the reason and need for surveyed GCPs.

Of course, there are numerous factors which are involved. For example, the aircraft’s firmware played an important role in how the altitude was passed onto the EXIF writer as each image was geotagged from the barometer. In four out of six cases spanning February through April 2016, they were erroneously referenced as being BELOW SEA LEVEL! The firmware on the aircraft and DJI’s GO App also influenced in how the pilot was allowed in only two cases out of six, to define a flight path that wasn’t explicitly limited to the major axis being along cardinal directions; i.e., only east-west or north-south.

Therefore; because of the complexities and number of variables that are involved, no conclusions have be drawn. It is however interesting to note the patterns that are illustrated when some of the numbers, for example Post Processed Shifts (Δx, Δy, Δz), are graphed. The magnitude and distribution of positional errors were surprising. Most notable was the shift vertically, but also curiously indicated was the apparent horizontal shifts linked with flight path direction.

10

Is there any signs of phantom 4 firmware update to fix the altitude problem? The barometer is so inaccurate that my drone seemed to fly up to 200m relative altitude which is illegal in my country… Some of the flights seemed to be okay and most of them are not accurate (90m of relative altitude given by the dji ctrl is about twice the real altitude the drone flies)… Looking for a way to fly safely!

11

I ran into the same problem with my Phantom 4. DJI is recording into EXIF the GPS altitude, relative to the ellipsoid, which is very rarely accurate or useful for photogrammetry or surveying. I had photos showing up as below sea level as well, and inaccurate (ellipsoid-referenced) elevations throughout my study area. Thankfully, the barometer information is still present in jpeg metadata, but you have to make some tweaks to bring it out. Here’s how I did it, though there are likely other ways (note: some basic coding is involved):

I used exiftool: http://www.sno.phy.queensu.ca/~phil/exiftool/

This (freeware) application can be run from the command line, though I did it within R using “system()” to call exiftool.exe, though the same syntax should work. If you go the R route, exiftool.exe should be in your working directory.

You can view all the metadata tags with a command like system(“exiftool DJI_0807.JPG”)

You’ll see several tags, though the relevant ones are GPSAltitude, RelativeAltitude, and GPSAltitudeRef. GPSAltitude is referenced to the ellipsoid; you’ll want to replace this with RelativeAltitude, which is determined by barometer readings between the launch point and UAV position. You also might need to change GPSAltitudeRef to make it above sea level. This can all be done with the following line of code:

system(“exiftool -n -GPSAltitudeRef=0 -tagsFromFile @ -RelativeAltitude>GPSAltitude DJI_0807.JPG”)

NOTE: this will change the altitude to ‘above sea level’ whether it is or isn’t, so if you’re flying in the Dead Sea or somewhere like that, you’ll have to do it differently.

This will substitute RelativeAltitude for GPSAltitude, and in my experience Pix4D and other EXIF readers interpreted this correctly. It’s also possible to run this recursively on folders full of files, for example if for the final argument you use “photos/” (i.e., a folder) instead of “DJI_0807.JPG” (i.e., a file).

I recommend looking over the exiftool documentation if you have problems. Hope this helps someone!

JB

 

 

12

Likewise to what is being reported here I’ve been looking at the metadata recorded by the DJI Mavic Pro and have found that the GPS altitude tag is not orthometric height (~MSL height) or ellipsoidal height. For instance, one location I tested at is at approx +33 m MSL and the geoidal  separation (N, EGM96) is -21 m so the GPS altitude (Ellipsoidal) at ground level should be +33m + (-21m) = +12m but the recorded GPS Altitude tag is -65m (all numbers rounded to the nearest meter). Even given the approximations and rounding that is a error of 77 meters which seems excessive even considering it is GPS derived elevation using Standard Positioning Service. The error also seems systematic and not random which is what you’d expect of error from GPS. 

It almost looks like DJI is converting ellipsoidal height to orthometric but with the sign on the EGM reversed.  I have not tested it on surveyed points yet but the GPS Altitude tag appears to contain neither ellipsoidal or orthometric heights. Use with serious caution. 

One possible work around would be to use Exiftool Like Jeff describes above but calculate the relative elevation + the MSL elevation of the start point as a constant to get a better approximation of MSL elevation for the image locations.

13

We have noticed the same problem, we get around 100m wrong positioning of the images every time. Of course using gcp’s will correct this but its annoying. We’ve done tests with Agisoft Photoscan and the result is accurate to our flight height there, so the issue is between Pix4D and Dji EXIF. Tests were done with M210 RTK and Phantom 4 pro using the same images. 

14

Hi Alex, send us a subset of 10 images via a support request so we will the check what is written in the image EXIF. Also please provide us the expected elevation of the model.

15

Do all GCPs have to be marked in the ray cloud? I want to use some GCPs with which I only know their 3d coordinates.  I did what you suggested in an earlier post, as far as marking 3 GCPs and then importing and replacing with those of the exact same name.  That worked great!  But then, when I tried to manually enter 6 more GCPs and reoptimize, they are shown as being up above the project (but their pattern is correct).

16

17

@James, we noticed that the question is a duplicate of the one here. In order to keep the community clean, we encourage you do not create duplicated questions. 

The final answer will be provided here.