Bill VS

Accurate 3D Georeferencing: DJI Unit GPS altitude values are WAY off. Any help?

Recommended Posts

Can anyone advise me about the problem with vertical GPS values on DJI units? The horizontal values seem to be just fine.

We have an Inspire 1 and an Phantom 4 Pro. We have been using them, along with DroneDeploy and Pix4D, to map wetland vegetation for wetland restoration projects in Florida. The problem arose when we started combining imagery with survey to create and deliver 3D models to our engineering colleagues.

Both UAVs report accurate altitude to the RC, but the EXIF tags tell an entirely different story:

  • A photo taken at ground level (let's say, 65' above sea level), is tagged with an elevation of -88.0 (no indication of what the units are, but .5 units represents about 100').
  • If we fly 100' into the air and take another picture, it now reports an altitude of -87.5 units.
  • Per the DJI helpline folks, we've tried recalibrating the unit right before flight, and that doesn't seem to make a difference.

Unfortunately, the images captured indicate that, rather than 200' over the levee (which is about 70' on the NAVD88 datum), the image thinks that it was captured from a position 20' or so below the roadbed. Flying another 100' or 200' up still doesn't get us above ground level. So Pix4D and Simactive both have trouble resolving this, and even manually editing the GCPs (at least in Pix4D) doesn't seem to fix things.

DroneDeploy does a decent job of creating a model, but it's not georeferenced, and that's part of scope. Plus, 1) I'd like a more detailed model than they generally provide, and 2) my management will not support the subscription upgrade necessary to use GCPs, especially since we already purchased a license of Pix4DMapper.

Dishing out $20K for an RTK unit is not on-budget for a few more years, so let's just assume that's not a solution. Besides, we don't need centimeter accuracy for the flight, just for the solution after the GCPs are incorporated. Just being within a few meters of reality (as advertised) during flight would be fine.

We could probably write a python script to write pressure altitude values to the GPS field, but that seems like kind of a sloppy workaround.

Any other ideas? Does anyone have a buddy at DJI who might fix this?

Kindest regards,

   - Bill

William E. VanSickle

Professional Geographer, Commercial Remote Pilot

GIS Analyst III, Office of Information Technology

St. Johns River Water Management District
P.O. Box 1429 ● Palatka, FL 32178-1429
Office: (386) 329-4580
Email:
bvansickle@sjrwmd.com

Website: www.sjrwmd.com

Connect with us: NewsletterFacebookTwitterInstagram, YouTube, Pinterest

 

Share this post


Link to post
Share on other sites

Hey Bill, thanks for posting. I’m a consultant (civil engineer) in Brevard so it’s good to see SJRWMD getting into the use of drones. They’re a great tool, and we use them for almost all of our current engineering projects. We use a Phantom 4 Pro and process in Pix4D. Since almost all of our projects involve a surveyor, we have the benefit of using very accurate GCPs for processing our imagery.

As you might know already, the altitude readings are based on barometric pressure. They’re going to be relative readings, meaning that even if you calibrate the drone before flight, the altitude is still going to be some “random” value that doesn’t correspond to any real NAVD88, NGVD29, etc. value. Until you use an RTK model (or something along those lines) or input some type of ground control information, you’re not going to be able to achieve any real level of vertical accuracy. Your horizontal accuracy may also be off by a decent amount (5-10 ft in our experience). Your imagery may also “tilt” in one direction since there’s no vertical control to orient it correctly.

To achieve what you’re looking for, your best bet (for having a small budget) is to input some type of ground control in your Pix4D processing. There are some pretty cheap GPS units out there that could give you a decent measurement of x, y, and z. By setting a few targets and inputting some “good enough” values into Pix4D, it will greatly improve your results. They won’t be perfect, as the GPS units have limited accuracy, but it would be a big improvement over no control at all.

  • Thanks 1

Share this post


Link to post
Share on other sites

Hey Bill, how's it going? Interesting to see you here, do you remember me? Wow, you're flying drones for the District, that's great! 

Anyway, to your issue...

I have had this before and the bottom line is that the Phantom 4 Pro uses barometric pressure for altitude for flying because the GPS is notoriously inaccurate, but it seems it posts the GPS altitude in the photo exif's.  Here's a link to folks discussing the issue. https://forum.dji.com/thread-148221-1-1.html

Anyway, I agree with Casey, it's well worth getting GCP targets on the ground, typically 4 corners and the center for each flight area.

Cheers,

Nadine

  • Thanks 1

Share this post


Link to post
Share on other sites

Hey Nadine and Casey! It's good to hear from both of you!

It's also good to hear I'm not the Lone Ranger regarding the vertical error problem. 

We placed and surveyed a dozen survey targets on the Lake Apopka Levee at the time of flight, so I have GCP data. The problem is that Pix4D doesn't seem to accept the GCP input, either in "automagic" mode or manual edit. And the folks at Pix4D are little or no help. 

If you have Pix4D and Skype, could we set a time this week or next to share my screen and go through the steps together? 

 

Share this post


Link to post
Share on other sites

As is being pointed out this isn't really a drone related issue as much as a technique for collecting the data, however, DJI does not make it easy to develop a good technique.  Also, mentioned is the accuracy of products like Pix4D, DroneDeploy etc., I'm not to saying they aren't good products, just depends on your technique and the use of the map or model your producing.

