Sur_veyor Posted at 3-17 13:44
Hi guillermomeiner,
Why is your base hight 2.01m? Are you not using standart rod(included with D-RTK)?

Sur_veyor Posted at 3-17 13:44
Hi guillermomeiner,
Why is your base hight 2.01m? Are you not using standart rod(included with D-RTK)?

because im using a standard tripod with adaptation i made   

guillermomeiner Posted at 3-18 12:20
because im using a standard tripod with adaptation i made

lol "standard" = real

patiam Posted at 3-18 15:22
lol "standard" = real

Sur_veyor Posted at 3-17 13:48
[view_image]

Something like this

guillermomeiner Posted at 3-19 04:47
Something like this
[view_image]

Cool. Do you have photo when it is on tribrach\tripod?

Sur_veyor Posted at 3-19 06:53
Cool. Do you have photo when it is on tribrach\tripod?

sure

guillermomeiner Posted at 3-19 10:31
sure[view_image]

thank you.

Thank you very much for providing valuable information through your experiences using DRTK 2.
I mention that I am using the DRTK 2 in mode 02 (static) to use the PPK method. I understand with .DAT files they are recorded approximately every 1 hour. My problem is that when updating the GPS firmware, it records the .DAT files every 3 min approximately. Generating many files, it is impossible for me to convert each one to RINEX and perform the merge.
* I have 103 .DAT files generated in approximately 3 hours of data collection in mode 02.
I hope someone helps me solve this problem.

fanse3badb5d Posted at 2019-6-3 04:51
Once you have input the base coordinate , how do you actually delete them

Sorry to rehash this topic, but has this question been answered?

I have the problem that I press "Reset" in the coordinate input tab, but the position of the station is still saved. So how can you delete the coordinates last entered without entering new ones ?!

Thank you for an answer!

patiam Posted at 2019-8-8 10:50
The D-RTK 2 can be powered by an external battery or AC power adapter. You're not limited to a single WB37.

That being said, we still generally site in our base location with another RTK GPS with which we can log at least 15 minutes of data, spit out a RINEX file, and send to OPUS for rapid-static or static processing. We use the coordinates from the OPUS report to enter into the D-RTK 2's setup for when we fly.

What antenna do you select when you are uploading to OPUS?

@AZGISP- good question! Never done it, so I'm not sure... Maybe a DJI mod will chime in with the answer (yeah right).

Es posible cambiar la altura de la base una vez hecho el vuelo. Lo que se tiene que hacer es extraer el archivo crudo de la base que tiene extension .DAT y cambiar la extensión por .RTCM3, convertirlo a rinex . En el archivo de observaciones puedes cambiar la altura de la antena y también las coordenadas geocéntricas. tienes que realizar un postproceso. anexo link de un video que tal vez pueda ayudar. https://www.youtube.com/watch?v=ckmyPVHW3OI&t=127s

Thanks @ing.maltamirano!
English translation (via Google):

"It is possible to change the height of the base once the flight is done. What you have to do is extract the raw file from the base that has a .DAT extension and change the extension to .RTCM3, converting it to rinex . In the observations file you can change the height of the antenna and also the geocentric coordinates. you have to do a post process. I attach a link to a video that may help. "

Great to see this thread, and not surprised to see Pat at the forefront.  We were going to acquire a P4P RTK but that went out of production it seems and we now have a Mavic 3M RTK.  We have some pretty significant accuracy needs since we're studying channel erosion where centimeters matter.  So we're planning to set up our base station over a benchmark which we'll establish coordinates for using an Eos Arrow Gold with CRTN, a setup which is providing us with sub-centimeter accuracy (our site has a very nearby California Real Time Network base station), and then use the drone itself as a rover to get coordinates for GCPs where we don't have cell service to use the Arrow.  It would be nice to just do without GCPs, but I'm not convinced we can get the accuracy needed for channel geomorph studies.  Some plans and things we need to figure out:

1. I figure we'll do a test comparison between Arrow and drone rover on GCPs where we do have cell coverage. We'll need to know the vertical offset between the drone RTK antenna and the target center, which looks to be about 0.14 m, assuming the RTK antenna center is just below the top of the plastic housing.

2. I'm assuming that the readout in the DJI Pilot 2 app will work for this, and if nothing else I could just manually record the coordinates in decimal degrees (assuming WGS 84) and HAE in m.  Our site is about 10 sq km, so a constant geoid height over that area should work to adjust that.

