I have a control point in State Plane coordinates that I want to convert to lat/long so that I can input it into the RTK base station. I think I've got the Northing/Easting to lat/long figured out but am not totally confident with the elevation conversion.
The point of interest is:
Texas South Central (4204)
N: 13809425.05
E: 3157105.66
ELEV: 33.62 ft US

I believe I've converted it correctly to
Lat: 29.6679268124
Long: -95.2564980031

I plugged that into the GEOID calculator above (thanks @patiam) to get a GEOID12B value of -27.222 meters. My understanding is that Ellipsoid Height + Geoid Height = Ortho Height. So plugging in the numbers gives 10.25m (that is 33.62 survey ft converted to meters) - (-27.222m) = 39.274m for my ellipsoid height.

Does that look correct?

(Obviously I still need to add the Antenna Phase Center value and pole length to that.)

dronie326 Posted at 2-28 08:15
I have a control point in State Plane coordinates that I want to convert to lat/long so that I can input it into the RTK base station. I think I've got the Northing/Easting to lat/long figured out but am not totally confident with the elevation conversion.
The point of interest is:
Texas South Central (4204)

Hi Dronie-
So we're in Houston, eh?

Assuming your Lat/Lon conversion from Sate Plane is correct (you specified the correct datum, for example)., your Z calculation is valid ASSUMING that the control point elevation you started with is indeed the NAVD88 Ortho height based on the GEOID12B model. If so, then your math checks out. [ETA- derp - see post #45 below, there is a sign error here I did not catch initially]

But if the original elevation is tied to a different vertical datum (such as NGVD29), or NAVD88 but based on GEOID99 or another type of model altogether, then backing out the GEOID12B value (after converting the initial elevation to meters) to get to Ellipsoid Height is not valid. It will probably be close, but only correct if the assumptions above in bold are true.

If not, you need to find and apply the appropriate correction/offset to get from whatever vertical datum you're starting with to HAE.

Make sense?

patiam Posted at 2-28 09:15
Hi Dronie-
So we're in Houston, eh?

Houston indeed

The control point elevation is NAVD88 but something doesn't seem right.
1. The RTK base wont let me enter that value (37.372m) because it says the point is beyond the 50m distance of where the RTK base thinks it is.
2. Does it make sense that the ellipsoid height would be higher than the ortho height? I was assuming it would be a smaller value but I guess that just depends on location.

Going off #2 above I tried subtracting it instead.
Geoid Height - Ortho Height.
27.222m - 10.25m = 16.972m

The RTK base lets me input that number successfully. BUT I then get an error saying "Cannot Takeoff - Weak RTK Signal"

I guess there is a chance like you mentioned that its not based on GEOID12B. Is there any way to determine this? I have the topo map of the point(s) with all of the information but it doesn't reference GEOID anywhere. I just assumed 12B.

dronie326 Posted at 2-28 10:26
Houston indeed

The control point elevation is NAVD88 but something doesn't seem right.

Aw snap. I didn't scrutinize yer math closely enough. We had sign issues.

As you seem to have figured out, Orthometric height = GPS Ellipsoidal Height - Geoid Height (that's MINUS not PLUS)

So 10.25m = HAE - (-27.222m)
10.25m +(-27.222m) = HAE
-16.972 = HAE

Try that. Sorry for not catching the issue before.

HAE is generally lower than NAVD88 in CONUS, as you mentioned.
Regarding the weak RTK signal that shouldn't have anything to do with the station coordinates you entered, that has to do with the site itself and obstructions, radio noise, etc.
Is the weak signal on the bird or base? Try moving the bird's takeoff position around? I dunno.

dronie326 Posted at 2-28 10:29
I guess there is a chance like you mentioned that its not based on GEOID12B. Is there any way to determine this? I have the topo map of the point(s) with all of the information but it doesn't reference GEOID anywhere. I just assumed 12B.

If it is a published benchmark then you should be able to look up the metadata (they may even list the EL Hgt).
If it's a one-off done by some independent surveyor, you'll need to contact whoever did it or find the technical report associated with it or something in order to find out.

patiam Posted at 2-27 11:53
Update on the NTRIP-corrected flight accuracy reported earlier:

I added about 35 Total Station shots to the accuracy assessment of our Jan 28 calibration flight. In GIS I compared the Z from the shots vs that of the DSM produced by Pix4D.

Patiam - would you please PM me with an email address so I can send a couple snips.  The base, drone,RC are all working great but I can't seem to get point cloud output in local state plane in P4D.

HTA_RP-1 Posted at 2-28 11:57
Patiam - would you please PM me with an email address so I can send a couple snips.  The base, drone,RC are all working great but I can't seem to get point cloud output in local state plane in P4D.

PM sent.
<junk to make 10 char limit>

patiam Posted at 2-28 10:45
Aw snap. I didn't scrutinize yer math closely enough. We had sign issues.

As you figured out, Orthometric height = GPS Ellipsoidal Height - Geoid Height

Ahh, ok I'll try that out. One thing I can't help but notice is that the aircraft when sitting right next to the control point shows an elevation of 14 when you look at the RTK settings page. So +16 sounds like it would be correct. Should these values be similar or is that purely coincidence?

Perhaps I should just drop this here...

patiam Posted at 2-28 14:12
Perhaps I should just drop this here...
[view_image]

On the "cannot Takeoff - Weak RTK Signal"  I have found that a reboot of the P4 and subsequent reconnect has worked.  


And I completely missed the 2nd page discussion which readdressed the same issues I have had with setting base heights to get georeferenced point clouds. I will test again!   Safe Flying!

HTA_RP-1 Posted at 3-1 03:44
On the "cannot Takeoff - Weak RTK Signal"  I have found that a reboot of the P4 and subsequent reconnect has worked.  

You too!

We did an NTRIP flight this morning and one with the D-RTK 2. For the latter we added the 1.802m antenna height to our HAE Z value for the base coords.

Flights went well, I'm processing the NTRIP one now.

patiam Posted at 3-1 12:43
You too!

We did an NTRIP flight this morning and one with the D-RTK 2. For the latter we added the 1.802m antenna height to our HAE Z value for the base coords.

NTRIP flight yielded comparable accuracy to last time but WITHOUT the need to introduce the mysterious ~84cm fudge-factor I had to use on last flight.

~1-2cm XY and 2cm Z accuracy.
As for reasons the offset was needed last time and not this time, maybe the FW update we did between flights fixed something, or perhaps the results are inconsistent and we got lucky this time, or who knows what?
Now to look at the D-RTK 2 flight...

Hello patiam and others,

I've been testing the base setup with the P4 RTK and have not yet come up with a good workflow.  I have at least 5 good flights in that I've double checked everything possible and I'm coming up with various Z value errors.  I'm adding this info into what's available here but don't yet have answers other than to always have some control points around your project site that you can adjust the data to in the vertical component.

I've spoken to HTA-RP-1 by email and phone and appreciate the heads up about this forum.  Thank you!!

My workflow so far is to measure my base point and checkpoints with an RTK Network GPS rover connected to Leica's Smartnet.  I'm close enough to the reference station that I'm getting 1cm horizontal and 2 cm vertical accuracy levels on my measurements.  I am placing 4 - 5 ground marks (checkpoints)  on pavement in close proximity to my base station location.  The base station ground point is output in DD.DDDD format with the elevation value in meters.  My checkpoints are measured and output in state plane coordinates.  All elevation values are ellipsoid values.  I don't normally use ellipsoid values day to day but want to simplify the workflow as much as possible to avoid any errors.  
     
I enter the lat, lon and ellipsoid elevation value of the ground point into the controller and set it.  I confirm that the setting has taken and normally take a screenshot of the RTK settings on the controller.  I am not adding any offset values (for rod height) when entering the info into the controller.  I've then flown a simple mission at both 80 metes and 92 meters at two different locations multiple times.  All other settings for the flight are configured the same.  The only difference is the height above ground that the drone flies the mission.  I have 5 flights so far with 3 at 92 meters and 2 at 80 meters and my Z error value is different for each flight but very consistent among checkpoints with a single flight.  I have multiple additional flights that I've tried to add various rod height valued to the ground elevation when entering into the controller but they did not result in anything consistent or recognizable as why the Z value is not correct.  My Z error value is very consistent for all checkpoints within a flight.   

I've been flying other brand RTK drones for close to 2 years and am very familiar with the workflows required.  I am not a surveyor by trade but work with them regularly and have a variety of RTK GPS equipment that I can use to independently verify my workflow and measurement values.  I plan to test further and will update my findings on this forum.  Any advice or suggestions are welcome.  

Thanks!!

ewischropp Posted at 3-10 15:53
Hello patiam and others,

I've been testing the base setup with the P4 RTK and have not yet come up with a good workflow.  I have at least 5 good flights in that I've double checked everything possible and I'm coming up with various Z value errors.  I'm adding this info into what's available here but don't yet have answers other than to always have some control points around your project site that you can adjust the data to in the vertical component.

hi ewischropp-

Sounds like you're doing everything right. I will say that even though it seems like a static offset that should be able to be added in real time or after the fact, incorporating the antenna height offset into the Z value for your D-RTK 2 base station coordinates is important for best results.
We don't have enough flights in enough places to establish if there is or is not a repeatability issue with the P4P RTK... but so far we've been able to get within a few cm in XY&Z pretty reliably on our test site, for which we have very good ground control (~40 GCPs we are using as checkpoints only, not for georeferencing during processing).

patiam Posted at 3-10 19:50
hi ewischropp-

Sounds like you're doing everything right. I will say that even though it seems like a static offset that should be able to be added in real time or after the fact, incorporating the antenna height offset into the Z value for your D-RTK 2 base station coordinates is important for best results.

Thanks patiam,

I'll review the postings and try a few flights adding in about 1.803 meters to my ground measurement for the coordinate value to input into the controller.  

eric

patiam Posted at 2-27 11:53
Update on the NTRIP-corrected flight accuracy reported earlier:

I added about 35 Total Station shots to the accuracy assessment of our Jan 28 calibration flight. In GIS I compared the Z from the shots vs that of the DSM produced by Pix4D.

Hi patiam,

Thank you for describing your coordinate system workflow. You say you are using height above ellipsoid when you set up the D-RTK 2 base station over the top of a surveyed benchmark. My question is: what vertical coordinate system do you think the Phantom is recording height in? In the exif metadata of an image, they have latitude, longitude, and height above sea level. Perhaps, 'height above sea level' actually means height above ellipsoid in this case. Perhaps DJI is being lazy about terminology. This would make sense because GNSS normally uses HAE.

fans2f149175 Posted at 3-29 11:05
Hi patiam,

Thank you for describing your coordinate system workflow. You say you are using height above ellipsoid when you set up the D-RTK 2 base station over the top of a surveyed benchmark. My question is: what vertical coordinate system do you think the Phantom is recording height in? In the exif metadata of an image, they have latitude, longitude, and height above sea level. Perhaps, 'height above sea level' actually means height above ellipsoid in this case. Perhaps DJI is being lazy about terminology. This would make sense because GNSS normally uses HAE.

Hi fans2f149175,

Regardless of what it is labeled, when I tell Pix4D that the altitude is in HAE and then apply the GEOID12B height to get to NAVD88, my surface model is within a few cm of my independently-measured checkpoints, so unless there's some math going on that I don't know about then it's HAE.

I just got a P4RTK and have to say thank you all very much for your contributions on this thread as it is very helpful, particularly with adding the antenna height to the base station coordinates.  
I am in the middle of testing workflows with Pix4D and it seems that my best workflow so far is to apply the geoid height correction in meters to the photos on import when selecting the image coordinate system.  I can then bring in my control points into Pix4D in state plane (x,y) and orthometric heights in NAVD88 (z) in feet (my case international feet) which is what I want my output coordinate system to be.  I also did it by leaving the photos in geoid height above ellipsoid at 0 and importing my control points in state plane but with ellipsoid heights for the z and then adding the geoid height above ellipsoid to bring it to the NAVD88 datum.  Both ways accomplish the end goal, I'm not sure which way would be better.

HTA_RP-1 Posted at 2-13 11:22
A previous workflow by a surveyor in TX stated to add 5.83 ft or 1.776984m to the benchmark z value that you are set up over to account for the antenna height.  I am still working towards getting a reliable consistent workflow from the DRTK2 and P4RTK when set up over a known point.

Me too.  I found using an NTRIP custom network to be smoother.  If one is available to you i recommend it

patiam Posted at 2-27 11:53
Update on the NTRIP-corrected flight accuracy reported earlier:

I added about 35 Total Station shots to the accuracy assessment of our Jan 28 calibration flight. In GIS I compared the Z from the shots vs that of the DSM produced by Pix4D.

It's the most smooth reliable way to go

Just thought I'd update this thread since it has been some time since I reported on our continuing effort to develop a workflow and test the accuracy of the P4P RTK. We've got enough flights in to get a better feeling for how the system performs.

Unfortunately, while we have continued to enjoy great (1-3 cm) XY precision and accuracy, that is not at all the case for Z.  As @ewischropp reported, within-flight vertical precision is quite good (that is, for a given flight elevations are internally consistent). But between flight precision and accuracy are unacceptable. Doesn't matter whether we use NTRIP or the D-RTK 2, we're seeing up to 0.8m DSM elevation departures between consecutive identical flights, and up to 1.3m differences between the DSM and known surveyed Z at our checkpoints.

As with any inaccurate and imprecise system, sometimes you get lucky and the results are spot-on. But it's a crap shoot, and short of having GCP's and/or check points, you have no way to know what you ended up with. And not needing those points, or only needing few or infrequent ones, is kind of the whole reason for RTK.

That and the issue with the D-RTK 2 not accepting the correct benchmark position for the base keep the P4P RTK well short of living up to the marketing hype. Really had hoped for better from this system.

Appreciate the update there @patiam. Will go back to my Klau geomatics system which works a treat and goes on the M200 which is nice. Maybe DJI will sort this out eventually but I wont hold my breath.

Great thread guys.  I am a registered surveyor in Australia, and familiar with QA of of data in a practical sense.  I have been using the P4PRTK  for  a few months and agree with patiam that it is a crap shoot...

I purchased Klau geomatics software which was written for the P4PRTK drone and it is magic to use, but I am getting the same spread of vertical errors, up to 1.2m between flights 2 hours apart.  On a large area I am getting a 'tilt' effect on the project, with the vertical error possibly running at 200mm over the 15 minute flight time.  Not good.  It seems to me that the vertical component stays in float, and never gets to a fix.

I use Metashape for my reductions.

patiam Posted at 2-22 13:15
Very early for any real results yet.

Still trying to figure out a systematic offset, but when that is applied, about ±0.10m RMSE.

When we get RTK correction from CORS system reach 3 cm RMSE in horizontal and 15 cm in vertical direction.
In order to reduce vertical RMSE below 10 cm, we use 5 GCP and improved our final results for 2 SqKm.

@jivago what altitude are you flying? we get great results around 40m AGL but at 80m AGL we're looking at 50-150cm error which is not acceptable. Seems like camera calibration is needed, since the error appears to be correlated with altitude...  

patiam Posted at 6-2 19:53
@jivago what altitude are you flying? we get great results around 40m AGL but at 80m AGL we're looking at 50-150cm error which is not acceptable. Seems like camera calibration is needed, since the error apperas to be correlated with altitude...

I flight at 120m above ground.

yes that matches our experience, sort of. low altitude flight yields great results. higher not so much. although your results @jivago are better than ours at similar altitudes.
please see latter part of the accuracy and precision thread for more discussion of the need for custom camera calibration or some other solution.

Once you have input the base coordinate , how do you actually delete them

I am a surveyor in Austrian - and we have the same Problem with the accuracity of the Z-Value when using the Base Station - x,y, is perfekt but the lack of DJI in offering support is horrendous - you cannot but in the Antenna height, you cannot account for any other Koordinatesystem than WGS84 in lat and Long - if i could enter my Austrian koordinatesystem with the correct height i would not have to account for  the GEOID difference and so on.

i mean the System cost 7000 € i was not expecting that it is perfect, but as it is now the base Station is completely useless, when surveying in the mountains for example i get Z-Errors up to 3 Meters, i still have to use a lot of GCP, why should i use the base then.

This is a really helpful thread.  I'll apologize that I'm going to ask a very basic question:  Assuming that we have the known coordinates (including antenna height or HAE) of the D-RTK 2 base station, where in the DJI GS RTK app does one input them?   A couple of others:
1.  If the base station is not over a known point, is there a particular length of time for the base station to sit on station in order to get a reasonably consistently-accurate fix?
2.  Does the base station store its location data, and is there a way to download that data for correction in something like OPUS?   If that's possible, then it would seem that you could enter that corrected position data in the same way that you can enter it if you place the base station over a known fix.  Right?

Thanks to all you tech-savvy and GIS-savvy experts for pointing the way for us neophytes!

jdzac Posted at 7-18 13:15
This is a really helpful thread.  I'll apologize that I'm going to ask a very basic question:  Assuming that we have the known coordinates (including antenna height or HAE) of the D-RTK 2 base station, where in the DJI GS RTK app does one input them?   A couple of others:
1.  If the base station is not over a known point, is there a particular length of time for the base station to sit on station in order to get a reasonably consistently-accurate fix?
2.  Does the base station store its location data, and is there a way to download that data for correction in something like OPUS?   If that's possible, then it would seem that you could enter that corrected position data in the same way that you can enter it if you place the base station over a known fix.  Right?

You enter the known coordinates of the base station Under RTK Settings>Advanced Settings>GNSS Coordinate Input. As you noted, you must include the antenna phase center height above the point on the gound in the altitude (Z) you enter.

• How long is a piece of string? But seriously, the longer the better, up to a point. Not less that 15 minutes and probably better to go an hour or more. You can watch the STD to see when it stops improving significantly. It's always going to be better to use a vetted, known set of coordinates than the on-the-fly solution from the D-RTK 2.
• That's supposed to be a functionality offered by the D-RTK 2, just like every other RTK Base station out there, but DJI offers absolutely zero documentation on how to do it and AFAIK nobody has cracked that nut yet. We generally use a "real" RTK unit to do exactly what you describe- log at least 15 minutes of data to a RINEX file, wait for the UTC day rollover, and upload to OPUS for rapid-static processing. The report we get back from OPUS has the coordinates for us to input into the D-RTK 2.
  

Remember you can also connect to a nearby NTRIP caster for corrections if you have access to one that is within 10 km or so. If you use an NTRIP provider you don't need to enter coordinates for the D-RTK 2.


Also take a look at the attached unreleased "user manual". It explains some of this in more detail than the one that ships with the product. It also sketchily describes how to get into "Mode 3" and some silly methods for using the P4P RTK as a mobile to find the coords of your benchmark. I haven't spent any real time at it, but "Mode 3" would allow you to use the D-RTK 2 as a mobile (with corrections supplied by an NTRIP caster or another D-RTK 2) so that you could get precise coordinates for benchmarks or other features. This is a functionality that was advertised but once again I haven't seen any reports that anyone has actually made it work.

Have fun & safe flying!

patiam Posted at 7-19 08:47
You enter the known coordinates of the base station Under RTK Settings>Advanced Settings>GNSS Coordinate Input. As you noted, you must include the antenna phase center height above the point on the gound in the altitude (Z) you enter.

Thanks, Patiam.  That's really helpful.  I have used an NTRIP (CORS) correction system, but I'm right on the edge of two different stations, so I can get a correction signal MOST of the time, but it's not 100% reliable.  It would be great to have one rock-solid, reliable solution.  But at least where I am (just south of Charlotte) there doesn't appear to be one.  Thanks for all your insights to this thread.

jdzac Posted at 7-19 11:18
Thanks, Patiam.  That's really helpful.  I have used an NTRIP (CORS) correction system, but I'm right on the edge of two different stations, so I can get a correction signal MOST of the time, but it's not 100% reliable.  It would be great to have one rock-solid, reliable solution.  But at least where I am (just south of Charlotte) there doesn't appear to be one.  Thanks for all your insights to this thread.

Let me run another idea by you:  Would it be accurate to put a Propeller Aero Point down at the location where you'll put your D-RTK 2 base station, and do the same thing (but within the Propeller ecosystem) that you describe using the "real" RTK unit?  My understanding is that Propeller corrects the Aero Point data with either PPK or similar process, then sends you back the corrections (haven't purchased them yet, so not quite clear on exactly how this process works).  So could you take that corrected data and enter it into your D-RTK 2 base station?

jdzac Posted at 7-19 11:25
Let me run another idea by you:  Would it be accurate to put a Propeller Aero Point down at the location where you'll put your D-RTK 2 base station, and do the same thing (but within the Propeller ecosystem) that you describe using the "real" RTK unit?  My understanding is that Propeller corrects the Aero Point data with either PPK or similar process, then sends you back the corrections (haven't purchased them yet, so not quite clear on exactly how this process works).  So could you take that corrected data and enter it into your D-RTK 2 base station?

