Getting terrible accuracy vertically with rtk

[Jasono]

Hello everyone,


I have an evo II pro RTK v3

I am using a custom base station with NTRIP caster by ublox.

I used my rover to survey varius point along a block such as in street, on curb, in gutter et...

Now when i fly my autel evo II (Which i just purchased i see a bowl effect from the take off point. There is areound a foot of fall to the south and about the same rise to the north. When i process the images i see 10 or more feet of rise in both directions.

I see that somewhere there should be a way to set the drone to MSL vs AGL for mapping but i only see that option under slope.


Please Help with any idea

I am using open drone mape to process the images

 

[jaja6009]

The Evo will report altitude in your images as follows:

When not receiving corrections: WGS 84 geographic coordinate system with elevations as an ellipsoid value ( I do not own one, but this seems to be the case)
When receiving corrections: In the datum and coordinate system that the base is sending. What are you sending to the drone? I would think NAD83(2011) with ellipsoid elevations correct?

I have never used open drone map, but you can process Step 1 in Pix4D with their free Discovery mode. I can help you if you go that route.

 

[Jasono]

The Evo will report altitude in your images as follows:

When not receiving corrections: WGS 84 geographic coordinate system with elevations as an ellipsoid value ( I do not own one, but this seems to be the case)
When receiving corrections: In the datum and coordinate system that the base is sending. What are you sending to the drone? I would think NAD83(2011) with ellipsoid elevations correct?

I have never used open drone map, but you can process Step 1 in Pix4D with their free Discovery mode. I can help you if you go that route.

Are you referring to pix4d mapper?

 

[Jasono]

I performed some more diagnostics.

I connected to polaris online for rtk corrections to ensure my base wasn't and isse and i found the exact same behavior.

 

[jaja6009]

I am not following you at all.

Are you saying that when you are receiving corrections and the drone is flying that it rises and falls on its own when applying throttle? Are you saying it does the aforementioned while on a mapping grid mission?

Or are you saying that when you process a dataset in Open Drone Map that the elevations in the outputs have this inaccurate elevation?
If my assumptions are accurate, does this happen only when receivng corrections?

It would really help if you answered the question, what datum and coordinate system are you receiving corrections in? NAD83(2011) with ellipsoid? When using your own base are you placing an ellipsoid value or orthometric value when setting up your base and then sending corrections? If you are using something like RTK2GO to send NTRIP I would make sure you are not sending the elevation as an orthometric value, make sure its an ellipsoid value.

 

[Jasono]

Both those things are true.

After a mapping mission when i process the images in ODM the farther away from the takeoff point i get the higher the elevations are. This is also true in the exif data embedded in the images before processing. The images are in wgs84 elipsoidal.

My understanding is that the base only send rtcm deviations so the actual transmission won;'t have any datum related to it. The base is set with an ellipsoid elevation and uses wgs84 for coordinate system. All transformations happen on the rover/drone. so any datum would be applied there by applying the deviation to what its internal gnss results are.

I have tried using a corrections service and not using my base to send corrections which produce the same result.

when receiving corrections regardless of source the farther from takeoff point to higher the raise in the elevation data stored in exif.

This does not happen withour RTK corrections the grade is actually more accurate relative to the takeoff point than when recieveing corrections.

 

[jaja6009]

Okay, I understand now.

I have not heard of this before on this forum.

Some questions that may be stupid, just ruling things out.
All images are FIX?
You are not changing the source of corrections while the drone is on and then flying? If you change the source of corrections you should reboot the drone.
Have you tried to PPK the images?
Make sure you have the newest firmware for both controller and drone too.

Hopefully one of the forum members who are more knowledgable in Casters, NTRIP and RTK jump in.

 

[Jasono]

Yes they are all in FIX RTK and no there is no changes in source during flight

I also used my rover with the exact same source to verify elevations.

I've contacted autel support also and they are looking into it.

Now for the PPK question i have not and im not understanding the workflow for that. That may hold a key. I have read that somewhere there should be an option to select MSL for elevation rather than AGL. I'm wondering if the problem isn't being creating by the drone reading cars and the like and adjusting it's height.

 

[jahalnon]

Are you using ground control points to process your images?

 

[Jasono]

Are you using ground control points to process your images?

No im not. I use GCPs with my other 2 drones and have built 100's of models and orthophotos.

This is an issue unique to this drone whil using RTK

My accuracy is better vertically by using GPS and the models do not have this problem.

 

[jahalnon]

Sorry to hear that, must be specific to that unit. Other than the latest firmware update headache, our V2 has been pretty reliable. I have noticed a drift or fold so to speak of the final ortho along edges that did not have a GCP close by. But the elevations have been consistent with typical gps elevations.

 

[Jasono]

Sorry to hear that, must be specific to that unit. Other than the latest firmware update headache, our V2 has been pretty reliable. I have noticed a drift or fold so to speak of the final ortho along edges that did not have a GCP close by. But the elevations have been consistent with typical gps elevations.You

 

[Jasono]

So you use GCPs with an rtk unit?

 

[Jasono]

An interesting development.

Today a went to a location and did a double grid mission. Again no GCP's and this time my accuracy was excellent. I surveyed the location in 42 points and compared the Rover elevations with the drone elevations at the same point. There was an average difference of .1 feet. About an inch and a half. That is acceptable for what i'm doing and it leaves promise for the possibility of achieving the accuracy I expect. What I don't understand is why it worked.

Lets hope i can recreate the success

 

[jahalnon]

I have been a surveyor most of my life so traverse points and monuments are like oxygen to me. Every site we work on has good control, so some of those then become GCPs. The limited testing I did early on when I got the drone using RTK only was a mixed bag of success and troublesome data. So quickly I decided GCPs were the way to go and became our SOP. The more the better.

We use Carlson software products so their Photo Capture processes the images and GCPs to create the final ortomosaic and point cloud. We then use Carlson Point Cloud to process further.
Similar workflow with Pix4d would be my guess.

 

[jaja6009]

An interesting development.

Today a went to a location and did a double grid mission. Again no GCP's and this time my accuracy was excellent. I surveyed the location in 42 points and compared the Rover elevations with the drone elevations at the same point. There was an average difference of .1 feet. About an inch and a half. That is acceptable for what i'm doing and it leaves promise for the possibility of achieving the accuracy I expect. What I don't understand is why it worked.

Lets hope i can recreate the success

The Evo 2 RTK will have a vertical shift if you use just nadir images. I run all my missions double grid collecting all oblique and this removes the vertical shift.

If you want to use just nadir images, use the Altitude optimization feature where it adds one line of oblique images from the outside corner of the map heading to the center.

It has been proven by numerous members that you can obtain sub 6cm with just using RTK alone and validated with check points when using all oblique images or nadir images with the altitude optimization single oblique line.

 

[RPAerials]

Hello everyone,


I have an evo II pro RTK v3

I am using a custom base station with NTRIP caster by ublox.

I used my rover to survey varius point along a block such as in street, on curb, in gutter et...

Now when i fly my autel evo II (Which i just purchased i see a bowl effect from the take off point. There is areound a foot of fall to the south and about the same rise to the north. When i process the images i see 10 or more feet of rise in both directions.

I see that somewhere there should be a way to set the drone to MSL vs AGL for mapping but i only see that option under slope.


Please Help with any idea

I am using open drone mape to process the images

Bowl effects on the point cloud can also be a camera calibration issue. ODM conducts an auto calibration —but has a "best practice" for self calibration to help out the software.

Essentially flying a double grid—first pass low obliques, second cross pass nadir at a different altitude.

 

[WV RAM]

So you use GCPs with an rtk unit?

Always use GCPs.

The goal using RTK corrected photos is to need less GCPs and still build an accurate ground model.

Without GCPs you can’t check the model into your ground control survey horizontal and vertical datum translations.

In theory, with RTK or PPK corrected positions tagged to your photos, each photo becomes an independent GCP of sorts.

Generally, sea level elevations is what the client wants the final ground model mapping product delivered in. There are multiple ways to get there.

Using GCPs has remained a consistent method to match the client’s on-site survey control.

All other methods are dependent on your knowledge of the Vertical Datum(s) used to control that site’s sea level elevation offset from-to the WGS-84 Ellipsoid Height Datum.

This is where the magic really happens with RTK or PPK data.

Im pretty confident the
DJI AGL FLIGHT ALTITUDE is developed in the drone using a barometric pressure sensor.

I’m not sure sure yet what the Autel EVO RTK uses?
If RTK Elevation overrides the barometric pressure sensor?
If Autonomous GPS elevation is used when no RTK corrections are available.
Is barometric sensor used?

Unless you are a believer in the Flat Earth Theory, there is curvature in all level lines. This is due the natural spherical shape of the earth.

In the United States,
the general rule is that a level line curves downward about a 1/4” per mile in any single direction.

The out of LEVEL drift you are seeing in the Flight Photos from your drone are most likely caused by the drone’s barometric pressure sensor or the geodetics controling the shape of the WGS-84 Ellipsoid determined by your actual latitude and longitude.
That’s why we use GEOIDS to roughly correct Ellipsoid Elevations to local sea level elevations.

And, that’s why GCPs fix that rough translation to the Local Site - Vertical Datum Sea Level Elevation.

No measurement is absolute in
Surveying or 3D mapping.