Drawing drone trajectory on an orthomosiac
We perform a trajectory estimation followed by projection into the mosaic’s coordinate system. From the previous implementation to generate an orthomosaic, one can derive an approximate path from the transformations it already computes—without adding DROID-SLAM or another reconstruction engine. Some of the criteria that this drawing must meet is that different routes even in the same drone tour over the same survey area must result in two shapes. For example, if the drone follows the same ground track twice, the two paths should overlap. If the actual routes differ or when they are deliberately displaced, the two paths are concentric. The follows steps explain the implementation followed by illustration of results.
1. Re-use the transformations already in the generate_orthomosaic script
The script already computes:
A cumulative transformation for each sampled frame.
A canvas translation that moves everything into positive image coordinates.
The final mosaic using those same transformations.
So, a compatible method is:
Take the center of each video frame.
Transform that point into the mosaic canvas.
Preserve chronological order.
Draw a solid black polyline through those transformed points.
For frame i:
Here, Α_i is the cumulative frame-to-reference transformation, and Τ_canvas is the translation returned by compute_canvas_size(). These are the same coordinate mappings your code uses to warp the images. OpenCV supports applying those mappings to points as well as images.
For a stable, nearly nadir camera, this gives an approximate trace of the camera’s ground-view center. It should be labeled an image-derived ground-track estimate. Camera tilt, an off-center principal point, parallax, and alignment errors can move the trace away from the true vertically projected drone position.
Where to integrate it
In the stitch_frames() function, we draw the trajectory after this call:
mosaic = build_mosaic(
frame_paths,
transforms,
width,
height,
translation
)
Drawing afterward prevents later frame warps from covering the black line. Our existing variables already provide the required coordinate mappings.
2. Fix rejected-frame handling before trusting the path
The current tracking code has one issue: when matching fails, it appends the previous cumulative transformation but advances prev_gray to the rejected frame. That can misplace the next successfully matched frame because the stored global transform and the matching reference no longer correspond to the same image. This is now changed to:
Keeping the last successfully registered frame as the matching reference.
Marking rejected frames as having no valid position.
Matching subsequent frames against that last accepted reference, with appropriate quality checks.
Breaking the displayed line across unresolved tracking gaps rather than drawing a misleadinging connection.
Otherwise, an attractive black path could conceal tracking failures already present in the mosaic.
3. Detecting two passes requires revisit detection
Drawing the path and identifying separate survey passes are different tasks.
To detect that the drone has returned to previously observed ground, we use:
Nonadjacent frame matching to find candidate revisits.
Geometric verification to reject look-alike roofs or roads.
Loop-closure constraints connecting the revisited frames.
Global optimization of frame transformations.
Loop closure uses revisited locations to reduce accumulated trajectory drift and improve map consistency. Simply chaining consecutive transformations provides no equivalent global correction.
This matters for our desired visualization: two separated loops could otherwise be tracking drift rather than two genuinely different routes.
Both the mosaic and the overlaid path should use optimized transformations. Correcting only the line would make it inconsistent with the imagery.
4. How to show repeated loops
Situation Appropriate display
Two genuinely different, nested routes Two nested black loops at their estimated positions
Same route flown twice Overlapping black lines
Same route, different altitude Generally overlapping ground-track lines; altitude needs another encoding
Both coincident passes visible Separate per-pass images, or individually labeled display offsets
If we deliberately offset coincident passes to show two concentric shapes, we must keep the original trajectory unchanged and label the result “offset for visibility.” It should not be presented as evidence that the drone flew two spatially separated routes.
A solid black line alone cannot preserve visit count at identical locations. Store the underlying samples with fields such as:
timestamp, frame_index, mosaic_x, mosaic_y, tracking_valid, pass_id
Final solution
What the replacement changes
The script:
Transforms each accepted frame’s center using the same cumulative transformation and canvas translation used to place its imagery.
Draws the black line after all mosaic images have been placed.
Keeps the last successfully registered frame as the matching reference when a subsequent frame fails.
Excludes rejected frames instead of assigning them fabricated repeated positions.
Breaks the path across failed-tracking intervals rather than connecting across unknown positions.
Exports coordinates, timestamps when available, registration status, inlier counts, and rejection reasons to CSV.
No comments:
Post a Comment