When using a third party base station doing ppk, how can the image positions be corrected like the laser data is? Even though the current workflow for PPK on the laser data is very janky and not a smooth process I have it down and it comes out well.  The images are not in the same project as the Terra LAS is. So the photos are (I assume) not even being looked at or adjusted in Terra. When going into Metashape or any other third party software there are no corrected images to bring in with the LAS file. You can see from the screenshot that the images are located well above the trajectory lines but also have a slight shift in the X and Y. When using a DEM created from the LAS to produce an ortho, the images are far off from the actual locations they were taken and that causes plenty of issues. Does anyone know how or if this can be corrected? From a few people I have spoken with about this there doesn't seem to be a way to PPK the images. Which would be a real problem if DJI has done this intentionally.

You must choose photogrammetry mission instead of lidar for this purpose.

LV_Forestry Posted at 2-1 09:27
You must choose photogrammetry mission instead of lidar for this purpose.

That's a good idea and I appreciate the suggestion. I just tried this with high hopes but it seems that doing anything in visible light mode requires a Terra license. DJI fails to give you the needed data from the drone to PPK the images from a third party tool. The more I use Terra the more disappointed I am with how limited it is. I don't even see an option to use the base station in the visible light mission type.  

The workflow is as follows:

Fly photogrammetry mission
PPK with RTKLIB, Emlid Studio, Redtool...
Process corrected images in Terra (Metashape for professional) ;)


Maybe the issue has been fixed but when you fly Lidar mission one part of EXIF data are missing in images. Anyway because of the overlap it is more appropriate to fly separate mission.

LV_Forestry Posted at 2-1 22:04
The workflow is as follows:

Fly photogrammetry mission

I have just finished testing the two types of missions using the L2 this time instead. My initial findings, and correct me if I'm wrong, is that flying a photogrammetry mission flys much faster, doesn't do the IMU calibration dances but also doesn't save any of the lidar data (even though it shows it on the RC during flight). It also doesn't seem to save the PPKraw.obs or similar files that is needed for PPK processing. Flying a typical L2 5 Return Repetitive mapping mission saves a fairly decent lidar point cloud but doesn't allow you to PPK the images either from that same flight.

Johnnokomis Posted at 2-2 09:03
I have just finished testing the two types of missions using the L2 this time instead. My initial findings, and correct me if I'm wrong, is that flying a photogrammetry mission flys much faster, doesn't do the IMU calibration dances but also doesn't save any of the lidar data (even though it shows it on the RC during flight). It also doesn't seem to save the PPKraw.obs or similar files that is needed for PPK processing. Flying a typical L2 5 Return Repetitive mapping mission saves a fairly decent lidar point cloud but doesn't allow you to PPK the images either from that same flight.

Yes if you choose photogrametry then it won't save lidar data.
You must have a file .OBS or something else which in reality is a .rtcm3 file.
And finaly there must be the MRK file.

I just hope that DJI doesnt decide to not produce OBS file if the RC is not connected to an NTRIP client.

LV_Forestry Posted at 2-2 11:20
Yes if you choose photogrametry then it won't save lidar data.
You must have a file .OBS or something else which in reality is a .rtcm3 file.
And finaly there must be the MRK file.

There is an .MRK file. There's also a .RTS .RTL .RTK .RPT and .RPOS. All are relatively small in size.  The only .obs file is the one from the base station that I had to add and rename. Why does DJI feel the need to intentionally handicap their products so much?

Johnnokomis Posted at 2-2 14:01
There is an .MRK file. There's also a .RTS .RTL .RTK .RPT and .RPOS. All are relatively small in size.  The only .obs file is the one from the base station that I had to add and rename. Why does DJI feel the need to intentionally handicap their products so much?

OK, I see.  They deliberately handicap the data, I don't know why.  

You will take the .RTK file, you will change the extension to .rtcm3, then you use the convert function of Emlid Studio.  There you will obtain your OBS rover file.  

Then still in Emlid Studio, in PPK drone, you feed the two OBS rover and base files, the MRK file, you grab a NAV file on the IGS for example.  Your images will be geo-referenced.  

It remains to put everything in Metashape. Or Terra, but its not recommended at all.

Be careful because the .RTK file is the OBS of the left antenna, I am not sure of the reference of the lever arm of the payload.  The values are in the MRK file.

You can PPK the imagery with RedCatch.  If you buy it from BAAM.tech, they'll send you a workflow guide for the L1 or L2 that includes step by step instructions for the entire start to finish process, including PPK'ing.