3. I'm assuming (and gathering from the discussion here) that the base station z value is for the antenna itself.  This fits with my backyard deck tests where the readout of the base station coordinates is higher in elevation by about a meter from the drone, sitting on the table below (by about a meter) the antenna on the pole beside me.  The vertical offset (I just measured ours to the closest mm as 1.795 m:  measured tip of rod to base of antenna shown below as 1.657 m + 0.138 m for L2) is just to add to a known benchmark height to enter into the RTK base station settings to get that established. Our base station came with a good tripod with a central hole to allow the rod to simply stand vertically, so that made it simple and consistent, not requiring an awkward tripod setup.


Jerry

JerryDavis Posted at 4-23 09:32
Great to see this thread, and not surprised to see Pat at the forefront.  We were going to acquire a P4P RTK but that went out of production it seems and we now have a Mavic 3M RTK.  We have some pretty significant accuracy needs since we're studying channel erosion where centimeters matter.  So we're planning to set up our base station over a benchmark which we'll establish coordinates for using an Eos Arrow Gold with CRTN, a setup which is providing us with sub-centimeter accuracy (our site has a very nearby California Real Time Network base station), and then use the drone itself as a rover to get coordinates for GCPs where we don't have cell service to use the Arrow.  It would be nice to just do without GCPs, but I'm not convinced we can get the accuracy needed for channel geomorph studies.  Some plans and things we need to figure out:

1. I figure we'll do a test comparison between Arrow and drone rover on GCPs where we do have cell coverage. We'll need to know the vertical offset between the drone RTK antenna and the target center, which looks to be about 0.14 m, assuming the RTK antenna center is just below the top of the plastic housing.

Hey Jerry!

Welcome to the fray. I wrote a long reply only to have the forum GUI glitch on me and lose everything I had typed. So here goes again.

• You're in good company, and of course have lots of experience and knowledge from your surveying backgroud already. There are quite a few folks on here that have written tons of great threads with lots of information on maximizing precision in phtogrammetry and LiDAR products. Most are friendly and helpful. Here's a great reply by @LV_Forestry that discisses your "use the aircraft as a rover" method, albeit w/ a P4 RTK. I don't now if anyone has made a 3D printer model for an M3E RTK bracket but it might be a good idea to fab one.
• Yup. I forget how many decimal places the Pilot 2 app displays, but as long as there's at least 7 that should be enough. And yes, they'll be WGS 84/HAE.
• Yes, you need to do the math yourself to add the APC Z offset to the Z of your benchmark, and enter that solved Z into the Pilot app. So pole height + antenna base to APC offset + benchmark Z in HAE meters. Now of course "real" survey-grade software GUIs generally have a separate box for you to enter (and save) the antenna height into, and then they do the math for you, but I guess DJI didn't bother to look around much or ask any actual surveyors how they should design their interface. That or they want to give us more chances to screw something up in the field that we'll have to discover and fix later. And don't get me started on the "Custom RTK Network" NTRIP connection lameness... In any event, with the original D-RTK 2 DJI said to use 0.1419 m (the L1 APC) as the base to APC offset, not the L2 APC value of 0.1379 m. Our pole is 1.660m from the pointy end to the base of the antenna. Adding 0.1419m to get to the antenna phase center as specified on the diagram and by DJI gives us 1.802m for our antenna height to be added to the BM elevation in RTK setup. Sounds like your pole is w/in a few mm of ours, and your antenna has the APCs more clearly labeled than the original did (see below). And as far as the tripod goes, not sure if you got the same ones we did, but the original is a POS and very much worth replacing. Many folks have created adapters to convert the proprietary helical threads on the lower end of the top half of the antenna pole for mounting on a tribrach or standard 5/8" thread so they can use a "real" tripod w/ optical plumb and legs that won't crumple.
  

Anyway, have fun & let us know how things go!

-p

patiam Posted at 4-26 11:23
Hey Jerry!

Welcome to the fray. I wrote a long reply only to have the forum GUI glitch on me and lose everything I had typed. So here goes again.

Thanks for those suggestions, Pat.  It's great to have knowledgeable folks to work with, especially since neither the vendor nor the manufacturer is providing the essential documentation we need.

