System calibration solves the intrinsic relation between elements of the sensor platform such as position of the GNSS antenna, the alignment of the laser with respect to the Inertial Measurement Unit (IMU) body frame, camera alignment to this same IMU body frame, intrinsic camera parameters such as principal point, focal length and so on.
We solve for these “static “parameters in our factory calibration processes. We have learned how to do this to a high degree of accuracy and these parameters (due to our rigid platform designs) hold exceptionally well over time.
Calibration vs. Characterizing Sensors
It is informative to note that we do not actually “calibrate” the sensors. Instead, we characterize all parameters and apply corrections using these parameters in our post-processing True View EVO workflows.
To understand this distinction, consider the process of sighting a rifle scope. For instance, If I fire a rifle at a target and carefully turn the azimuth and elevation adjustment screws until I am consistently hitting the bulls eye, I have calibrated the system. If, on the other hand, I note how far I am from the bulls eye but make no physical corrections, I am characterizing the error. I could still hit the bulls eye by using these parameters to aim at the appropriate place off the bulls eye.
This may seem pedantic, but it is actually important. Since we are characterizing rather than calibrating, we will need to keep track of these correction parameters. In a True View 3DISsystem, these data are automatically managed for you within our True View Reckon system.
What are Project Dynamic Errors?
Now usually if a project is flown and the data are not as accurate as desired, we will hear something such as “the system calibration is off.” However, this is usually not the true cause of project error.
What is really going on is some of the dynamic aspects of the specific flight are introducing error. These anomalies have nothing at all to do with calibration. For lack of a better term, I call them “Project Dynamic Errors” (PDE). The PDE variables with which we typically deal are:
- Vertical Bias – This is a systematic error in the average vertical value (Z value) of the data. Since this error is systematic, it can be removed if you know some reference points. These references are obtained from Ground Check Points (GCP) placed as part of the project preparation.
- GNSS X, Y, Z errors – This is time variant over the time of flight. Since UAS flights tend to be of short duration and local to the base station, it is not a huge contributor but it can still easily be in the 1 to 2 cm range. However, when you do multiple, overlapping flights, this becomes, as you can imagine, a dominate error. GNSS errors are exacerbated by the distance from the locus of the project and the base reference being used. This is why we strongly recommend you always use a local, physical base station as a reference.
- IMU error – The roll, pitch and heading are estimated by the IMU post-processing software (POSPac, in our case). Roll and Pitch are pretty good (technically because they live in a non-inertial reference frame so they can be computed from the gravity vector). Heading, however, is the big issue since there is no horizontal acceleration unless the drone makes some turning maneuver (hence a jigger every 500m of flight line, etc. recommendation). As a side note, it is heading that dominates error when we look at points collected far from nadir.
- Blunders – these are errors associated with mistakes. Examples include incorrect antenna heights, moving a GNSS antenna on the sUAS without adjusting the lever arm parameters, not properly leveling survey poles, misreading coordinates, incorrect geoid½ You get the idea! This can be a fairly long list. The best way to mitigate blunders is to very carefully follow a written checklist.
The errors we see in nearly all project data are due to the above project dynamic errors, not sensor calibration. Of course, the question arises as to how to deal with PDE.
How to Deal with PDE
The very first thing to do is check for blunders. If these are not evident, begin to suspect PDE. We have found that the calibration on our True View 3DIS holds extremely well over time and hence most observed project errors are due to project dynamic errors such as GNSS and IMU drift. These errors are inherent to all airborne sensors and cannot be “calibrated out”; they must be corrected on a case by case basis.
For most projects, they are sufficiently small that no post-process correction is required (other than debiasing the vertical). On those occasions where it is necessary to correct for these errors, we recommend either Terrasolid’ s “TerraMatch” or Bayes Mapping’s “StripAlign” to perform these project corrections. Both of these tools, along with training, can be purchased from GeoCue. In addition, we offer geometric correction as a processing service for those customers who do not wish to internalize this process.