Project control strategies for high accuracy drone mapping
By Lewis Graham, GeoCue
Project control is a topic near and dear to anyone doing high accuracy mapping – project control. While this article won’t be giving you specific answers about how much and where to place control, it will provide you with useful guidelines. The main reason for this article is that a lot of work remains to be done by the UAV mapping industry in this area.
What is project control?
Project Control generally refers to marks in the “object” space being imaged (e.g. the ground) that can be measured in the collected data. These control marks are typically precisely measured, independently from the airborne sensor system. The most common approach is to use a global navigation satellite system (GNSS) rover referenced to a base station.
For imagery and high-resolution laser scanners such as GeoCue’s True View 515 and True View 6xx systems, marked points on the ground often suffice for both planimetric and 3D control. Of course, for vertical only, no image identifiable markings are needed. We often refer to deliberately placed marks that can been seen in sensor data as “signalised” control.
Figure 1 illustrates two different types of control marking. It also illustrates (via the crushed tile marker on the left) why, for many projects, it is a bad idea to use expensive control markers.
Figure 1: Examples of two ground control points.
Ground control points vs ground check points
Unfortunately, those versed in photogrammetry for many years refer to points that will be used to build a model and points that will be used to verify a model both as ground control points, or GCPs.
In fact, control points are brought into the modelling process to “tie” the sensor data to the ground, whereas “check” points are withheld from modelling and used only to verify the resultant models. To complicate matters, both acronyms are unfortunately “GCP”.
To distinguish the two types of points, we sometimes use the acronym “GKP” for checkpoints to ensure people know what we mean (as opposed to the more common term “withheld points”).
Laying out GCPs on a project site takes time, effort and planning that influences project logistics, and thus project designers attempt to minimise or even eliminate their use. The most common approach is to add so-called “direct geopositioning” to the drone sensor itself. This is effectively putting a GNSS L1/L2 rover on the drone, operating in either Real-Time Kinematic (RTK) or Post-Process Kinematic (PPK) mode (PPK being our recommended approach for a number of reasons).
Using direct geopositioning can, indeed, eliminate the need for ground control points (GCP) for controlling the model, but it does not eliminate the need to have checkpoints (GKP) around the site. At GeoCue, we always tend to overdo in the projects we design, since a GKP can be used as a control point (turning it into a GCP) should the need arise. The need may arise if the direct geopositioning system fails, the base station battery dies mid-project, there is no close CORS, and so forth.
Figure 2: Project check points for sensor testing.
You will not need as many check points for a lidar vertical dataset as you would for pure photogrammetry. (In a True View 3DIS, which has both a lidar and a camera sensor, the lidar is invariably used for vertical positioning.
The reason for this is subtle: a lidar system is a direct ranging device. Thus, if the system holds a good, steady range, any vertical error from control tends to follow the GNSS vertical error.
Photogrammetry is more complicated, as Z (vertical height) is derived rather than directly measured. Photogrammetry requires a calibrated camera, and that camera must hold calibration over the entire project, to derive Z (vertical heigh) by correlating the same object location in multiple images. The Z value is derived, not directly measured. Anywhere correlation is poor (e.g. vegetated areas), there is a high probability of vertical error (well, a lot more than just vertical – which is why we use lidar!).
Use a local base station
One bit of advice I find invariably good is this: use a local base station, set the antenna pole of the base station on an easy-to-see target, and make sure the target will be visible in the dataset you collect with the drone. This will give you a few options for tying the project to the ground, should anything go awry.
Example cases of control strategies
If I were doing a flight of 40 hectares (100 acres) with a True View 3DIS (meaning I am using lidar for vertical height), I would want to have five “signalised” check points; four near the project edges and one in the centre. These would be in addition to the aforementioned base station positioning. In addition, I would collect a few vertical only points. These are really easy – just “pogo” (prism pole) with the rover; no target needed. These vertical only points add a lot of confidence for vertically debiasing data (discussed below).
If, on the other hand, I were flying a P4 RTK or an M300 RTK with a Zenmuse P1, I would increase my control/check up to around eight to ten points, since photogrammetry tends to produce a weaker “uncontrolled” vertical network accuracy.
I always process with all points treated as check points, meaning they are not brought into the model (because I am lazy and don’t want to measure them). We typically use Agisoft Metashape for the photogrammetry portions of projects. During this stage we use our own camera calibration and the direct geopositioning results from our PPK processing in True View EVO (GeoCue’s processing software).
I then do an accuracy test using the software’s American Society for Photogrammetry and Remote Sensing (ASPRS)-compliant accuracy testing. If an unacceptable vertical bias is observed, I will test to see if it is systematic or “noise” by used a Standard Deviation of the Mean (SDOM) test. SDOM testing is included in True View EVO, so you won’t be required to dust off your old statistics book. If the SDOM test indicated systematic bias, I will use another tool in EVO to shift the point cloud data.
If we are conducting a photogrammetry-only project (e.g. using a P4 or P1) and everything goes awry, we use 75% of the GCP for true control (using the rather tedious workflow of measuring GCPs in Metashape) and use the remaining 25% to, once again, validate in EVO. In reality, we very seldom get in to this sort of trouble. It can happen if the base station fails and there is no suitable alternative. Fortunately, when you are running an EVO post-processing PPK flow, you can usually buy Trimble PP-RTX by the flight minute (right from within the software) and have a project solution, albeit with accuracy a bit degraded compared to a local base station.