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

Altitude Error

Good news!
Any chance you can attach the Quality Report as it will answer any questions I have such as did you only use the Control Points as Check Points and what your final RMSE was on those checks.

To answer your questions:
Another question for you - Is there anything specific that I need to do when setting up the processing using RTK correction data?

Yes you can use the Accurate Geolocation option, but I have never had to. My opinion is that having the accuracy data for the images and GCPs weights Pix4D well enough for RTK obtained images and my results are almost always very good using the normal settings. There are some other more advanced options and things you can try, but I have only lightly delved into them as I use Agisoft Metashape now and have stopped exploring them.

I have also adjusted the camera to the 'Optimized' parameters and saved it for future use.

Yes, some people will save the camera parameters from a good processed data set for future use. I have also done this, but for the most part, I still usually use the default values and will then goto a saved set if I had trouble getting tight results.

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)?

I am only lightly familiar about VRS, a couple of our other members will surely chime in with good information about it. I do know that it uses multiple bases around where you are. In my opinion you are too far from the bases and since you would think VRS wants bases around your position, accuracy/precision will suffer. What GNSS rover do you use? I use Emlids which are good for my use cases. From my testing the GNSS chip in our drones are not as good as the ones in handheld rovers and when my Phantom 4 RTK is more than 25 km from a base, it starts to have trouble holding fix, while my handheld Emlid rover gets FIX and holds it.

There are a couple of things you could do. Fly a non-RTK workflow and just collect GCPs and Check Points and process as you said as a non-RTK drone. If you have 2 Emlid units you could use VRS to make your own known point on site, send corrections to your rover to collect GCPs and Checks and send corrections to your Evo 2. You could even try a PPK workflow.


I am a firefighter and was put through classes to run our drone program through Emergency Mangement and our cops are now using it for accident scenes. Every problem you had, they had so I am well versed in addressing them. I stress one thing, don't settle for anything other than the best output. Make your products as accurate as can be and do not skimp on your vertical datum. EGM96 will not give the best orthometric ("Above Sea Level") elevation. The geoid undulation process I showed you will allow you to use NAVD88, using Geoid 18 which is the correct vertical datum for NAD83(2011).

A problem I saw is that a member of PD took an accident scene class that was a week long. There is no possible way that this class could teach you datums, coordinate systems, geoids and ellipsoids as well as all of the other information you need to start making maps. If it was crammed in there, it would be information overload. This is the weakness of those classes, they give you enough to start making maps and models and good workflows, but as soon as you need to change a workflow you do not have enough base knowledge to proceed.

On a final note check you Private messages, I will link you a video I made when I taught Remote Sensing at our local college. It shows processing an RTK drone dataset, full explantion of how and why to choose coordinate systems for your images, control points and outputs. It also shows with visual aid how the geoid undulation works and why Pix4D mapper introduces error since it lacks a true geoid 18 grid. I also have a video on processing GCP maps and maps with no GCPs and no RTK drone.

And finally I learned my craft from our local college, members on these forums, local surveyors and just plain reading books, white papers and Dave Doyles incredible webinars on Youtube for Florida GIS.


One more thing, always use Check Points!!! You cannot make an assumption on the absolute accuracy of your data without them!
 
  • Like
Reactions: TCLMike
Good news!
Any chance you can attach the Quality Report as it will answer any questions I have such as did you only use the Control Points as Check Points and what your final RMSE was on those checks.

To answer your questions:
Another question for you - Is there anything specific that I need to do when setting up the processing using RTK correction data?

Yes you can use the Accurate Geolocation option, but I have never had to. My opinion is that having the accuracy data for the images and GCPs weights Pix4D well enough for RTK obtained images and my results are almost always very good using the normal settings. There are some other more advanced options and things you can try, but I have only lightly delved into them as I use Agisoft Metashape now and have stopped exploring them.

I have also adjusted the camera to the 'Optimized' parameters and saved it for future use.

Yes, some people will save the camera parameters from a good processed data set for future use. I have also done this, but for the most part, I still usually use the default values and will then goto a saved set if I had trouble getting tight results.

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)?

I am only lightly familiar about VRS, a couple of our other members will surely chime in with good information about it. I do know that it uses multiple bases around where you are. In my opinion you are too far from the bases and since you would think VRS wants bases around your position, accuracy/precision will suffer. What GNSS rover do you use? I use Emlids which are good for my use cases. From my testing the GNSS chip in our drones are not as good as the ones in handheld rovers and when my Phantom 4 RTK is more than 25 km from a base, it starts to have trouble holding fix, while my handheld Emlid rover gets FIX and holds it.

