Welcome, Autel Pilots!
Join our free Autel drone community today!
Join Us

Altitude Error

jf121

Active Member
Joined
Sep 1, 2022
Messages
25
Reaction score
1
Age
38
Hi,

I recently purchased an EVO II Enterprise with an RTK unit. I have used it on three survey missions so far and I keep getting erroneous altitudes while flying as well as those associated with the images captured during flight. For example, the altitude is often ~ -5 ft when I am flying 100 ft AGL.

Any thoughts?
 
The altitude is set at takeoff, so is relative to takeoff point rather than actual ground level.
 
Thanks for the reply and information.
My issues remain unexplained since the altitude should have been about 100 ft above takeoff, definitely not - 5 meters.
 
Barometer could be faulty or somehow pressurized. I have had false readings on my RC gliders when changing direction in wind but only 10 or 20 metres not 100.
 
It is relatively new so I hope that there is not a permanent issue with pressure sensors. Is there anyway to calibrate/reset the barometer?
 
Sorry I don't know. I would expect it resets each time it is initialised.
I would check that there is no tape or stickers etc covering any of the vents on shell. Or take it back to supplier to be checked/replaced
 
Are you using RTK?
It sounds like your altitude is reporting an ellipsoid value.

Where I live I am around -33 meters under the ellipsoid on the ground.

If I went up 100 feet or 30 meters I would be at around -2 to -3 meters or -6 to -10 feet.
 
  • Like
Reactions: hewell
Jaja,

I am using RTK with the USACE/Keynet Corrections Network.

Some of my flights are in Class D airspace from the Dover Airforce Base where other pilots have had odd results. However, I have the same issues with altitude at places far away from this airspace.

How do I check if it is an ellipsoid error and how do I account for it?

-Joe
 
Jaja,

I am using RTK with the USACE/Keynet Corrections Network.

Some of my flights are in Class D airspace from the Dover Airforce Base where other pilots have had odd results. However, I have the same issues with altitude at places far away from this airspace.

How do I check if it is an ellipsoid error and how do I account for it?

-Joe
 
Jaja,

I am using RTK with the USACE/Keynet Corrections Network.

Some of my flights are in Class D airspace from the Dover Airforce Base where other pilots have had odd results. However, I have the same issues with altitude at places far away from this airspace.

How do I check if it is an ellipsoid error and how do I account for it?

-Joe
I need the elevation/altitude of the images in relative to NAVD in order to get the terrain relative to the ideal datum. Anyway to post process the ellipsoid height?
 
How are you receiving your corrections? NTRIP from Keynet?
I am assuming you are receiving directly from Keynet to your controller and then to your drone?



I know nothing about Keynet. I do not know if they are sending out their corrections in NAD83 or WGS, orthometric or ellipsoid.
You need to ask them. You could run a simple test. When you are at FIX and on the ground see what your altitude is and then compare it to a map that lists ellipsoid height on the ground or even Google Earth with EGM96 would give you a reasonable orthometric height for comparison.

On your last question, if indeed your images have ellipsoid heights in them, use this NGS tool to obtain the Geoid height at a particular coordinate. It uses Hybrid Geoid 18. GEOID18 Interactive Computation | GEOID | Data & Imagery | National Geodetic Survey


Use this format for your coordinates: : 39.35701047 -74.45730073 and enter them all.

When you get your return page, copy the results and paste them in Excel. You will have to use the formula Orthometric = Ellipsoid - Geoid. Don't forget though that we are under the Geoid in Delaware and NJ so your math will be more like: (-32) - (-34) or -32 + 34 = 2 meters
 
Is there a way to correct for this? I'm using an EVO II V3 RTK and processing in Pix4D. When I import my images, they seem to be accurately displayed at about the 100' AGL that I flew at. However, when I import the GCPs the projected camera positions are at or below ground level. Using the Geoid calculator mentioned above for one of the photo coordinates it returns a value of -26.668 meters or about 87 feet, which seems to jive with the photos below.
 