Here is a part of a model we did for a utility: http://162.144.22.103/models/Transformers/#%2F . This is part of an eight acre substation, we spent one day scanning it and the customer spent about a week ground truthing it and it wasn't out more than 1.2cm in any axis on any part of the field.   

There are some concepts you should keep in mind if you want that kind of accuracy.  We fly at approximately 7m/s, if your relying on GPS and taking latency into consideration, the drone might have traveled as much as forty feet between the time it was supposed to take an image the time it actually took to record.  If that where a constant, this would mot  be that difficult to accomplish.  Trouble is it is not a constant so the distance between waypoints is a variable that you have to account for.  If you don't then your relying on Pix4D to calculate the exact position and you see the results for yourself.

 

  

   

Share this post


Link to post
Share on other sites

Hey all, thanks so much for responding to this post. My ability to spend time on the project waxes and wains due to higher priority stuff, but I think I'll be able to get back on it pretty soon. CaseyC reached out, so I'm going to provide them some info soon, but I'll cc this post if you guys would like more nuts n bolts.

Just to clarify, here are some bullet points to clarify the error we're talking about here:

  1. By my calculation, the GPS units that DJI is recording (on both the Phantom and the Inspire) are 1 unit equals about 50', so that's going to account for a pretty huge difference in the EXIF tag. It's possible, for instance, that DJI's firmware may be recording in U.S. Survey Chains (60') or Indian Bamboos (42', established by Akbar the Great in the mid-1500's). To quote Adam Savage, "THERE'S YOUR PROBLEM", or at least part of it.
  2. Values are also negative. So instead of 100' above the roadway, the UAV thinks it's flying 50' BELOW it, putting the surveyed target ABOVE the UAV, and therefor not in the picture in order to be selected as a GCP.
  3. The barometer values are not too bad, actually, and the calibration was a few minutes before the first observation, taken at the same XY location but hovering at different altitude. So speed should not be an issue here.
  4. I'm not sure how to make Pix4D use the barometer elevation instead of the "GPS Elevation", which is the extra-screwy one.
  5. This GPSAltitude problem has been reported before, and has been discussed at https://forum.dji.com/forum.php?mod=viewthread&tid=154027, and https://forum.dji.com/thread-117047-1-1.html, but not in a very satisfactory way.
  6. So far, everything seems to point to a bad Geoid (geometric model of the earth) conversion.

The nearest answer I can see so far is to write a program to dump the RelativeAltitude data into the GPSAltitude tag in the EXIF file. It'd be nice if I could figure out how to get Pix4D to look at the RelativeAltitude instead of the GPSAltitude.

 

Edited by Bill VS
Clarification

Share this post


Link to post
Share on other sites

I have good news! 

I went out and flew a test mission straight up and down, capturing images at 0, 50, 100,... 400, 375, 325, 275, etc., to get relative and absolute elevation values every 25', ascending and descending. Used Exiftools to export the metatags from the imagery, and...

the problem is linear (r-squared equals 1!) , and the units are indeed in meters:

  • image.png.917b2e19732de662d5819620588f3f44.png
  • Apparently DJI uses a weird ellipsoid (model of the earth's surface) in their calculations, so in my area, the elevations are 70.5 m (231.4') below what they should be. That explains why the UAV thought it was below the roadway I was overflying, and it should be resolved by adding 70.5 to all GPSAltitude values.
  • Although DJI doesn't seem super exited about fixing the problem, Pix4D has a workaround. It's in their Image Properties editor, and it looks sort of like this:
  • hYIAX4yaOK3-d493zC14HA.png
  • You can also use ExifTool to fix the problem, along these lines:
    • exiftool -n -GPSAltitudeRef=0 -tagsFromFile @ -RelativeAltitude>GPSAltitude DJI_0807.JPG

    • I don't know if that will work, but if the P4D fix doesn't work, I'll certainly give it a try.

Thanks, all, for your consideration and comments!

Share this post


Link to post
Share on other sites

Hi 

I have been reading your posts.

I am a surveyor and licensed drone pilot in South Africa and I do a great deal of aerial surveys for various clients, mainly mines. I place Ground Control Points with a RTK GPS before each flight and then processing the data in Agisoft. I get very good results in XY and Z. I have also found tilting in the model, but only if the ground control is not correctly spaced. Long thin areas are prone to this tilting. My work around is to fly at least 4 lines along the line and place the ground control as far as possible on either side with a few in the middle. Then process the data in chunks (with an overlap between the chunks ie, have common ground control points on adjacent chunks) in order to keep reasonably  rectangular shape.

Share this post


Link to post
Share on other sites

Thanks Harry, for your perspective and counsel! 

I have the RTK ground control and markers, and am much closer now to a solution after adjusting the altitude. I'm also very fortunate to have a survey benchmark visible on the imagery to use as a checkpoint. I'm going to have to develop some serious Pix4D muscles to get within my intended accuracy of an inch or so, but I hope to get it done next week.

Do you happen to know how best to share the resulting product to someone who uses AutoCAD Civil 3D?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.