First, I’m going to speak to using RTKLIB to process as it can only one base station-rover pair at a time. Therefore…
Your local base station becomes the heart of your operation. You will want to establish its position prior to any rover post-processing. It does not matter if this position is known ahead of time or even during the RTK process.
Base sends ITS OWN data to the UAV and the UAV calculates its position relative to the base using whatever coordinates were assigned to the base. Note that the Base is NOT forwarding any NTRIP corrections; the NTRIP corrections going to the base only help initially definine its position.
M+ monitors the RTCM stream coming from the base and processes its relative position compared to it (RTK). This position is logged as LLH if desired. This position is NOT recorded in the .ubx or RINEX data that is used for post-processing. The M+ also functions as a precise clock for nano-second timing accuracy on photo events, and those event times are recorded in the .ubx. The actual photo positions (lat-long-height) are not recorded in any of the logs in my workflows, but maybe others could speak to this “RTK” photo position logging.
Download the rover (M+) .ubx file, and download the base station (RS2) .ubx file. You COULD use the RTCM3 file as a replacement for the RS2 log because they should have roughly the same information, but the base’s .ubx is better because it isn’t reliant on a radio link. During the relative post-processing between the RS2 and the M+, the full trajectory is created and then the photo positions are interpolated between those positions. I doubt that this interpolation happens live, so PPK is by far the best procedure.
Both the base and rover are logging the raw satellite signals for post-processing, not calculated positions. This allows them to figure out the difference in their location very precisely when one of the files is treated as stationary (the base). It’s great that your base is L1/L2 as its position will be more that likely able to be calculated accurately. It would also be advisable to use a M2 if you plan on taking off from sky-obscured areas like valleys or near tall trees or operating too far from the base. The L1-only PPK process can be quite finicky and challenging. See emlid’s video for more information: https://youtu.be/qUL16b-SUAc
Hi Christian,
Thanks mate. Must have been pretty awesome working with the Phase One gear.
Having a truly metric camera really opens up a whole new world of high precision applications.
More than happy to share my research with you when it’s all wrapped up.
I can share the datasets too if that’s of interest to you.
I found that even the P4P with its short focal length worked well at these ranges. I needed to be so close as I had a custom 3D calibration frame manufactured and in order to have it cover a significant portion of each image, I had to be close. The re-projection RMS was ~0.4pix which seems to be about right for the P4P when comparing to other papers.
You could certainly (and preferably in many cases) perform the calibration over a larger area and with the camera at a higher altitude.
However for repeatability over a period of months, I felt the only option was a rigid 3D frame.
Great point regarding the scale bars. For my research project I did not use GNSS at all. Unsurprisingly, at such a close range, the photogrammetry model exceeded the precision of my scale bars, which I estimated to have a precision of 1mm.
The scale bars were simply measured multiple times with a Class 1 tape measure. They were ~1.6m in length, ie. almost the entire length of the frame.
This was only meant to be the first phase of my research project. Phase two was to perform 30 repeat surveys of civil works (recently completed land subdivision) to assess the repeatability of precision at more typical flying heights. But this got cancelled due to COVID and so I had to just go into deeper detail regarding the close range calibrations.
It took me a long time to come across the info that GCP’s or scale bars aren’t actually required at all for the pre-calibration.
I re-ran the calibration with all scale bars included in the bundle adjustment and the resultant camera parameters were almost identical…ie. with a strong imaging network etc, the calibration does not require GCP’s or scale bars.
“One of the merits of fully automatic camera self-calibration is that in can be carried out without the need for an object point array of accurately known 3D coordinates. Indeed no prior information on target positions is needed and nor is object space scale. If required, nominally true scale can generally be set from knowledge of the coded target size. The question then arises as to whether the provision of independently surveyed coordinate data for the points forming the target field is useful, and the answer has to be: not really. Where object point coordinates are known it can be reassuring to quantify the quality of the calibration through an accuracy check of triangulated object points against the control points, but with very strong network geometry, one can expect this to yield little further information than is gained via checks between multiple independent calibrations. A good deal of expense in cost and time is involved in setting up and maintaining surveyed control point arrays, and it is reassuring to know that they are not needed for automated camera calibration.”
AUTOMATIC CAMERA CALIBRATION IN CLOSE-RANGE PHOTOGRAMMETRY - Clive Fraser
Hi Nathan, thanks for your overview, really interesting input. So I understand your method, but what about the “pos.event” file generated when processing M+ logs. Are we saying here that that the position logged is inaccurate, so the only useful piece of data is the precise GPST?
I don’t think there’s a logged position of the “events”; there’s only a logged time. The position of the rover may be accurate from RTK, but only at 5Hz or 10Hz. The photos are never taken exactly at the moment of a 10Hz observation, and the M+ does not interpolate positioning live. That interpolation only happens in post-processing.
The pos.event file only comes from RTKLIB post-processing, and that is an interpolation of the post-processed observations.
You could develop a workflow where you use the accurate LLH positions logged (that’s a separate log) and then extract the timestamps from the .ubx in order to interpolate between the closest events. By the time you go to that work though, you may as well post-process the entire dataset.
We’re mapping a series of small rivers, streams and their embankments over a period of 10 months. Some have limited access points, the take-off and landing zones are going to be restrictive and gaining access permission troublesome, thus being able to set out ground targets unlikely. The areas to be mapped are typically long and thin, so 20m wide x 600m long, up to 40m wide by 1000m long. We will be able to use the government CORS network for NTRIP, so I’m confident we can achieve a very accurate base position, and if possible one, perhaps at best two GCPs using another RS2 with LoRA to the RS2 base. This is a location for on of the streams/rivers # 22°28’42.5"N 114°02’18.0"E
You will need some checkpoints along the way, just so you can prove to your customer that your results are accurate. These small strips are prone to warping and bending, especially when we are talking about the 1 km one. I would also suggest to have some control points, like 5 pr 1 km when using PPK.
As @TB_RTK mentioned, then PPK doesn’t solve all problems. You still some pretty imprecise encoders on a platform like the P4P. Usally I get errors from 4-7 degrees with the scene is referenced to ground by plenty GCP’s.
With PPK, the resultant accuracies of the antenna position are typically between 1-4cm. Flying with a multirotor that uses a gimbal will add additional positional error unless the “lever-arm” offsets are used in the post-processing process. That error is on the order of 15cm for an aircraft like the DJI P4P.
This strip “warping” and “bending” is can be entirely avoided by using a pre-calibrated camera with known internal parameters (F, PX, PY, C1, C2, C3, T1, T2). With single-strip coverage, control will still be needed to reduce the roll error. I also fully agree with using checkpoints to determine the real error.
The main requirement for Reach M+ is a hot shoe connection to a drone camera. DJI Phantom 4 Pro v2 camera doesn’t provide hot-shoe access, so there’s no easy way to integrate the receiver with it. I’m afraid that the only alternative is to use GCPs for precise mapping.
I’d like to notice that Reach M+ supports UAV mapping in PPK only. If you connect it to the drone’s camera hot shoe, Reach can provide you with centimeter-accurate coordinates in PPK. In such a case, you don’t need to place many GCPs, as they just can help you to verify the accuracy.
Thanks for your input. We’re using P4P’s modified with the Teoboard/M+ PPK system. This triggers the camera and provides the event.pos file from the M+ log
Good point. Yes, I have the measurements for the camera offset, so we’ve got that covered. Camera calibration is something which we need to implement so I’ve been reading through the documentation James provided.
I just want to make sure you really have that covered, because the X/Y shift of the antenna will not be embedded anywhere in the EXIF, and it will be entirely vairable based on the tilt of the platform. If it’s a gimballed system, the photogrammetry software will be unable to estimate it either.
