Emlid + Zenmuse L2 PPP Workflow Question

Reach RS3 RTK / PPK configuration
1

I’m trying to pinpoint where the error is in my workflow (if any error).

My LiDAR DTM (surface representing bare earth) is consistently off my around 100 mm when compared to check points (obtained at the same time) and as compared to other DTMs in the same projection. When comparing DTMs, am I using very distinct surface (e.g., paved roads). This comparison has been done against three separate surveys in three very different areas yielding similar errors.

General workflow is as follows.

I setup by base over an unknown location, using a local NTRIP between the RS3 and the Matrice 350 RTK/Zenmuse L2. The RS3 is collecting RINEX / positioning data for PPP (which I do later).

When I return to the office, I submit the 24O file to NRCan to obtain the precise point position coordinate the ellipsoidal height. These X, Y, Z points are then inputted into DJI Terra. To do this, I click the Base Station Center Point Settings in DJI Terra, input my base coordinate from NRCan and add my antenna height (pole height + antenna offset). For reference, I have included the observation file and PPP data sheet from NRCan.

The error (~100mm) is strikingly similar to the antenna offset (APC to ARP). I’m wondering if this has something to do with the error.

Please advise.

EmlidRS3_raw_20240907205720.OBS (844.7 KB)
EmlidRS3_raw_20240907205720_rapid.pdf (1.2 MB)

3

Your workflow seems correct. Indeed in terra you have to include both pole and offset, so no errors in that part. The 10 cm error is same for all check points? Bare in mind that the vertical accuracy of the L2 is around 10cm. Also in Dji terra the “smooth” option is very bad and sometimes it can cause such errors (credits to indiana drones)

Dji Terra has implemented a vertical adjustment tool if you add control points. Using that tool, you can mitigate the errors.

3 Likes
4

Hi @davidevanr,

Thank you for explaining the workflow. I can see that your workflow for the PPP using NRCan is correct.

I see that your data duration is 2.51 hours. I’d suggest to 4 hours as the NRCan recommendation. Also, since the processing is marked as “Rapid,” I’d suggest try to PPPing the data again.

Is the point is off just on the vertical or also the horizontal?

Additionally that the PPP process on the NRCan will able to read the antenna information from the file, so the base point result from the PPP is the point on the ground.

For the DJI Terra, I don’t have extensive experience with it. I suppose DJI support is better to address the setting question on the DJI terra. Other suggestions from me is to ensure the datum from PPP processing and the DJI Terra.

2 Likes
5

I am not familiar with the NRcan system, I did take a look, and noticed it does not request a rod height. I tried your file a couple times and it seems to source that from the RINEX file. I noticed your antenna height is 2.446 Meters. Double check if that is the corrected height to phase center. And that would be the same value in DJITerra.

I just want to make sure the antenna correction didn’t get applied twice before you processed it.

I will say, my typical unadjusted RMSE in the Z is about 7cm. Once we complete the flight-line matching, our final step is a delta Z adjustment to de-bias the Z and remove that 7cm.

1 Like
6

Thank you for the help. Yes, mostly off on the horizontal. To be fair, the LiDAR I am comparing against may be off from absolute Z by this amount too.

7

Thanks for the response Bobby. 2.446 m is the height to the antenna reference point (ARP, i.e., underside of receiver). NRCAN should read ARP to APC off the RINEX file so I believe it accounts for the additional 134 mm (as Merryna confirmed).

Applying an adjustment in the Z is interesting. Do you have more background information on this?

8

2.446M to ARP: This helps

Antenna Offset in NRCan: NRCan get the height to ARP from the RINEX file. I think it is looking for the antenna ANTEX file in a database use the record below. The opus system in the US is manual, We have enter to enter the height (ARP) and select the Antenna type.

                EMLID REACH RS3                         REC # / TYPE / VERS 
                EML_REACH_RS3   NONE                    ANT # / TYPE

RINEX Files: RINEX files do not typically store the antenna offset between APC and ARP, although they can using a ANTENNA: PHASECENTER record. But I have never seen that in use. Instead, they typically store the antenna height as vertical distance from the ground to the ARP. Some users might incorrectly include a correction for the phase center in this value, but this is not the intended use and could lead to errors, particularly duplication of the correction.