There are a couple of things you could do. Fly a non-RTK workflow and just collect GCPs and Check Points and process as you said as a non-RTK drone. If you have 2 Emlid units you could use VRS to make your own known point on site, send corrections to your rover to collect GCPs and Checks and send corrections to your Evo 2. You could even try a PPK workflow.


I am a firefighter and was put through classes to run our drone program through Emergency Mangement and our cops are now using it for accident scenes. Every problem you had, they had so I am well versed in addressing them. I stress one thing, don't settle for anything other than the best output. Make your products as accurate as can be and do not skimp on your vertical datum. EGM96 will not give the best orthometric ("Above Sea Level") elevation. The geoid undulation process I showed you will allow you to use NAVD88, using Geoid 18 which is the correct vertical datum for NAD83(2011).

A problem I saw is that a member of PD took an accident scene class that was a week long. There is no possible way that this class could teach you datums, coordinate systems, geoids and ellipsoids as well as all of the other information you need to start making maps. If it was crammed in there, it would be information overload. This is the weakness of those classes, they give you enough to start making maps and models and good workflows, but as soon as you need to change a workflow you do not have enough base knowledge to proceed.

On a final note check you Private messages, I will link you a video I made when I taught Remote Sensing at our local college. It shows processing an RTK drone dataset, full explantion of how and why to choose coordinate systems for your images, control points and outputs. It also shows with visual aid how the geoid undulation works and why Pix4D mapper introduces error since it lacks a true geoid 18 grid. I also have a video on processing GCP maps and maps with no GCPs and no RTK drone.

And finally I learned my craft from our local college, members on these forums, local surveyors and just plain reading books, white papers and Dave Doyles incredible webinars on Youtube for Florida GIS.


One more thing, always use Check Points!!! You cannot make an assumption on the absolute accuracy of your data without them!
I’m replying to this on my phone. When I get back to my computer I will give you a more comprehensive reply. But than you!
 
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!
Quality report from the processing after applying your wisdom - let me know if I missed anything. Thank you!
 

Attachments

  • Kamp Kohut Autel Correction1_report.pdf
    1,017.7 KB · Views: 8
There is something going on. Your RMSE on your checkpoints is really bad for an RTK workflow.
The image overlap is inconsistent, but I guess you tried to not be over the road?

Long corridors can be tough. Sometimes without GCPs or RTK they like to curl up like a banana.

If you can I would do this for a test of a new workflow.

Test on a small square area so we can just test an easy RTK workflow.

Receive your corrections to the drone in NAD83(2011) ellipsoid elevations, which should be the case. Make sure all images are FIX
Collect your control points in NAD83(2011) ellipsoid elevations. Collect in FIX for 2 minutes.

When you process use these settings:

Images NAD83(2011) Height Above Ellipsoid 0 m
GCPs/Control Points. Use all points as check points. NAD 83(2011) Height Above Ellipsoid 0
Output Coordinate System - NAD83(2011) ME State Plane W US Ft For Vertical find the center area of the map, get the undulation from the Geoid 18 Tool for those coordinates in the center of the map, convert the meters to ft in a tool and place that in the Height Above Ellipsoid field.

Your Evo 2 RTK should have RMSE under 0.2 US ft.
 
  • Like
Reactions: TCLMike
There is something going on. Your RMSE on your checkpoints is really bad for an RTK workflow.
The image overlap is inconsistent, but I guess you tried to not be over the road?

Long corridors can be tough. Sometimes without GCPs or RTK they like to curl up like a banana.

If you can I would do this for a test of a new workflow.

Test on a small square area so we can just test an easy RTK workflow.

Receive your corrections to the drone in NAD83(2011) ellipsoid elevations, which should be the case. Make sure all images are FIX
Collect your control points in NAD83(2011) ellipsoid elevations. Collect in FIX for 2 minutes.

When you process use these settings:

Images NAD83(2011) Height Above Ellipsoid 0 m
GCPs/Control Points. Use all points as check points. NAD 83(2011) Height Above Ellipsoid 0
Output Coordinate System - NAD83(2011) ME State Plane W US Ft For Vertical find the center area of the map, get the undulation from the Geoid 18 Tool for those coordinates in the center of the map, convert the meters to ft in a tool and place that in the Height Above Ellipsoid field.

Your Evo 2 RTK should have RMSE under 0.2 US ft.
I'm replying quickly (perhaps more later) as I need to get some more pressing work stuff done presently. If you recall at the start of our conversation, I had only used 3 GCPs - that's because GCP1 recorded with 0.04 horizontal and 0.07 vertical errors; GCPs 2-4 were all 0.01 horizontal and 0.01 vertical. I had processed it with all 4 GCPs and saw that there were some issues, so I removed GCP1, reprocessed and everything came out pretty good. I forgot to remove GCP1 on the last processing - I suspect that is the issue. On the overlap, yes I fly manually. As retired law enforcement, I don't have the option of closing a road down like we used to do and I'm somewhat conscientious about Part 107 so I don't want to fly over moving vehicles. I've been flying the Mavic for the last 4 years and I will admit that I'm still getting used to the EVO II, so my right stick nudge forward, take a photo, and repeat may need a little finessing.
 