From our tests on campus, it's looking like using the drone as rover is going to work, though I'll do some more tests with better sky views and no multipath issues from buildings (we have a rooftop weather station).  The variation on the method from LV_Forestry is instead of taking a picture with the drone and getting it from the exif data, I've just taken a picture of the dji Pilot 2 display and manually recorded the data (for the small number of points we're collecting, that takes less time, as long as we're careful.)  It displays to 9 decimal places to the right, so that's 1e-9 degrees, which is about 1.11e-4 m, so 0.11 mm, so that should do it.

I'm annoyed that the D-RTK2 (or maybe it's the dji Pilot 2 app?) doesn't let you set to ortho elevation, so  that means that the coordinates stored in the exif will presumably use HAE.  I guess that can probably be dealt with in Pix4D, but it means that everything this drone collects will be different from what we collected before, so we'll just need to make sure not to get confused.

However, I'm wondering about updating the base station coordinates using ortho elevations instead of HAE.  For our project area, we were already planning to enter coordinates for the two benchmarks we use, since we can get those to sub-centimeter accuracy with our Eos Arrow Gold connected to the CRTN (which has a very close base station on a mountain visible from our site), and dji Pilot 2 does allow you to save these as frequent points so we don't have to enter those in each time.  I'm just not sure whether the RTK system will have a problem handling that.  

It's not just Pilot2, GS RTK also expects HAE. Our workflow in Pix4D has been developed around entering HAE instead of Ortho height for the base, and applying the Geoid in Pix or later. Everything is always going to be asumed to be HAE so it just makes sense to use that for the APC Z as well. I'd like to work in UTM/Ortho height from the start but its no big deal not to.

Some folks have played with entering Ortho instead of HAE for the base, I don't recall how that turned out. If you try it, let us know how it goes!

patiam Posted at 4-27 11:47
It's not just Pilot2, GS RTK also expects HAE. Our workflow in Pix4D has been developed around entering HAE instead of Ortho height for the base, and applying the Geoid in Pix or later. Everything is always going to be asumed to be HAE so it just makes sense to use that for the APC Z as well. I'd like to work in UTM/Ortho height from the start but its no big deal not to.

Some folks have played with entering Ortho instead of HAE for the base, I don't recall how that turned out. If you try it, let us know how it goes!

I reckon we can just work with HAE.  Just need to make sure everyone knows it on our team -- it's always challenging having to train up new team members.  

I did try out the 'take a photo with the drone' way of capturing the coordinates for our drone-as-rover, and the .MRK file is probably the easiest to deal with, e.g. DJI_202304271329_001_Timestamp.MRK is the file I looked at, it includes our coordinates for the top of our student union with z in HAE 37.72252487,Lat        -122.47863438,Lon        24.434,Ellh.

For the Mavic3M at least, that file (and some PPK files) are stored with the color *_D.JPG, maybe an index *_F.jpg, and 4 TIFF bands.  The .MRK file also retains the coordinates that are removed from the Jpg files when copied to my computer -- guess that's some privacy setting getting in the way.

JerryDavis Posted at 4-27 13:45
I reckon we can just work with HAE.  Just need to make sure everyone knows it on our team -- it's always challenging having to train up new team members.  

I did try out the 'take a photo with the drone' way of capturing the coordinates for our drone-as-rover, and the .MRK file is probably the easiest to deal with, e.g. DJI_202304271329_001_Timestamp.MRK is the file I looked at, it includes our coordinates for the top of our student union with z in HAE 37.72252487,Lat        -122.47863438,Lon        24.434,Ellh.

You can also use Pix to export the exif data from a directory of images to a file, rather than finding the data in the MRK. Or use the uasimg R package, or Exiftools,or, ...

