From 188a2b82edf4bafcba6ef450db6b09e35f7e7aec Mon Sep 17 00:00:00 2001 From: Eg0Ri4 Date: Mon, 3 Nov 2025 20:26:36 +0100 Subject: [PATCH] ChatGPT_Solution --- .gitignore | 1 + docs/01_solution/.DS_Store | Bin 10244 -> 0 bytes .../02_solution_draft/productDescription.md | 90 ++++++++++++++++++ 3 files changed, 91 insertions(+) create mode 100644 .gitignore delete mode 100644 docs/01_solution/.DS_Store create mode 100644 docs/01_solution/02_solution_draft/productDescription.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e43b0f9 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.DS_Store diff --git a/docs/01_solution/.DS_Store b/docs/01_solution/.DS_Store deleted file mode 100644 index 7ff4f018250858e9cea2cea1169df2366272cce5..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 10244 zcmeHNTWl0n7(U;$z^ol$S}8YKc4Yw@XzjM#3Ps#rxKvs}wxt(}b+GrQ%I zVhPcBOT3%tgG5Ci2^x(U0zqFiQDQU=i6j!D58{hYyr2>N&zxDHT#|;M@GvKt^Plsd z^PMy2oBx~XIa|gU>a$uEV^PMKOc%GRLfH)xZ|B!_N%B3s5rk*VW+uxrml;$FQoumK zK)^u2K)^u2z}?6IeY1Izi-ZmGfPsL4fPu>l@b^QME^ZUP9TC=hbx`JQ0mv4T+e=iY zeSn9F`ZnR)5n(+jjVX2y@S*Ux7!Yu3kMizh6TTf0R=^nqoWY+N{tgA+?1YPY-5CFY^g2D+C zC&`oKB6)kV-yTZ3DL3oXr!w1kt<|>8biSNQZ#DFx9(7uSZMiAK(lZ{w&~)n3-ELT# zJydUJEzR+;NzovOtK(E&vV3?rB$vi2Yq#|5GzTpE z1+h5zF9rvILqi@k^EF-5k(ug!v37>7#ARorrs%IRsu|!-f zICOZ*jL7`5is}`s6Kk7V9vhvi7MCbW>GbxT;TUOC?@T$px}_ObU)zwOx&2-Aq%7Ci zVd$Aqs2Js~R%$>WEtxrM_I-20VbSLbCO=9?Hf=nWHQe25OqRtQ;d!x;tbW$5(M`74 z8Xr;fTEgLZ56JR1?r+HGlnb{KUR+LqRI5V-`L`Lb3WZdsbti?BfGW$D%OO>3GgE2Z z^j)iJ$+fXPCsyt|OCOd)9rWA>XfclPg&P`WS^eg5K5=u(aW@U>*5zAj*dWVYPJb$+ zZyKUt&Lf&-*?X|$=a99U;o2FGjYsE&!<~GnI!)6xTJ-Fhvr59raGR|DNEp?yat6tV zo`q169Lq;wEU`!wV<(MsUdiJ)G%er3xBL?tW(!#jeKK1~v^Lw%USbE?r|dX8!A`N$ z>?}La{$Ll`pX@Jo2?bD4f;pIv3REJFDy%{+R$~n|q7`k}iZph@!~kr#7{)$4js18Q zFXI)wir4Wr-p2%1d|q*p*4UsXjgt`Y$Qz@QpMPwOrp9_DT}BRNl2o)I8qT&CDN~`#v|2=T0rUydDvx<3Ppu1 zDl3&*MJ*(qis~9=uA;J#sMJRqBPv&&e7ocS2X=;?qxiqTE@C2zpdx}YJct^K_jTBS zCN!gkV!i{N*oJQC=tDoABn7z0VFoxJ+GB&<(VSMpDU^h1UA7OdlyT^{a)BSbbc#+yIA_x0# z<#U)zW-QaT`snWRnjX94pcXI?Fc2^hFc2^hFmQ($C=l~T`T76aoB#fQhwd(zHeeuN z;QwF%g^kI^dYb8Gf2;Ge_9$IX(8Uw)HzKSDp^SIoe(yM*D*Rlr%=h_6OI~}z_l*ea j!3pQV$%@nb|NO^*yZsO@*#8InfA62@#vH=m*8Ts#z6tl9 diff --git a/docs/01_solution/02_solution_draft/productDescription.md b/docs/01_solution/02_solution_draft/productDescription.md new file mode 100644 index 0000000..d28de24 --- /dev/null +++ b/docs/01_solution/02_solution_draft/productDescription.md @@ -0,0 +1,90 @@ +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.