Sure! I'm familiar with Aeropoints but have never used them... Do they give you the Z value for the ground underneath their center, or the top surface of the unit (I'm guessing the latter, given that you're supposed to use them as GCPs)? If its for the upper surface you'll want to account for it (subtract the thickness of the unit) or have the unit in place and put the pointy end of the D-RTK 2 pole on top of it...

patiam Posted at 7-19 13:42
Sure! I'm familiar with Aeropoints but have never used them... Do they give you the Z value for the ground underneath their center, or the top surface of the unit (I'm guessing the latter, given that you're supposed to use them as GCPs)? If its for the upper surface you'll want to account for it (subtract the thickness of the unit) or have the unit in place and put the pointy end of the D-RTK 2 pole on top of it...

I apologize for the delayed reaction, but just wanted to say Thanks, Patiam.  You're an invaluable resource.  Hope to be able to gain the knowledge and experience to pay it forward in the future.

I apologize for the delayed reaction, but just wanted to say Thanks, Patiam.  You're an invaluable resource.  Hope to be able to gain the knowledge and experience to pay it forward in the future.

Glad to help. Let us know how it goes.

Your avatar- Clemson?

We have tested P4 RTK over 3 projects; our data processor concluded that for highest grade survey accuracy, it is recommended for DJI Base RTK to use at least 7 GCP’s, and if using another survey equipment for PPK post processing method to then use at least 5 GCP’s. That seems like a lot, but necessary to GUARANTEE accurate and reliable elevations; can use less GCP’s and get sub-cm Z accuracy, but can’t be confident if it’s reliable.
We will keep using our survey grade Altus-PPK system and only use DJI base for further comparison testing maybe. Basically DJI Base Station is not particularly helpful – unless – as patiam mentions - we can access the raw data from DJI Base, and/or activate the mysterious “Mode 3” (which seems to imply that DJI base is survey-grade rover as well, which is fascinating).
That said, this drone is so much more reliable and flies better than anything I’ve ever used for survey in past, the mapping system and KML import capability are excellent, and I highly recommend it to the semi-pro or pro- surveyor who can manage the complex post-processing. I do NOT recommend P4 RTK for beginners or those with no ground-based survey experience.

patiam Posted at 7-19 08:47
You enter the known coordinates of the base station Under RTK Settings>Advanced Settings>GNSS Coordinate Input. As you noted, you must include the antenna phase center height above the point on the gound in the altitude (Z) you enter.

Would be good to set up base over known point for long time ; but how long the Base station can run is limited by WB37 battery life - only lasts about 45 minutes in DJI Base station in our experience so can't log or calibrate longer than that, might not be long enough for some applications.