We follow thestandard Pix workflow as far as setting input image coordinates to GCS WGS84/HAE and output coordinate system to UTM/NAD83(2011) applying a Geoid height to the output elevation under "Advanced>Geoid Height Above the Ellipsoid" (of course this is only really needed when you're not using GCPs, if your GCPs have ortho Z... but we do it regardless).

BTW have fun w/ CRTN and their weird NAD83(2011)(epoch2017.5) or whatever is is these days.... I love CRTN and dynamic datums really seem to be the way to go (especially in CA) but few geospatial applications are set up to deal with them.

patiam Posted at 4-27 14:18
You can also use Pix to export the exif data from a directory of images to a file, rather than finding the data in the MRK. Or use the uasimg R package, or Exiftools,or, ...

We follow thestandard Pix workflow as far as setting input image coordinates to GCS WGS84/HAE and output coordinate system to UTM/NAD83(2011) applying a Geoid height to the output elevation under "Advanced>Geoid Height Above the Ellipsoid" (of course this is only really needed when you're not using GCPs, if your GCPs have ortho Z... but we do it regardless).

Wow, I'm now thinking that we've been doing our GCPs wrong, or at least making the wrong assumption. Our GCP elevations have all been ortho elevations, but it *seems* from this Pix4D documentation and what you've said that the assumption is that these have been HAE.  Though I guess the DSMs and DTMs it has created are in the same coordinate system as the GCPs, so ours would be ortho/MSL, since we haven't specified a geoid height.  So that's ok.

But going forward with this RTK unit that works in HAE, we'll want to enter the Geoid height for our site into Pix4D.  Then our output should be in ortho elevations. I'll probably watch their video and do some testing to make sure we have it right.  

In my experience (I've done a lot of leveling surveys for cross sections and other profiles), while the math is extremely simple -- adding and subtracting -- elevation measurements are really easy to screw up, since it's easy to make a mistake, subtracting when you should be adding, etc.  And the use of a pole-mounted antenna adds to the likelihood of screwing up, and there you may not realize it (in contrast to the much larger error possible with datum assumptions.)

Ah yes, sign issues... Always look for an error that is twice your offset!

JerryDavis Posted at 4-23 09:32
Great to see this thread, and not surprised to see Pat at the forefront.  We were going to acquire a P4P RTK but that went out of production it seems and we now have a Mavic 3M RTK.  We have some pretty significant accuracy needs since we're studying channel erosion where centimeters matter.  So we're planning to set up our base station over a benchmark which we'll establish coordinates for using an Eos Arrow Gold with CRTN, a setup which is providing us with sub-centimeter accuracy (our site has a very nearby California Real Time Network base station), and then use the drone itself as a rover to get coordinates for GCPs where we don't have cell service to use the Arrow.  It would be nice to just do without GCPs, but I'm not convinced we can get the accuracy needed for channel geomorph studies.  Some plans and things we need to figure out:

1. I figure we'll do a test comparison between Arrow and drone rover on GCPs where we do have cell coverage. We'll need to know the vertical offset between the drone RTK antenna and the target center, which looks to be about 0.14 m, assuming the RTK antenna center is just below the top of the plastic housing.

Hi Jerry,
To complete the discussion started with Pat, I attach to this post the 3D files to print the "base station" of the M3.

For the coordinates of the images, before I recorded them manually as you suggest, but what a waste of time!
Now I put them in Metashape then save the metadata. It takes less than a minute, there is no possibility of copying error, precision data are included for all 3 axes, the altitude is corrected according to the desired geoid. All you have to do is open the file in the references and create the GCPs, which takes less than 10 seconds.

After the hard part remains to be done, if the quality of the RTK is not good during the flight it will be necessary to replace the GCPs on each picture manually. It's long but the result is really great.

Before having a LiDAR worthy of the name I had to use this technique to carry out an erosion survey on a peatland for 2 years. The results are relatively conclusive but not at the level of a LiDAR.


M3E_GCP_Split.rar (81.57 KB, Down times: 2)

2023-4-28 Upload

Click on the file name to download attach
M3E_GCP.rar (65.01 KB, Down times: 1)

2023-4-28 Upload

Click on the file name to download attach

LV_Forestry Posted at 4-28 06:59
Hi Jerry,
To complete the discussion started with Pat, I attach to this post the 3D files to print the "base station" of the M3.

Thanks @LV_Forestry!

Jerry, I also just remembered that since you're using an M3M, you may want to check out LV_Forestry's posts regarding some weirdness in the P4M/M3M Red-Edge band...

Not an issue if RE and indices using it are not of interest to you, but worth checking out even if not. Someday I plan to do a side-by-side w/ our Altum & P4M to see if I get similar results. Our P4M hardly gets used...

I thought I'd try to confirm that the base station coordinates are for the antenna itself, not offset by 1.8 m to be the benchmark below, and figured the way to test it was to put the base station antenna and an Eos Arrow Gold with CRTN RTK in use, with ~1 cm accuracy, side by side on my back deck with good GNSS conditions.  What I found was:
a.        The aircraft and base station tend to stay consistent together, presumably because RTK is already in effect.  This probably answers the question, since it appears that the base station is not offset vertically by anything like 1.8 m.
b.        The Eos Arrow Gold differed by about a cm between tries.  No surprise, given the CRTN RTK it uses and a CRTN base station is relatively close (20 km).  The horizontal difference is just because I didn't put the antenna down in exactly the same point on the railing, but the vertical difference should be reliable given the horizontal railing.
c.        There's a big difference between the base station and Eos Arrow Gold, both horizontally (though there should be ~0.2 m difference anyway, since the antennas were separated about that far) and vertically, with different tries being 0.35, 2.01, 4.51, and 3.04 m vertically.  Horizontally they may be up to ~2 m off.  

So my conclusion is that adjusting the base station coordinates is pretty important if you're wanting even decimeter accuracy in the drone images.

Follow-up:  repositioned the Eos Arrow Gold on the exact same point as the base station had been in, and derived new errors.  Didn't change the basic results, just provides a better view of horizontal error.

JerryDavis Posted at 6-7 10:41
I thought I'd try to confirm that the base station coordinates are for the antenna itself, not offset by 1.8 m to be the benchmark below, and figured the way to test it was to put the base station antenna and an Eos Arrow Gold with CRTN RTK in use, with ~1 cm accuracy, side by side on my back deck with good GNSS conditions.  What I found was:
a.        The aircraft and base station tend to stay consistent together, presumably because RTK is already in effect.  This probably answers the question, since it appears that the base station is not offset vertically by anything like 1.8 m.
b.        The Eos Arrow Gold differed by about a cm between tries.  No surprise, given the CRTN RTK it uses and a CRTN base station is relatively close (20 km).  The horizontal difference is just because I didn't put the antenna down in exactly the same point on the railing, but the vertical difference should be reliable given the horizontal railing.

Nice that you proved it to yourself... this has been established.

• Unless you enter precise coordinates into the D-RTK 2, you will get internally consistent results as long as it is not moved or turned off, but the real world accuracy will be decimeters at best. Often all that is needed is a simple shift, and a single GCP can provide this.
• The Z coordinate for the D-RTK 2 should be in HAE with the height of the APC included (ie if you have coordinates for the benchmark on the ground, you should add the APC height to its HAE).
• As you proably know, take care when using CRTN to account for their weird CSRS NAD83(2011) Epoch 2017.5 dynamic datum.
  

Have fun!

While I probably should know more about it, I'm going to need to learn about issues related to the CSRS NAD83(2011) Epoch 2017.5 dynamic datum.  I guess I figured we'd just use what it provides and everything will then be in that datum.  We do have some of our data in WGS84, so maybe we need to project one to the other?

JerryDavis Posted at 6-7 13:00
While I probably should know more about it, I'm going to need to learn about issues related to the CSRS NAD83(2011) Epoch 2017.5 dynamic datum.  I guess I figured we'd just use what it provides and everything will then be in that datum.  We do have some of our data in WGS84, so maybe we need to project one to the other?

You got it. It's just that one must be aware of their NTRIP CORS station's geodesy and account for it, of which you obviously were aware. And the particular complication with CRTN is that while their special datum totally makes sense (especially here in California where terra ain't so firma), it is far from a universally recognized standard and not all geospatial software knows about it yet (in fact the list of those that don't is longer than those that do). So you're often forced to reproject, sometimes by creating your own custom reprojection algorithm, or empirically determine offsets for your site or whatever.

http://sopac-csrc.ucsd.edu/index.php/epoch2017/
https://epsg.io/104644

https://eos-gnss.com/knowledge-b ... estions-and-answers

https://community.esri.com/t5/ar ... ch-2018/td-p/259532

https://gis.stackexchange.com/qu ... 3-in-arcgis-desktop

Of course if you never need to use data generated using CRTN with any that are in another spatial reference, you can just call it generic NAD83(2011) (epoch 2010.0) which is close, and it will all agree with itself.

Are we having fun yet?

We seem to have more and more of this kind of fun all the time...    And I remember the time when we first got a GPS with 1 m accuracy; thought we'd never need anything better.  

in my early days as a hydrographer, we could save an entire day's survey on a 1.44 MB 3.5" "floppy" disk (the name was silly b/c they were plastic unlike the original cardboard housings on 5 1/4" and larger disks, but I digress...)

Now even drives that read those disks are a novelty, and daily data volumes can be in the 10's or 100's of GB.

Face it man, we're OLD

Leaving the SRS NAD83(2011)(2017.5) issue for a moment, and returning to the D-RTK 2 best practices one...

Not including NTRIP and PPK, which both obviate the need for the D-RTK 2 completely, you have 2 basic choices w/ the D-RTK 2:

• Set up over a known benchmark and enter the precise coordinates into the software
• Set up w/o a benchmark, do not enter coordinates, and correct everything after the fact with a single pecisise measured GCP as in this workflow from Aerotas. They claim this method is more accurate and reliable than #1. I'm not sure I agree, but both definitely work.
  

And if you're concerned about precision & accuracy, it is a good idea to cllect at least a few checkpoints as well.

patiam Posted at 6-7 13:37
You got it. It's just that one must be aware of their NTRIP CORS station's geodesy and account for it, of which you obviously were aware. And the particular complication with CRTN is that while their special datum totally makes sense (especially here in California where terra ain't so firma), it is far from a universally recognized standard and not all geospatial software knows about it yet (in fact the list of those that don't is longer than those that do). So you're often forced to reproject, sometimes by creating your own custom reprojection algorithm, or empirically determine offsets for your site or whatever.

http://sopac-csrc.ucsd.edu/index.php/epoch2017/

Thanks for those links, Pat!  I think I'm getting closer, and might try that method of dealing with it later from a good GCP, but more likely will enter it in the field using the RTK adjustment process of dji pilot 2.  I'm inclined to just capture in California SRS Epoch 2017.50 (NAD83), and then specify that in Pix4D when starting up the project, using the .wkt .prj downloaded from https://epsg.io/104644.  

However, I'm a bit confused on what to do to get UTM zone 10 from this to use for GCPs in Pix4D. I've used a process of downloading these as a shapefile from AGOL (which ends up in web mercator but has the GNSS fields), then exporting the table from that in ArcGIS Pro, then using Display XY data to use the GNSS fields in that GCS.  I'm trying to project to UTM zone 10, and not sure how to specify the output coordinate system as UTM zone 10 in that geographic datum -- just offers NAD_1983_UTM_Zone_10N. And indeed when I do the projection with that setting, the Geographic Coordinate System shown is simply NAD 1983 (WKID 4269).  I reckon however that since no Geographic Transformation is shown, the GCS part will actually be in that California SRS Epoch 2017.50 (NAD83).  So if I use the Add XY Coordinates with it for use in Pix4D, it should be right.

JerryDavis Posted at 6-9 08:30
Thanks for those links, Pat!  I think I'm getting closer, and might try that method of dealing with it later from a good GCP, but more likely will enter it in the field using the RTK adjustment process of dji pilot 2.  I'm inclined to just capture in California SRS Epoch 2017.50 (NAD83), and then specify that in Pix4D when starting up the project, using the .wkt .prj downloaded from https://epsg.io/104644.  

However, I'm a bit confused on what to do to get UTM zone 10 from this to use for GCPs in Pix4D. I've used a process of downloading these as a shapefile from AGOL (which ends up in web mercator but has the GNSS fields), then exporting the table from that in ArcGIS Pro, then using Display XY data to use the GNSS fields in that GCS.  I'm trying to project to UTM zone 10, and not sure how to specify the output coordinate system as UTM zone 10 in that geographic datum -- just offers NAD_1983_UTM_Zone_10N. And indeed when I do the projection with that setting, the Geographic Coordinate System shown is simply NAD 1983 (WKID 4269).  I reckon however that since no Geographic Transformation is shown, the GCS part will actually be in that California SRS Epoch 2017.50 (NAD83).  So if I use the Add XY Coordinates with it for use in Pix4D, it should be right.

What GNSS are you using to capture the positions for your GCPs? That Arrow Gold unit? If you collect the GCP coordinates in UTM using NTRIP from CRTN, they'll already have the desired datum/spatial reference... Or am I missing something?

I used the Arrow Gold using CRTN RTK, so yes the data collected have that datum, but when downloading from AGOL the shapefile itself ends up in Web Mercator so I tend to use the esrignss* fields in the table instead of the shapefile geometry.  I guess I could instead project the shapefile, but I feel more confident in the esrignss fields, though maybe I'm missing something.
I'm also pondering the idea of going with not adjusting the RTK coordinates in setup, and just doing the adjustment in Pix4D, maybe in an analogous fashion to what @LV_Forestry uses in metashape, but I'm not figuring out how to do that.  In my recent test data, where I have 7 GCPs surveyed with the Arrow Gold CRTN, I tried setting just one as GCP (figuring that would be all that would be needed to do an offset), then use the rest as checkpoints. I'm assuming that using the RTK makes things internally consistent, so just doing an offset would take care of it.  But Pix4D isn't happy with being given just one GCP, so I think I need to figure out another way.


However, when I extract the Error to GCP Initial Position (m) for each of these points (see below), I'm not seeing evidence that the RTK actually resulted in internal consistency.  

id	dX	dY	dZ
SC5	-0.097	0.091	0.904
Subch8	-0.003	0.172	0.92
Subb21	-0.027	0.174	1.012
Subb22	-0.013	0.148	0.978
Subb24	-1.851	0.919	0.607
Subb25.1	-1.815	0.836	0.361
Subb25.5	-1.967	0.786	0.629

But given my recent posts about possible RTK connection issues, I'm not confident yet that it's not working.  I'm going to try a local test (of much less data so it doesn't take forever to process) before going up to the meadow.  

JerryDavis Posted at 6-11 10:33
I used the Arrow Gold using CRTN RTK, so yes the data collected have that datum, but when downloading from AGOL the shapefile itself ends up in Web Mercator so I tend to use the esrignss* fields in the table instead of the shapefile geometry.  I guess I could instead project the shapefile, but I feel more confident in the esrignss fields, though maybe I'm missing something.
I'm also pondering the idea of going with not adjusting the RTK coordinates in setup, and just doing the adjustment in Pix4D, maybe in an analogous fashion to what @LV_Forestry uses in metashape, but I'm not figuring out how to do that.  In my recent test data, where I have 7 GCPs surveyed with the Arrow Gold CRTN, I tried setting just one as GCP (figuring that would be all that would be needed to do an offset), then use the rest as checkpoints. I'm assuming that using the RTK makes things internally consistent, so just doing an offset would take care of it.  But Pix4D isn't happy with being given just one GCP, so I think I need to figure out another way.

Ah, you're using Field Maps/Collector or some other AGOL-based platform to record the data. Might look into alternatives that don't have to go through Web Mercator along the way... Cloud data collection is groovy and all but I'm not sure the benefits outweigh the costs here.

BTW the "1 GCP" method in that Aerotas workflow just uses the GCP to determine the needed shift to apply in post; as you mentioned, Pix wants >= 3 to use them in processing to georeference the project.

patiam Posted at 6-11 11:33
Ah, you're using Field Maps/Collector or some other AGOL-based platform to record the data. Might look into alternatives that don't have to go through Web Mercator along the way... Cloud data collection is groovy and all but I'm not sure the benefits outweigh the costs here.

BTW the "1 GCP" method in that Aerotas workflow just uses the GCP to determine the needed shift to apply in post; as you mentioned, Pix wants >= 3 to use them in processing to georeference the project.

Indeed, Field Maps is what we are currently using.  We used Collector before that, but really only recently for our more precise GNSS.  Before the Arrow Gold, we were using a Trimble GeoXH 6000 and post processing with Pathfinder and local base stations.  I actually preferred that, since it didn't require all the preparation before the trip, but it was clear that it was an archaic system.  

I don't actually know about alternatives to something like Field Maps for use with the Eos Arrow Gold.  And also one advantage of the AGOL cloud is that it works pretty well for our team, and I'm often cycling in students who are learning the ropes.  They're also used to using Field Maps for the Arrow 100, Trimble R1, and integrated GPS in the phone.  It's a little similar to when we used Trimble Junos as training devices for using TerraSync and Pathfinder that would work similarly to the GeoXH.

But I'm open to better ideas...

While I still have questions about the way the DJI RTK base station works, this is what I'm looking at as a possible best practice (in California since we're using CRTN with our GNSS system) for field and lab methods, at least for my work in a very large study montane meadow (10 sq km), incomplete (~90%) cell coverage, and following from about 4 years of mapping to look at change:

1. For each flight plan, put out at least 3 GCP targets, coordinates captured in Field Maps with the Eos Arrow Gold & CRTN, so in California SRS Epoch 2017.50 (NAD83).
2. Set up the base station near the middle of the flight plan (each flight plan being ~1 sq km), with no adjustment of the coordinates.
3. Confirming that RTK is connected, run the flight.
4. Download the GCPs from AGOL as a CSV.
5. Reproject those esrignss* GCP coordinates to WGS84 UTM, and reconfigure for Pix4D input as a CSV file with id, X, Y, Z (HAE), horiz precision, vertical precision.  [I'll do this in ArcGIS Pro and then Excel].
6. Process in Pix4D as WGS84 UTM.  

For a new project, we might use some variation on NAD83 (2011, or maybe a newer epoch), but the amount of effort in reprocessing our earlier data, captured as WGS 84 UTM using Trimble GeoXH, is prohibitive.  Also, our project involves multiple GNSS devices, all but the one Arrow Gold using SBAS correction giving us about 30-40 cm accuracy, and most of those output to WGS 84.  Given the >1 m difference between the WGS84 and the California SRS Epoch 2017.50 (NAD83), it seems we should go with what most of our devices use, to avoid confusion.

My rationale for just using the base station coordinates is that it's easy to screw up the base station adjustment process out in the hot sun, and there will likely be an offset to deal with anyway.  After testing on a local site, I'm reasonably convinced about the internal consistency the RTK solution is providing, with the direction and magnitude of offset pretty consistent.  Could probably get away with just one GCP, to see the offset, but we need check points anyway.  Definitely can't go with no GCPs, since in my tests the base station coordinates can vary each time you set it up on the same point, so we're dependent on the internal consistency followed by offset.
I'm still not certain about how the DJI D-RTK2 Mobile Station works, however, since the base station will stabilize at significantly different absolute coordinates (often > 1 m different, in X, Y, or Z) while at the same location when powered on anew each time, as I document in https://forum.dji.com/forum.php? ... 111&pid=3061777 .  Since the way RTK works is that the rover's position is only very precise relative to the base station coordinates, with absolute coordinates having the same error as the base station's error, I guess this makes sense, but I'm just surprised at how much the base station's absolute coordinates vary each time you power it up at the same location.  But this points to the true necessity of getting good coordinates of at least one GCP using a highly accurate GNSS unit; I'm using three GCPs for now.

patiam Posted at 2019-2-15 15:08
Sorry, HAE = Height Above Ellipsoid, which is the Z value all GPS positions are calculated & reported in (at least initially, unless adjusted to MSL or the Geoid or some other vertical datum).

For example, here is a OPUS Solution Report for one of the benchmarks we use here for testing and calibration:

Hi patiam,

Your posts are always helpful, thanks' !!

But have a look at what ChatGPT says about adding the antenna height to the HAE.




It's hard to trust ChatGPT, but this response sounds convincing, doesn't it?

Also, regarding the antenna type that has to be inputed to services like OPUS (we have our own IBGE PPP here in Brazil): I can't find DJI D RTK 2 as an option for antenna type. Do you have a workaround for that? Is it possible to input ARP to APC distance (which DJI does inform) in the REDIX file?

Thanks' again!

RDC Agritech Posted at 7-26 11:05
Hi patiam,

Your posts are always helpful, thanks' !!

Chat GPT is obviously not able to replace a surveyor. Adding the ARP is essential. The OPUS example given by Patiam is made with a Trimble Zephir.
What is important is that the receiver knows the position of the phase center of the antenna.

What we know is the point on the ground.

Ground point altitude + antenna height = antenna center phase.

For PPP with DRTK2 you can try ADVNULLANTENNA something like that.

Below are the DRTK2 dimensions:

LOL I love it... Now we're using ChatGPT to tell us how to do things .

The point is, if the solution you obtained from OPUS was already for the ARP, of course you don't want to add the antenna height AGAIN when entering the coordinates into the D-RTK 2.
But if the OPUS solution is for the benchmark on the ground, then the antenna height must be added.

You only want to account for the height once, or you'll have the same error as not correcting for it at all (but the opposite sign).

Effective use of answers from sources such as ChatGPT is dependent on knowing how to interpret them. There is nothing in that answer that contradicts anything posted here previously regarding accounting for antenna height.