fanse68b7f05 Posted at 2-21 08:22
You can PPK the imagery with RedCatch.  If you buy it from BAAM.tech, they'll send you a workflow guide for the L1 or L2 that includes step by step instructions for the entire start to finish process, including PPK'ing.

I don't really see what redcatch (payware) will bring more, versus emlid studio which is free and does the same thing.

fanse68b7f05 Posted at 2-21 08:22
You can PPK the imagery with RedCatch.  If you buy it from BAAM.tech, they'll send you a workflow guide for the L1 or L2 that includes step by step instructions for the entire start to finish process, including PPK'ing.

I'm not familiar with them but It shouldn't take a third party purchase to PPK images. This is at the fault of DJI since they have done it this way on purpose. They don't want us to PPK the data anyways. They make it this difficult to encourage people to purchase and use the terrible D-RTK2. Many users don't realize third party base stations can be used. They are lead to believe that a D-RTK2 is their only choice and have never used a real base station to have anything to compare it to.   

LV_Forestry Posted at 2-22 00:40
I don't really see what redcatch (payware) will bring more, versus emlid studio which is free and does the same thing.

What still has me tripped up is the .nav file. I have converted the PPKraw.bin to a rinex but it doesn't work.  

Mainly because the converted file reads like this..

     3.04           OBSERVATION DATA    GPS(GPS)            RINEX VERSION / TYPE
cnvtToRINEX 3.14.0  convertToRINEX OPR  20240223 020529 UTC PGM / RUN BY / DATE
----------------------------------------------------------- COMMENT            
DJI_                                                        MARKER NAME         
DJI_                                                        MARKER NUMBER      
GEODETIC                                                    MARKER TYPE         
GNSS Observer       Trimble                                 OBSERVER / AGENCY   
##########          UNKNOWN             x.xx                REC # / TYPE / VERS
##########          UNKNOWN_EXT     NONE                    ANT # / TYPE        
        0.0000        0.0000        0.0000                  APPROX POSITION XYZ
        0.0000        0.0000        0.0000                  ANTENNA: DELTA H/E/N
  1980     1     6     0     0    0.0000000                 TIME OF FIRST OBS   
  1980     1     6     0     0    0.0000000                 TIME OF LAST OBS   
     0                                                      RCV CLOCK OFFS APPL
     0                                                      LEAP SECONDS        
     0                                                      # OF SATELLITES     
DBHZ                                                        SIGNAL STRENGTH UNIT
                                                            END OF HEADER      

Johnnokomis Posted at 2-22 18:22
What still has me tripped up is the .nav file. I have converted the PPKraw.bin to a rinex but it doesn't work.  [view_image]

Mainly because the converted file reads like this..

No worries you can download a NAV file from anywhere. It is simply the sat trajectory file. https://urs.earthdata.nasa.gov

LV_Forestry Posted at 2-22 21:20
No worries you can download a NAV file from anywhere. It is simply the sat trajectory file. https://urs.earthdata.nasa.gov

That didn't seem to work. I used the .NAV file from my base station since it covered the same time as my flight. Emlid Studio processed it but all images were tagged within a meter or so of the base itself. The purple flight lines are the PPK corrected flightlines and the green dots are the photos still in their uncorrected position. I still cannot believe DJI has gone to such lengths to make correcting their flagship L2 images this difficult.  

Johnnokomis Posted at 2-23 22:16
That didn't seem to work. I used the .NAV file from my base station since it covered the same time as my flight. Emlid Studio processed it but all images were tagged within a meter or so of the base itself. The purple flight lines are the PPK corrected flightlines and the green dots are the photos still in their uncorrected position. I still cannot believe DJI has gone to such lengths to make correcting their flagship L2 images this difficult.  [view_image]

You can share the folder, i will take a look.

LV_Forestry Posted at 2-23 23:30
You can share the folder, i will take a look.

Sent you a PM. Thanks

Johnnokomis Posted at 2-24 05:10
Sent you a PM. Thanks

Step 1/ Change .RTK file extension (located in the L2 folder) by .rtcm3 It is the observation file of the rover, here the drone itself.


Step 2/ Convert it to RINEX with Emlid, pay attention to choose the right date.


Step 3/ Open the result folder (must be located where the .rtcm3 file is). You must find one OBS (.24O) and one NAV (.24P) P is Mixed Nav, no worries if its not N.