Attachments

  • After GCPs Added Screenshot 2023-09-01 170410.jpg
    After GCPs Added Screenshot 2023-09-01 170410.jpg
    413 KB · Views: 6
  • Before GCPs Added Screenshot 2023-09-01 170315.jpg
    Before GCPs Added Screenshot 2023-09-01 170315.jpg
    259.8 KB · Views: 6
Is there a way to correct for this? I'm using an EVO II V3 RTK and processing in Pix4D. When I import my images, they seem to be accurately displayed at about the 100' AGL that I flew at. However, when I import the GCPs the projected camera positions are at or below ground level. Using the Geoid calculator mentioned above for one of the photo coordinates it returns a value of -26.668 meters or about 87 feet, which seems to jive with the photos below.
Please give me the coordinates and elevations of one of the images.
 
Is there a way to correct for this? I'm using an EVO II V3 RTK and processing in Pix4D. When I import my images, they seem to be accurately displayed at about the 100' AGL that I flew at. However, when I import the GCPs the projected camera positions are at or below ground level. Using the Geoid calculator mentioned above for one of the photo coordinates it returns a value of -26.668 meters or about 87 feet, which seems to jive with the photos below.

I really need more information.

1. When receiving corrections, what are the horizontal and vertical datums? I will assume NAD83(2011) and an ellipsoid elevation.
2. If 1 above is correct, do this:
A. For Output : Use the Projected Datum of choice (NAD83(2011) / WGS 84 State Plane or UTM and then use the Height Above Ellipsoid for your Vertical Datum. In the field where it asks Height above ellipsoid place the result of doing the following: (Find the centermost image in your map area, get the coordinates and run them in the Geoid 18 Tool. You will get the geoid undulation (Just like your -26.668 above). Now do the math H=h-N. h is the elevation listed on the image, and N is the geoid undulation. Now take the answer/result and place it in the field height above ellipsoid.
B. For Images Datums: Use NAD83 2011, the geographic coordinate system with the globe shape next to it., and for your Vertical System use height above ellipsoid, but this time leave the field at 0, as this indicates that you elevations from your images are ellipsoid values.
C. For you Control Points I again have to make an asuumption that you collected them in NAD83(2011) geographic with an ellipsoid elevation. If this is True for your Control Point datums use NAD83(2011) geographic, with the globe symbol. For your vertical system again use the Height Above ellipsoid option and keep the field at 0 to indicate ellipsoid elevations.

Also don't forget to choose feet or meters. But in the future I would collect my Control Points in Meters and let Pix4D output yourmap in US ft if you need US ft.

Feel free to PM me if you need more help.
 
  • Like
Reactions: TCLMike
Jaja6009 - thank you very much. I'll try to answer your questions below.

Photo Coordinates: 44.28734717, -70.52334637, 141.712 meters elevation
GCP Coordinates: Maine State Plane - West NAD83
GCP2,529600.012,2859941.393,447.324
GCP3,529996.365,2859543.003,452.882
GCP4,530022.486,2859572.886,453.172

I was flying at about 100' AGL with some step downs down to around 80' AGL. I always choose feet when using RTK Rover and in P4D processing. I choose the same state plane in P4D that I do when mapping GCPs with the RTK Rover.

My partner mapped the same scene at ~100'AGL with a DJI Mavic 2 Pro so that we could compare, before we move over to the Autel exclusively on 9/16. I used exactly the same settings when I processed the DJI photos as I did when I processed the Autel photos in P4D (obviously different cameras - but the remainder of the settings are the same). I've attached a screenshot of the camera locations in P4D, with the calculated camera positions from the DJI processing - it is vastly different in regard to the calculated camera positions compared to the Autel processing. This makes me think that there is a setting in the Autel that I need to change - I just don't know what it is yet.

I'm also attaching the Quality Reports for the Autel and DJI P4D processing in the event there are some clues that I'm missing but you may see immediately.

Thank you for your help! I've been scratching my head for the last two days trying to figure this out. As an aside, the point clouds and orthos for both came out fine - it's just the vast difference in the calculated camera positions in the Autel processing.
 

Attachments

  • DJI After GCPs Added Screenshot 2023-09-02 181204.jpg
    DJI After GCPs Added Screenshot 2023-09-02 181204.jpg
    313.4 KB · Views: 3
  • Kamp Kohut DJI_report.pdf
    1.1 MB · Views: 6
  • Kamp Kohut P4D 484_report.pdf
    1,023.8 KB · Views: 4
OK, while there are many ways to do this this is what I would do. You can do this for just Step 1 and if all is good then proceed and finsih Step 2 and 3.

I still need to know one thing. Was the drone receiving corrections and if so in what Datum? I again will assume NAD83(2011) with an ellipsoid elevation. The coordinates you gave have an ellipsoid elevation at 141.712 meters. This makes sense because you said you were around 100 feet AGL when flying and the ellipsoid height on the ground at the first image coordinates you gave me was 111.31 meters with 30 meters (98 feet) AGL making the drones image elevation 141.712 meters.

So reprocess Step 1.

Load your images. For your images Datum, check the Advanced box and enter the following
Unit Meters, Known Coordinate System NAD83(2011) Geographic with the Globe icon
Vertical Coordinate System is Geoid Height Above GRS80 ellipsoid m and leave the field as 0 as your elevations in your images are in ellipsoid elevation.
1693701892552.png

For your Output Coordinate System
Choose Known System
Your Datum is NAD83 NSRS 2011
Your Projected Coordinate System is NAD83(2011) Maine State Plane West ftUS
For Vertical choose Geoid Height Above GRS80 Ellipsoid and in the field place the Geoid Undulation -87.493 (For this I would choose and image in the middle of the project. Get the coordinates and run it in the Geoid 18 Tool, get the undulation which should be close to this and use that figure. Pix4D Mapper does not output elevations in the correct way. They take an undulation value and apply it to your map to shift the whole map vertically. The problem is that even in small areas mapped, the undulation value differs, sometimes up to 1 cm even in small areas.)
1693701857356.png
Choose your Standard Maps or Model Processing Template

Make sure to only run Step 1 as this is where you check your project before committing to the long time it takes to process your dense point cloud, 3D model and orthomosaic.
Go up to Project in the top left and choose GCP Manager.
For your GCPs Coordinate System Use the Following:
Make sure you use the same undulation as in your Output Coordinate System

1693701801351.png


Next use all three Control Points as Check Points. If you were using RTK and receiving corrections, you should be able to obtain low centimeter accuracy without the use of GCPs. To do this click on Type for each one and change it to Check Point.
You can then Use the Basic Editor to mark each control point in your images. I usually mark them in 5 at this point and then after processing the first step I use the Ray Cloud Editor to mark them in more images.
If all looks good, run Step 2 and 3.

In the future you can use GCPs with your RTK drone, but to be able to "check" the accuracy of your outputs, you MUST use check points. And again, I have processed datasets from Evo 2s with RTK and they for the most part do not need GCPs to obtain low centimeter accuracy as long as you had a FIX status for all of your images.

In the future I would do this.
Recieve your corrections to your Evo 2 in NAD83(2011) with an ellipsoid elevation.
Collect your control points in NAD83(2011) with ellipsoid elevations.

Pix4D Settings
Images - NAD83(2011) Geographic with Vertical System Height Above Ellipsoid, field 0 to indicate ellipsoid elevations
Output System - NAD83(2011) ME State Plane W ftUS with Vertical System being Height Above ellipsoid, and use the center most images geoid undulation value in the field.
GCP System - NAD 83(2011) Geographic with Vertical System Height Above Ellipsoid field 0 to indicate ellipsoid elevations.

THis helps to not get mixed up with meters, feet, and also orthometric vs ellipsoid elevations (At least it does for me).

When processing with a Non RTK drone like the mentioned Mavic 2 Pro, The GCPs will correct the vertical system to whatever vertical system you are using.
 
Also to note, EGM96 does give reasonable orthometric elevations, it has the following problems:

EGM96 has a resolution of I think 10 meters in its grid system while Geoid 18 has a 1 ft resoltuion.
Technically it is for use with WGS84 and your outputs are in NAD83(2011). While some software state that they are equal, they are not and can be 1 to 2 meters difference.
I have not tested if Pix4D even does a transformation from WGS84 to NAD83 (2011) but don't really need to since I am using a workflow that does not need to know.
By using the Height Above Ellipsoid as above you are using NAVD88 with Geoid 18 which is the correct vertical datum for NAD83(2011) although how Pix4D applies an orthometric shift leads to mm to cm level error depending on the size of the map. (Very large maps will have a more severe error) Pix4D Matic does include a proper Geoid 18 Undulation Grid though.
You will be better served to prepare for the new National horizontal and vertical datums that will be here in 1 to 2 years by learning how to correctly apply the formula H=h-N as the new datums will have GPS observations in mind.
 
Last edited:
JaJa6009,

Thank you so much for the time you have taken to educate a mere novice in the field, although I've been at it for just about 4 years now! I had a very short Pix4D course, back in 2019, when the vendor provided us a 'quick start' course after entering the UAV/Point Cloud/Pix4D world from using total stations. Since then, I've been mostly self-taught going through much of the Pix4D support and forums - so, thank you for your patience, I really, really appreciate it!

As for the Autel flight, I was receiving correction from Maine CORS via a VRS connection, as opposed to 'near site single connection'. From research (see attached document) it would appear that ME CORS uses "now NAD83(2011), actually using NAD83(2011) Epoch 2010." Apparently this retired police officer needs to learn more about coordinate systems!

Another question for you - Is there anything specific that I need to do when setting up the processing using RTK correction data? I had posted that question in a Pix4D User's Group on Facebook, and received differing answers. One said to check the "Accurate Geolocation Data" in the Step 1 processing options and others said that there was nothing else needed. In this processing, my first using RTK where I had a 'Fixed' notation on RTK throughout the flight, I initially chose "Accurate Geolocation Data" but then saw the difference between the actual and the calculated camera positions - so I reprocessed unchecking "Accurate Geolocation Data", but had the same result. I have also adjusted the camera to the 'Optimized' parameters and saved it for future use.

I just re-read your posts and now have another question - Following that flight, I met up with a co-worker to ensure that our second Autel EVO II V3 RTK was squared away (I had some significant issues getting the firmware to update, controller to aircraft connection, etc. which Autel Support helped me fix - same issues with the second aircraft, but we fixed it). About 2 hours before our meet up and about 40 miles to the east I had flown the mission we're talking about - achieved a 'fixed' solution after a couple of minutes and it stayed 'fixed' throughout the flight. When we were testing the two UAVs in NH (NH doesn't have a CORS system so we tend to rely on ME, MA, and VT depending on which is closest to us) neither of our UAVs achieved a 'fixed' solution even after about 20 minutes. So...my plan in this type of situation is to fly non-RTK, like we would with the Mavic. When flying non-RTK, follow the same guidelines you've outlined above (minus the RTK specific instructions)?

Thank you again, I can't tell you how much I appreciate your assistance!
 

Attachments

  • SPCZoneDefinitionsUsedinMaine11-2015.pdf
    715.9 KB · Views: 2
JaJa6009,

You are a genius, wizard, or whatever you'd like to be addressed as! I did what you said and you will see from the attached post-Basic and RayCloud Editor screenshots it seems to have fixed my problem. Now, I'll need to digest it and develop a new workflow to deal with it. Thank you so much!
 

Attachments

  • After GCP-Checkpoint Basic-RayCloud Screenshot 2023-09-03 115451.jpg
    After GCP-Checkpoint Basic-RayCloud Screenshot 2023-09-03 115451.jpg
    160.9 KB · Views: 6
  • After GCP-Checkpoint Basic-RayCloud1 Screenshot 2023-09-03 115451.jpg
    After GCP-Checkpoint Basic-RayCloud1 Screenshot 2023-09-03 115451.jpg
    155 KB · Views: 6

Latest threads

Members online

Forum statistics

Threads
11,288
Messages
103,010
Members
9,899
Latest member
rudymuller