DJI Terra Antenna Correction: DJI Terra does not apply an antenna correction automatically. When entering the antenna offset into DJI Terra, you should manually input a value that is adjusted for the phase center. In this case, the correct offset to input is 2.58 meters.

In summary, you need to ensure that the antenna offset you enter into DJI Terra is already corrected for the phase center because the software does not automatically make this correction for you.

Note: Most people using this system are using what’s referred to as a floating base where they do not calculate ground base coordinates, Instead they just let the receiver calculate the points at the APC. That’s why it can be hard to find documentation on this with DJI.

Debiasing the Z-axis in LiDAR mapping data refers to correcting any systematic vertical errors or biases that may exist in the elevation data collected by the LiDAR sensor. This is crucial because accurate elevation data is often a primary objective in LiDAR mapping, and any vertical bias can lead to incorrect conclusions or measurements.

Debiasing Process:

  1. Ground Control Points (GCPs): One of the most common methods for debiasing is to use GCPs, which are points with known accurate elevation values. By comparing the LiDAR data to these GCPs, you can identify and correct any biases in the Z-axis.
  2. Cross-Validation with Existing Data: Comparing the LiDAR data with existing, high-accuracy elevation data (e.g., from previous surveys or other reliable sources) can help identify systematic biases.
  3. Sensor Calibration: Ensuring that the LiDAR sensor, GNSS, and IMU systems are properly calibrated and working within specified tolerances can minimize biases.
  4. Algorithmic Corrections: Some software solutions provide algorithms to automatically correct for biases by analyzing patterns in the data (e.g., gradual drift or systematic offset) and applying corrections.
  5. Strip Adjustment: In airborne LiDAR, adjusting overlapping flight lines (or strips) can help identify and correct vertical discrepancies, ensuring that the data from different passes align correctly in the Z-axis.
  6. Statistical Analysis: Using statistical methods to analyze the elevation data distribution can also help in identifying any systematic bias. For example, if most of the data points are consistently above or below the expected elevation, a bias might be present.

Hope this helps

1 Like
9

Thank you for the information on di-basing. Appreciate the write-up.

I can confirm that I am accounting for the ARP to APC offset when I update the base station XYZ in DJI Terra.

With respect to NRCAN, I understand it reads the antenna type, and obtains the ARP-APC offset that way (see “Additionally that the PPP process on the NRCan will able to read the antenna information from the file, so the base point result from the PPP is the point on the ground.” in the post from Merryna)

10

No problem, I just noticed you did not mention swapping out the RTB files. if you don’t rename the RTB file and add the OBS-RINES to the Flight folder, it is not doing PPK, your just re processing the RTK. The RTB has the RTCM3 data stream from the time of flight, and DJI will use it if it exists.

This is the process my team uses, and some example pre and post adjustment reports.

UPDATING THE RINEX FILE
This process must be done per each flight folder

Copy the updated Rinex file with extension .2#o into the Flight Data folder for all flights. (You may want to update the header with the ECEF Ground Coordinates before coping the file, this way you won’t have to update coordinates in DJI Terra, you will need to use an APC base rod height)

Then find the RTB file copy the file name of the RTB file, then after add OLD to the extension. Example: (………RTBOLD)

Next find the .2#o file in the flight folder now paste the file name and change the extension .OBS.

Again the has to be done for each flight folder, Also note some Flight folder may have 2 data set. You will need to do this for all RTB files, and in this case there would be multiple RTBOLD and OBS files.

Here is some info from a flight I just processed ,the units are US Survey Feet. so the average dz of .094’ is 2.8 cm.

Un-Adjusted

Number Easting Northing Known Z Laser Z Dz
4 507557.755 1516447.729 567.695 567.970 +0.275
5 508117.096 1517120.953 632.062 632.070 +0.008
6 508704.203 1517069.409 651.841 652.030 +0.189
7 508828.116 1517737.420 716.704 716.760 +0.056
8 507936.664 1516204.762 586.056 586.000 -0.056