Step 4/ In Emlid, Drone Data processing, as follow :
Drone : The .24O from previous conversion
Base : Your favorite Base station OBS file
Navigation : The .24P from previous conversion, or any of you favourite navigation file provider (IGS)
MRK : The MRK file from the L2 folder


Perfect ! Oblique pictures are in Single mode, i don't know why. Looks like it wasnt covered by the OBS file.

Step 5/ Add the L2 folder and tag pictures.


Step 6/ Locate the .pos file which should be near the tagged pictures folder. Copy data but not the header, then paste it in Excel.



Step 7/ Load pictures in Metashape. Export pictures tag in a csv file (This step is made to save pictures names and camera calibration data if they exist, in this case no) Paste this info in the Excel sheet. save as CSV format.



Step 8/ Load it in Metashape and choose Columns as they are below :



It will update coordinates if you use the original pictures, and add accuracy.
It's a bit of a tedious process, but it's effective!



I find a difference of 5m vertical by staying in WGS and without using GCP, without calibrating the camera. Not too bad !


Could you share with me the coordinates of the GCPs so that I can check on the orthophoto?

It is not bad at all. I applied a correction of 1.90m for 158deg.
This demonstrates the importance of GCPs, and RTK/PPK is necessary to maintain raster proportions.

With a tighter overlap and a calibration of the camera with the Metashape checkerboard it should be possible to considerably reduce the offset.

LV_Forestry Posted at 2-26 00:05
It is not bad at all. I applied a correction of 1.90m for 158deg.
This demonstrates the importance of GCPs, and RTK/PPK is necessary to maintain raster proportions.

Your suggested workflow did perfectly. I was able to get a fix for all 88 photos. I included 2 different base observations so the one virtual base station file might have caused what you have. I haven't done the Excel spreadsheet steps yet but still happy to be this far.

LV_Forestry Posted at 2-26 00:05
It is not bad at all. I applied a correction of 1.90m for 158deg.
This demonstrates the importance of GCPs, and RTK/PPK is necessary to maintain raster proportions.

This is great LV_Forestry! Very well written and will definitely help many in the near future!
You can also convert the .RTK file with RTKLib RTKConv application.

TerraVia ZM Posted at 4-18 09:41
This is great LV_Forestry! Very well written and will definitely help many in the near future!
You can also convert the .RTK file with RTKLib RTKConv application.

Yes I am also a big fan of RTKLib Explorer. Now I find it more complicated to use so I recommend as a priority Emlid Studio which is user friendly and very up to date.

Bookmarked!! Thanks LV

LV_Forestry Posted at 2-25 14:00
Step 1/ Change .RTK file extension (located in the L2 folder) by .rtcm3 It is the observation file of the rover, here the drone itself.[view_image]

Dear LV_Forestry,

I have followed your instructions, but after completing step 4 of the processing, the image position is in FLOAT, which I believe is incorrect. I would appreciate your opinion on this matter.



Please note that the drone flight was conducted without RTK correction, but we have a base station available to apply PPK correction.

Looking forward to your advice.

Marco968 Posted at 10-23 04:40
Dear LV_Forestry,

I have followed your instructions, but after completing step 4 of the processing, the image position is in FLOAT, which I believe is incorrect. I would appreciate your opinion on this matter.

Unfortunately it appears that the base station is at least 10km too far away to obtain satisfactory results.



I have two solutions to propose to you:

1/ play with the settings of Emlid to make it more permissive, I mean modify the SNR mask. Not sure that it works because it is really very far.


2/ take a look here :
[ ]Alternative to DRTK2 and NTRIP Provider | DJI FORUM
But that means you're going to have to invest a little in equipment and, most importantly, do the flight again.

LV_Forestry Posted at 10-23 06:00
Unfortunately it appears that the base station is at least 10km too far away to obtain satisfactory results.

[view_image]

LV_Forestry, your first solution didn’t work. I tried different SNR Mask values, but the correction remains in Float. Can I send you the .pos file as I’d like to hear your opinion on the accuracy achieved. Could you help me interpret it?
Your second solution is fascinating, and I will definitely consider it in the future.
I have another question and would appreciate your thoughts. As you can imagine, I am using a GNSS base station that belongs to a national network. These antennas are usually placed on top of buildings, I asked the operator if they could provide the antenna height relative to the ground. Unfortunately, this is a value the operator does not know. As a result, when I process my Lidar data, the point cloud gets an offset equal to the antenna's height.
I can fix this issue using GCPs, but initially, I’d prefer to get as close as possible to reality using the GNSS base. Do you have any suggestions on how I can retrieve the antenna height to minimize the offset in my data?

