Product Solution Description
We propose a photogrammetric solution that leverages Structure-from-Motion (SfM) to recover camera
poses from the UAV images and thereby geolocate each photo and features within it. In practice, the
pipeline would extract robust local features (e.g. SIFT or ORB) from each image and match these between
overlapping frames. Matching can be accelerated using a vocabulary-tree (Bag-of-Words) strategy as in
COLMAP or DBoW2, which is efficient for large image sets. Matched feature tracks are triangulated to
obtain sparse 3D points, then bundle adjustment optimizes all camera intrinsics and extrinsics jointly. This
yields a consistent local 3D reconstruction (camera centers and orientations) up to scale. At that point, we
align the reconstructed model to real-world coordinates using the known GPS of the first image – effectively
treating it as a ground control point (GCP). By fixing the first camera’s position (and optionally its altitude),
we impose scale and translation on the model. The remaining cameras then inherit georeferenced positions
and orientations. Finally, once camera poses are in geographic (lat/lon) coordinates, we can map any image
pixel to a ground location (for example by intersecting the camera ray with a flat-earth plane or a DEM),
yielding object coordinates. This photogrammetric approach – similar to open-source pipelines like
OpenSfM or COLMAP – is standard in aerial mapping.
Figure: A fixed-wing UAV used for mapping missions (western Ukraine). Our pipeline would run after image
capture: features are matched across images and bundle-adjusted to recover camera poses. With this approach,
even without onboard GPS for every shot, the relative poses and scale are determined by image overlap. We
would calibrate the ADTi2625 camera (intrinsics and distortion) beforehand to reduce error. Robust
estimators (RANSAC) would reject bad feature matches, ensuring that outlier shifts or low-overlap frames
do not derail reconstruction. We could cluster images into connected groups if sharp turns break the
overlap graph. The use of well-tested SfM libraries (COLMAP, OpenSfM, OpenMVG) provides mature
implementations of these steps. For example, COLMAP’s documented workflow finds matching image pairs
via a BoW index and then performs incremental reconstruction with bundle adjustment. OpenSfM (used in
OpenDroneMap) similarly allows feeding a known GPS point or GCP to align the model. In short, our
solution cores on feature-based SfM to register the images and recover a 3D scene structure, then projects
it to GPS space via the first image’s coordinate.
Architecture Approach
Our system would ingest a batch of up to ~3000 sequential images and run an automated SfM pipeline,
with the following stages:
1. Preprocessing: Load camera intrinsics (from prior calibration or manufacture data). Optionally undistort
images.
2. Feature Detection & Matching: Extract scale-invariant keypoints (SIFT/SURF or fast alternatives) from
each image. Use a vocabulary-tree or sequential matching scheme to find overlapping image pairs. Since
images are sequential, we can match each image to its immediate neighbors (and perhaps to any non-
consecutive images if turns induce overlap). Matching uses KD-tree or FLANN and RANSAC to filter outliers.
3. Pose Estimation (SfM): Seed an incremental SfM: start with the first two images to get a relative pose,
then add images one by one, solving P3P + RANSAC and triangulating new points. If the flight path breaks
1
into disconnected segments, process each segment separately. After all images are added, run a global
bundle adjustment (using Ceres or COLMAP’s solver) to refine all camera poses and 3D points jointly. We
aim for a mean reprojection error < 1 pixel , indicating a good fit.
4. Georeferencing: Take the optimized reconstruction (which is in an arbitrary coordinate frame) and
transform it to geodetic coordinates. We set the first camera’s recovered position to the known GPS
coordinate (latitude, longitude, altitude). This defines a similarity transform (scale, rotation, translation)
from the SfM frame to WGS84. If altitude or scale is still ambiguous, we can use the UAV’s known altitude or
average GSD to fix scale. We may also use two or more tie-points if available (for example, match image
content to known map features) to constrain orientation. In practice, OpenSfM allows “anchor” points: its
alignment step uses any GCPs to move the reconstruction so observed points align with GPS . Here, even
one anchor (the first camera) fixes the origin and scale, while leaving a yaw uncertainty. To reduce
orientation error, we could match large-scale features (roads, fields) visible in images against a base map to
pin down rotation.
5. Object Geolocation: With each camera pose (now in lat/lon) known, any pixel can be projected onto the
terrain. For example, using a flat-ground assumption or DEM, compute where a ray through that pixel
meets ground. This gives GPS coordinates for image features (craters, fields, etc.). For higher accuracy,
multi-view triangulation of distinct points in the 3D point cloud can refine object coordinates.
Throughout this architecture, we include robustness measures: skip image pairs that fail to match (these
get flagged as “unregistered” and can be handled manually); use robust solvers to ignore mismatches; and
allow segments to be processed independently if turns break connectivity. Manual correction fallback would
be supported by exporting partial models and images to a GIS interface (e.g. QGIS or a WebODM viewer),
where an analyst can add ground control points or manually adjust a segment’s alignment if automated
registration fails for some images. All processing is implemented in optimized C++/Python libraries (OpenCV
for features, COLMAP/OpenSfM for SfM, and GDAL/PROJ for coordinate transforms) so that the time cost
stays within ~2 seconds per image on modern hardware.
Testing Strategy
We will validate performance against the acceptance criteria using a combination of real data and simulated
tests. Functionally, we can run the pipeline on annotated test flights (where the true camera GPS or object
locations are known) and measure errors. For image center accuracy, we compare the computed center
coordinates to ground truth. We expect ≥80% of images to be within 50 m and ≥60% within 20 m of true
position; we will compute these statistics from test flights and tune the pipeline (e.g. match thresholds,
bundle adjustment weighting) if needed. For object positioning, we can place synthetic targets or use
identifiable landmarks (with known GPS) in the imagery, then verify the projected locations. We will also
track the image registration rate (percent of images successfully included with valid poses) and the mean
reprojection error. The latter is a standard photogrammetry metric – values under ~1 pixel are considered
“good” – so we will confirm our reconstructions meet this. Testing under outlier conditions (e.g.
randomly dropping image overlaps, adding false images) will ensure the system correctly rejects bad data
and flags segments for manual review.
Non-functional tests include timing and scalability: we will measure end-to-end processing time on large
flights (3000 images) and optimize parallel processing to meet the 2 s/image target. Robustness testing will
include flights with sharp turns and low-overlap segments to ensure >95% images can still register (with the
remainder caught by the manual fallback UI). We will also simulate partial failures (e.g. missing first image
GPS) to verify the system gracefully alerts the operator. Throughout, we will log bundle-adjustment
residuals and enforce reprojection-error thresholds . Any detected failure (e.g. large error) triggers user
notification to apply manual corrections (e.g. adding an extra GCP or adjusting a segment’s yaw). By
benchmarking on known datasets and gradually introducing perturbations, we can validate that our
pipeline meets the specified accuracy and robustness requirements.
References: Standard open-source photogrammetry tools (e.g. COLMAP, OpenSfM, OpenDroneMap)
implement the SfM and georeferencing steps described . Computer-vision texts note that mean
reprojection error should be ≲1 pixel for a good bundle adjustment fit . These principles and practices
underlie our solution.