Okay I also had some time to look at your Quality Report more thoroughly.

You are getting the required accuracy on 2 out of 4 check points. One of the more inaccurate ones isn't too bad and the final one is extremely off for RTK.
So it looks like your Evo 2 RTK is geotagging your images well while receiving your corrections.
Is Check Point/GCP 1 on the edge of the map while the others are better placed? I know it is a skinny corrider and this will create problems and cannot be avoided. So maybe in the future widen the area where you obtain images to help keep the Control Points off the edges.

How long are you collecting your Control Points? I use the settings to only log while in FIX only for a minimum of 1 minute, but will do 2 minutes also. Again you do not need GCPs for your Evo 2 RTK to be able to obtain sub 6 cm (0.2 ft) accuracy, but corridor mapping is unique so maybe it might be best to collect both GCPs and Check Points. Also don't fall into not using check points and then just looking at the initial and optimized camera positions and the accuracy of your marked GCPs. While those can be helpful, you must use Check Points to "check" your accuracy.

I am sorry but I know nothing about Maine DOT VRS (Most likely Trimble). I either setup my own base on an NGS monument and send out corrections to my Rover and Drone or use a small regional RTK/NTRIP service, and I use Emlid GNSS receivers. I cannot help you on that end as there is not information I was able to find that answered my questions on a Google search. But we do see that what you are doing right now is for the most part working as you Evo 2 RTK geotagged images are matching up to half of your Check Points well. We also see that even when you are collecting your Control Points in projected NAD83(2011) ME State Plane for control points and your Evo 2 RTK in NAD83 (2011) with ellipsoid elevations we can get Pix4D to get it close. I think your check points again need to be off the edges more and you need to measure them for two minutes in FIX only (I am not sure if you are not, just guessing). Another item is that Maine DOT VRS is using Geoid 12 B. For one of your control points I checked the difference and there was no difference between Geoid 18 and 12B for those coordinates.

Some of your vertical inaccuracy will be from how Pix4D uses just a single geoid undulation and applies it to all elevations with the Height Above Ellipsoid Vertical choice. Your software on your tablet for collecting control points will be giving you your orthometric elevations in the correct way and will have a different undulation value for each point. Example: You used one undulation value for the whole map in the Height Above the ellipsoid field, each control point used something similar to the geoid tool you used and can give an undualtion that slightly disagreed at those particular coordinates. I checked this on 2 of your control points and the error was tiny, as in millmeters, but in a large project this will grow.

Next problem is the software you are using to collect your control points. If this software is not giving an anticipated accuracy that you import into Pix4D along with the X,Y and Z, Pix4D will not weight them properly. Your control points just like your images should have the accuracy values filled to work best. Check Points don't use this in Pix4D. Check your software to see if you can enable this to be given for each control points and import this information into Pix4D.

You can use GCPs with RTK and some people will always use at a minimum of 1 GCP even when using an RTK drone. I do this on my beach mapping where I collect one GCP in the center of the area and then collect check points all over the area spread out. You can try this on your current project we are discussing, but when you do you will have to change some settings. If you want to try this choose the Control Point with the lowest RMSE and change it to a GCP and use the others as check points. There may be a problem though since you will not have an accuracy value for this and Pix4D could not weight it accordingly. If you do try this give it an accuracy of around 0.1 US Ft Horizontal and 0.2 vertical. Now with a GCP, your vertical elevations will be from the GCP and will be in NAVD88 usng Geoid 12 (The orthometric elevations you have for your GCPs). So here are your settings: Image Coordinate System is NAD83(2011) with Height ABove Ellipsoid and field being 0 to indicate your Evo 2 RTK was reporting its elevations as an ellipsoid value. GCP Coordinate System is NAD83(2011) ME State Plane W US ft with Vertical System being Arbitrary. Output Coordinate System is NAD83(2011) ME State Plane W US ft with Vertical system being Arbitrary. We are using Arbitrary for the Vertical because your collected GCPs are already in orthometric elevation so we do not have to use the Height Above Ellipsoid with a geoid undulation that we used before. Your elevations will still be in NAVD88 using Geoid 12 with this way of doing it.
 

Latest threads

Members online

Forum statistics

Threads
11,292
Messages
103,024
Members
9,903
Latest member
Aerugo