Best regards

Marco968 Posted at 10-24 02:58
LV_Forestry, your first solution didn’t work. I tried different SNR Mask values, but the correction remains in Float. Can I send you the .pos file as I’d like to hear your opinion on the accuracy achieved. Could you help me interpret it?
Your second solution is fascinating, and I will definitely consider it in the future.
I have another question and would appreciate your thoughts. As you can imagine, I am using a GNSS base station that belongs to a national network. These antennas are usually placed on top of buildings, I asked the operator if they could provide the antenna height relative to the ground. Unfortunately, this is a value the operator does not know. As a result, when I process my Lidar data, the point cloud gets an offset equal to the antenna's height.

Yes you can send the file.

If the provider does not know the height of his antenna there is a problem. I especially think that the employee who answered you either does not care, or he does not know anything about it.

I think your problem is not caused by the antenna height (because it is taken into account by the provider before sending the corrections) but by the conversion from a global coordinate system to a local one. I recommend you to go and have a look there:
DJI Products EXIF Wrong Altitude / How to solve it | DJI FORUM

In theory, after reading you will look for a file, don't look any further, it's there:
ISG - International Service for the Geoid

LV_Forestry Posted at 10-24 07:05
Yes you can send the file.

If the provider does not know the height of his antenna there is a problem. I especially think that the employee who answered you either does not care, or he does not know anything about it.

I have just sent you the file, anyway, I’m not sure if the provider takes antenna height into account. I’ve made some orthometric corrections using national grids, and once I obtained the AMSL altitude, there was quite a difference compared to the actual value, which I can easily check on Google Earth. While I know Google Earth isn’t ideal for precise comparisons, a discrepancy of 10 to 15 meters seems significant enough to be noticeable. This makes me think that the absence of this crucial information might be causing the offset.

Thank you again for the link—very well explained. It’s always enjoyable to revisit old-school concepts. I hadn’t seen the second link, but I’ll take a closer look at it. As I mentioned, we’re using national grids, which are quite accurate for orthometric corrections. I noticed they provide for the Geoid a .dat file; could you guide me on how to use it?

I’ve been using EMLID Studio to correct the altitude for each image, entering the antenna height after orthometric correction to get AMSL altitudes. However, I still suspect there’s an offset, as I mentioned. If you’re interested in looking into this further, I’d be happy to share some files.

Marco968 Posted at 10-24 23:40
I have just sent you the file, anyway, I’m not sure if the provider takes antenna height into account. I’ve made some orthometric corrections using national grids, and once I obtained the AMSL altitude, there was quite a difference compared to the actual value, which I can easily check on Google Earth. While I know Google Earth isn’t ideal for precise comparisons, a discrepancy of 10 to 15 meters seems significant enough to be noticeable. This makes me think that the absence of this crucial information might be causing the offset.

Thank you again for the link—very well explained. It’s always enjoyable to revisit old-school concepts. I hadn’t seen the second link, but I’ll take a closer look at it. As I mentioned, we’re using national grids, which are quite accurate for orthometric corrections. I noticed they provide for the Geoid a .dat file; could you guide me on how to use it?

Well, the file itself does not present any anomaly.
As mentioned previously you are much too far away to obtain a reliable correction in these mountainous regions.

On the other hand I am intrigued about the base station. I have not found where it is referenced. I found it physically on Google maps, and the least we can say is that it looks like an amateur construction. It is fixed on a chimney, on a slate roof... It's a bit excessive... there are rules to follow to install this type of device.




Do you know precisely the difference in altitude that you note between your dataset and reality?

Marco968 Posted at 10-24 23:40
I have just sent you the file, anyway, I’m not sure if the provider takes antenna height into account. I’ve made some orthometric corrections using national grids, and once I obtained the AMSL altitude, there was quite a difference compared to the actual value, which I can easily check on Google Earth. While I know Google Earth isn’t ideal for precise comparisons, a discrepancy of 10 to 15 meters seems significant enough to be noticeable. This makes me think that the absence of this crucial information might be causing the offset.

Thank you again for the link—very well explained. It’s always enjoyable to revisit old-school concepts. I hadn’t seen the second link, but I’ll take a closer look at it. As I mentioned, we’re using national grids, which are quite accurate for orthometric corrections. I noticed they provide for the Geoid a .dat file; could you guide me on how to use it?