Average dz +0.094
Minimum dz -0.056
Maximum dz +0.275
Average magnitude 0.117
Root mean square 0.153
Std deviation 0.135

Adjusted

Number Easting Northing Known Z Laser Z Dz
4 507557.755 1516447.729 567.695 567.620 -0.075
5 508117.096 1517120.953 632.062 632.080 +0.018
6 508704.203 1517069.409 651.841 652.090 +0.249
7 508828.116 1517737.420 716.704 716.670 -0.034
8 507936.664 1516204.762 586.056 585.920 -0.136

Average dz +0.004
Minimum dz -0.136
Maximum dz +0.249
Average magnitude 0.102
Root mean square 0.132
Std deviation 0.148

1 Like
11

Thank you very much for the help - really do appreciate it.

I have generally been following your workflow (with regard to renaming OBS file and importing into the raw data folder). I had followed the following workflow: DJI Zenmuse L2 PPK Workflow – E38 Survey Solutions

Is the E38 workflow consistent with your procedure?

Cheers.

12

My work flow is a little bit different. I’ve been processing data in DJITerrace since version 3.4 so some of my workflow is based on the limitations from the past. I’m not sure if some of these things have been alleviated but this is the way I do it .

First we will process our base RINEX point file in my case using Opus and in yours Nrcan

I would then update the coordinates in the Rinux header file to contain the ECEF coordinates from the OPUS output. I don’t change the z value. Do make note of your rod height in the RINEX file. It should represent the height to ARP for use with NRCan. It will have no effect on DJITerra (More to come).

The website did not explain how crucial it is to name the files properly. The new OBS file has to have the same file name as the rtb file had before you renamed it. For example

  	Original
  		Flight_123.RTB
  	Corrected
  		Flight_123.RTB.OLD
  		Flight_123.OBS (This is the updated Rinex file)

Note: If you did not change the name of the RTB file it will use it instead of the OBS, not sure if that is still the case though.

Then in DJITerra, I will import the flight data. I don’t use any optimization (I do not have the paid for version), again I use TerraScan and TerraMatch for the refinement process and I am a big fan it.

Also, I did have a lot of issues with Coordinate transformations in DJITerra so I always output to WGS84, and convert on import into Terrascan. However, I know a lot people use DJITerra these days with no trouble.

The only settings I am worried about is output coordinate system, Height offset (APC based rod height), and output files (for me LAS)

From there I use the SBET.out and the LAS with Terasolid the maker of Terrascan. They have an awesome wizard which is a great starting point. And the “Known Control Report” is where I make the reports I sent you earlier, and where I apply the delta Z adjustment.

One last thought to consider. You post processed your recover file (The RINEX) and you’er PPK processing you flight. But did you PPK you ground control, or are you still using the coordinates from the original RTK, for these to agree they will also need to be post processed.

13

I see your workflow (renaming the OBS/RTB files, etc.) is included on Page 25 and 26 of the Zenmuse L2 manual (Zenmuse_L2_User_Manual_v1.2_ENI).

I guess I should mention that I setup a local NTRIP between the Matrice/Zenmuse L2 and the RS3, so technically I do not need to PPK the data afterwards. The L2 data is initially captured with respect to the arbitrary base station coordinates, and then corrected with the PPP’d base station coordinates later on. So it is essentially a base shift in the X,Y,Z only. So I’m assuming there is no need to rename the Rinex/OBS file and replace the RTB file, etc…, correct?

With respect to GCPs and CPs, I run the check and output a quality report in the “local” coordinate system. So yes I do this but with the original data.

I think the original error was due to insufficient observation duration.

14

I ran a quick test and found no difference running it with the OBS or RTB with adjusted Coordinates. That is cool…

For our Ariel targets we do 180 epochs, and verify with a test shot before we leave the site and while we recover the targets. For our Check-shots we do 5 epochs.

Are you using the same base when you read the targets? (This is the best practice). If so, are you post processing the Targets with the updated base coordinates from NRCan. You should post process with “Stop and Go” in Studio so that the flight and targets are in the same system.