We are using RS2 and M+ with LoRa installed into a UAV to undertake RTK photographic surveys. The EXIF location of the images recorded during the flight are to be updated post flight.
So when we use RS2 or M+ to log data when used individually as a single GNSS receiver clearly the logged data is representative of a single receiver solution. The data can then be post processed for a PPK solution.
But,
When we use RS2 or M+ together, the RS2 providing correction data via Lora to achieve an RTK solution. Is the data logged by the M+ error corrected realtime? Thus the RAW Data Log has been error corrected and can be used as is.
Not sure what you mean with error corrected. If you set up M+ as RTK then yes, is uses incomming RS2 correction data to compute a solution (float/FIX) and you can also record raw data for PPK later,but the raw recorded data is not error corrected.
The M+ unit is the only one doing some kind of filtering/correction onboard and is the unit doing the filtering throught SNR level, kalman and multipath adjustment etc.
In your logging menu, you can activate 3 different logs.
1.Raw rover log, this is data derived by the rover and rover only, no form of correction is recorded here, this is the one you use for PPK/PPP
2.Position, this might be the closest to a error corrected solution. It could be either singel, float or a Fix solution depending on you incomming correction. If you want the RTK result this is the one to enable
3.Base correction is incomming data from a base. Somewhat compact simplyfied data due to the data beeing sent over radio or internet link. Close to raw data but raw data on the base unit itself contains more data.
So if I understand you correctly the log file I should use from the M+ is the position file as this a computed solution from both M+ and incoming RS2 correction data.
What about the RS2 when using as a base and connected to NTRIP server? I assume the same in that the position file logged during the survey period is error corrected too?
Most users use PPK when they do photogrammetry with a drone. Using the recorded raw file from rover and the recorded raw file from base. Then you dont need a RTK link from UAV to the ground and you also have more control of your FIXed solution during postprocessing. I would say this is the recommend way of doing mapping to achieve the most accurate result.
But to answer your question, the logged solution is the result of RTK onboard.
If you are looking for a live computed solution, e.g connect a cameras to a external gps, you must configure and use the output solution her https://docs.emlid.com/reachm-plus/common/reachview/position-output/#formats
If set up the right way, this output corrected RTK solution
Yes
If you forward your base or any other base data to your M+ on the drone with a live RTK link, the output should be corrected as well yes.
This is what we would normally use, but we’re to map large areas of inaccessible terrain so it’s not possible to use PPK with GCP. What we’re aiming for is to use LoRa to provide the RTK data to the UAV, then use the logged files from M+ to update the EXIF. The M+ is logging the time the camera takes an image, but not correcting the EXIF.
So the process will be (I hope!)
Base connected to NTRIP server
Base sends corrected data to UAV/M+ via LoRa
UAV/M+ flies the set mission, records location data and time image was taken
Download logs and note camera trigger points
What I’m not sure of is how to link the position log file to the camera events.
If anyone has done this I will really like to know if it’s possible.
Yes, that should work.
Its not the most accurate way of doing mapping but might be close enough for your mission?
Do you have a spec this needs to be within?
Ortho - GSD 0.04m, absolute accuracy 0.1m, relative accuracy 0.08m
DSM - GSD 0.04m, absolute accuracy H 0.1m, V 0.35m, relative accuracy H 0.08m, V 0.12m
3D Mesh - GSD 0.1m, absolute accuracy H 0.3m, V 0.5m, relative accuracy H 0.1m, V 0.2m
Point Cloud - 0.04m, absolute accuracy H 0.03m, V 0.05m, relative accuracy H 0.03m, V 0.05m
Hmm… those numbers is going to be tough with RTK only, unless you have some high end gear in the UAV?
Whats your flight height/speed, UAV/camera and INS/IMU spec?
I’m not sure, but I think that just calculating the solution post-flight could add accuracy. With post-processing, you could use additional information which wasn’t available while calculating real-time positions. i.e. exact satellite positions, atmospheric errors/distortions, … they are know with higher accuracy when its in the past, in realtime solutions you can only use estimates/predictions of near future. (off course you need to dowload/provide this data to rtklib).
On the other hand, if the ambiguity was resolved and the solution is fixed… I don’t know if it’s really adding precision or just more information to acquire the fix.
Again, this is from my ‘theoretical/historical’ knowledge, not 100% sure, but sounds reasonable to me
For our survey work we use DJI P4 Pro v2 which have proved to be both reliable and accurate. Our standard practice is to use RS2’s to conduct an on site survey using local NTRIP service to fix the position of the base and Lora to provide NTRIP to the rover being used to mark the position of the GCPs around the site. Once complete multiple flights are conducted to take both nadir and oblique images. Our clients typically require GSD of 2cm/PX, which with a P4 means flying at around 72m AGL. The images are then processed in Pix4D, the survey log from the rover being used to mark the GCPs.
Seems to work, but as mentioned prior, for our upcoming work we’re going to flying over areas where we can’t place GCPs across the survey area, at best one at the take-off/landing zone, perhaps another GCP located somewhere else within the survey area.
Hi Chris,
I would strongly suggest utilising a pre-calibration of the P4 Pro’s camera for projects like this ie. minimal ground control.
I am just finishing up my thesis on the stability of the interior orientation of the P4 Pro’s camera and it has proven to be quite stable over a period of 3 months.
But the key point in this case is that with such minimal ground control, you require really strong imaging network geometry for the software to accurately determine the calibration parameters.
So, if you take ~40 images, at a very low altitude eg. 2 to 4m, and ensure a very strong imaging network geometry; you can then save the calibration parameters and use them in the later processing. If it’s possible to do the pre-calibration on-site, just prior to the flight, that is ideal.
I can send you some guides on how to best perform the pre-calibration if you would like.
With a good pre-calibration, the GCP’s can be used simply to scale the model and will have minimal effect on its shape. For my project I had 22 scale bars for checks and only a single scale bar used for providing scale. Adding additional scale bars to the bundle adjustment had no significant effect on the checks eg. under a mm. This was all close range mind you.
I’d encourage you to use a few GCP’s if you can. Even with survey-grade GNSS locations for the camera locations, a few GCP’s have demonstrated to be extremely valuable in assisting the software determine the camera’s focal length; which is a primary contributor to Z error.
Happy to send through some papers if you want to read more about it.
This is crucial point. If you are 1millisecond of, with 10m/s your data is going to be 1cm of.
And with RTK its even harder, and you only have one shot.
The phantom has a great camera for PPK but is lacking important stuff like accurat internal IMU.
And then there is the camera calibration.
With an overal accuracy and few ground control point you should get it just with in.
You really need consistent accurat of all you images. If you have one or maybe only two gcp and also have some sync issue 1or 2 ms off and some wind to tilt the camera with no lever arm adjustment, thing tend to grow out of wack with accuracy.
Your customer is probably expecting accuracy anywhere in the image or is it an overal agreement?
With enough gcp this wouldnt be much of an issue but, but no gcp with this kind of accuracy is going to be hard.
You can do this in the first step in pix4d. Import your gcp and set two of the points as 3D gcp and tie them to nearby images, leave the rest as check points and see where they line up in pix4d estimates. But do a test i similar condition
TB_RTK - thanks for input. Nothing specified other than the overall accuracy as per prior post.
We’ve site visits planned for the coming week, so hopefully we’re going to be able to find a few locations for GCPs. The project will last for 10 months with a series of flights over multiple locations to monitor changes overtime.
I’ll attach some documents to this post.
Let me know if you have any questions.
I’ve read very intensively and widely for my thesis; so I can point you in the right direction on most topics regarding UAV Surveying.
The Pre-calibration document is written by Prof. Clive Fraser who is an excellent resource.
You do have to use coded targets as in his example. Just note the key tips.
The paper by Pryzbilla outlines a very efficient flight plan ie. two seperate flights, one 20% above the other. This study did incorporate VERY high quality ground control, but you can see that even with only 5 GCP’s the precision far exceeds that of most studies. There are a number of reasons for this, but two key take-aways from this paper for you just briefly are the flight plan and the seperate processing of the flights ie. two sets of interior orientation parameters.
The paper regarding the P4P RTK demonstrates the errors that can occur when no ground control is in place.
Also, there’s an interesting section in the, ‘Grayson’ paper attached regarding PPP GNSS locations; where the location tagging was slightly delayed in comparison to the image capture…flying up and back actually allowed the error to effectively cancel itself out.
Hi Chris,
This may be more than is required for the project at hand; but Prof. Mike James developed a modified M3C2 algorithm for CloudCompare that allows for confidence interval bounded change detection of photogrammetrically derived point clouds.
Essentially it takes into account the estimated Survey and Photogrammetric errors to then determine what amount of change is significant ie. 95% chance of being real etc.
The more precise the Survey and Photogrammetric processing, the smaller the changes you can confidently identify.
Fixed ground control become even more important for surveys of change detection.
Thank you and very much appreciated. I’ve had a quick look, now I need to read and digest. We’ve been complimented on the accuracy of our work, however where there are ways to improve we should endeavour to do so. The camera calibration is something I had not considered prior, so this will be the first consideration. Will most certainly have some questions for you at some point, so your offer of help is accepted. Cheers…
This is interesting, as that is somewhat of departure from how I would derive my calibration.
I see a few problems with your proposed flow:
To achieve a tack sharp image 2-4 meters, it would be beneficial to not use infinity focus on the p4pro. However, for repeatability from flight to flight, having a hard-stop like infinity would absolutely be preferred. I would imagine that this wouldn’t be much of problem using smartphones or the sub-1-inch sensor found in the Mavic products. But when you get to bigger sensor, you’ll lose sharpness pretty quick to the point where you can’t place pixels precisely enough.
When using GCP’s/Scale bars for calibration, remember that GNSS have the constraint of 1-3 cm 3D accuracy. If your area of flight only spans 20-30 meters, your ratio between the gnss accuracy and the mean distance between your GCP’s isn’t big enough to effectively mean out the inaccuracy of the GCP’s. Scalebars are nice check, but doing them over distances (where they really matter) is hard to do accurately. If course, you place the GCP’s by Total Station, but then the time saved by using a smaller area gets sucked up by traversing the total-station.
Other than that, I completely agree with your points, and I would love to read your thesis, when you are done (I am a (former) Phase One/ (now) Capture One employee, well-versed in the camera-calibration/Lens-correction of both metric Phase One systems (they always play nice) and various old 35mm format beat-up lenses (they rarely play nice))!