I have another question. What do you use to plan the trajectories? Because it goes a bit in all directions. What cutting-edge software does something like that?

LV_Forestry Posted at 10-25 08:54
Well, the file itself does not present any anomaly.
As mentioned previously you are much too far away to obtain a reliable correction in these mountainous regions.

Dear LV_Forestry,

Thank you for your interest in my topic. The provided ellipsoidal base height is 851.60 m, and after correction, I get an altitude of 809.26 m AMSL. I can only check the altitude on Google Earth, where I notice a difference with the terrain level of 8 to 9 meters, which I believe may correspond to the building height. The antenna is part of a professional network, but I’m quite disappointed because they seem unaware of details regarding their installations; I was advised to contact a surveyor to measure the antenna height, which is rather unprofessional. I also have access to another antenna, but, unfortunately, its height isn’t provided either.

Regarding the LiDAR model, for now, I can only cross-check altitude using Google Earth; I’ll be recording GNSS points soon, but so far, I have observed a constant offset of about 2 meters. The software I use to plan trajectories is DJI Pilot 2. Could you clarify what you mean by 'it goes in all directions'?

Marco968 Posted at 10-28 00:57
Dear LV_Forestry,

Thank you for your interest in my topic. The provided ellipsoidal base height is 851.60 m, and after correction, I get an altitude of 809.26 m AMSL. I can only check the altitude on Google Earth, where I notice a difference with the terrain level of 8 to 9 meters, which I believe may correspond to the building height. The antenna is part of a professional network, but I’m quite disappointed because they seem unaware of details regarding their installations; I was advised to contact a surveyor to measure the antenna height, which is rather unprofessional. I also have access to another antenna, but, unfortunately, its height isn’t provided either.

Can you send me a RINEX file from this professional base station?
A 24hours file would be ideal.

LV_Forestry Posted at 10-28 01:20
Can you send me a RINEX file from this professional base station?
A 24hours file would be ideal.

I have just sent you a PM.

Marco968 Posted at 10-28 02:14
I have just sent you a PM.

Well, I understand better what your problem is.
First, you can safely use the base station, provided you are relatively close to it, 30km is too far.
  (Sorry, You will have to copy the coordinates manually, the forum interface does not allow me to publish a series of numbers. Ineffective anti-spam policy implemented recently.)

You can try to redo the process with these new coordinates. Not sure if it helps, because calculated from a 2h file, the result can be more than uncertain. And anyway as mentionned before, its too far away.

Then, when you say altitude taken with Google Earth, in reality you are referring to the SRTM4 reference model, used by Google, which is purely indicative.
The resolution of the original file is 30m, which means that the extrapolation can generate enormous errors.
SRTM | NASA Earthdata

I find the center of the antenna at 7.99m from the ground (according to Google Earth model... SRTM4) Which is of absolutely no interest because the coordinates of the base station are correct. So your altitude error does not come from there.

Using the SRTM for geographical work is really not recommanded. To give you an idea of ​​the differences that can be found, today I did a survey on a road. A point measured at 3.70m high in reality, is at 1.91m on the SRTM. 1m79 error.


50m further I measure a point at 3.37m high, on the SRTM it is at 3m exactly. 37cm error.


And this is in the center of Riga which is relatively flat. I let you imagine in a mountainous environment with very pronounced relief what the margin of error can be. In fact, no need to imagine, look at the results you get.


I propose the following workflow:
-Do your survey with your Lidar L1 connected to a base station not exceeding 25km away.
-Output the point cloud on DJI Terra using the EGM96 geoid.
-Use it as a reference to generate DEM / DTM...
You can also use it as a reference to set the altitude of the GCPs if you want to do photogrammetry from the L1 photos.


If your client requests georeferencing in the national system, think about using the appropriate geoid instead of EGM96 !
ITA2009 for example.


And finally, if you still need to refer to an existing model, you can use more precise models than the SRTM, like this one:
Tinitaly
Using this one for comparison, I find 50cm difference with the SRTM at the coordinates of the base station, and 14m at the takeoff point of the drone...  
I think the evidence is clear.

Marco968 Posted at 10-28 02:14
I have just sent you a PM.

Follow the link below to find the website of your national geographical institute.

https://www.igmi.org/en/geoprodotti#b_start=0

It is possible to see the inventory of geodetic markers for free, the differences with the SRTM are huge as expected.
You can use it to place your own base station.