That distinction matters most when the aircraft is moving, the camera has appreciable shutter latency, or the mapping workflow assigns positions from a flight log after landing. A timing fault is not the same problem as a poor GNSS fix, and adding more control points does not automatically diagnose it. PX4's camera documentation explicitly distinguishes a trigger event from camera capture feedback; ArduPilot's Mission Planner guide documents both log-message and clock-offset geotagging paths.
The aircraft can know when it asked, not when the image happened
A typical camera mission has several observable events. The autopilot decides that an image is due. It sends an electrical pulse or a protocol command. The camera receives that instruction, operates its shutter or electronic exposure sequence, and eventually writes the image and its metadata. These are related events, but they are not necessarily simultaneous.
PX4's camera architecture illustrates the consequence. A camera-trigger module publishes a timestamp for the request. When a camera capture input is configured, a separate capture driver can publish a feedback timestamp for a physical signal from the camera. The camera feedback module then uses the appropriate event to associate the image with vehicle position. Without physical feedback, the system is relying on the trigger time as a proxy for exposure.
A hot-shoe or other camera-provided capture signal can improve the association, but its electrical edge must genuinely correspond to the exposure event of interest. Wiring a generic camera-ready output into the capture input would not establish that relationship. Voltage compatibility, polarity, shutter mode and camera documentation are part of the integration, not peripheral details. The PX4 camera configuration instructions describe capture-pin feedback and its voltage considerations; supported output assignments vary with the controller and firmware.
A short delay becomes a displacement along the flight path
The first-order effect is straightforward: aircraft ground speed multiplied by the time offset. At 10 metres per second, a 100-millisecond association error corresponds to roughly one metre of travel. This is an illustrative geometric calculation, not a measured error for a particular drone, camera or mapping package.
Real processing is more complicated. The ground projected into an oblique or tilted image depends on aircraft attitude, lens geometry and terrain. A fixed camera lever arm shifts the sensor from the navigation antenna, and a time-varying gimbal can change its pointing direction. A timestamp shift combined with a turn may therefore produce neither a neat constant translation nor an easily spotted one-metre offset.
The useful distinction is between delay and uncertainty. A repeatable delay can often be calibrated if the event being timed is known. Unpredictable shutter latency or an image sequence that occasionally skips a feedback message is harder: one universal offset cannot recover which position belongs to every exposure. Inspect the interval distribution, not just its average.
Keep the event order and the clock domains separate
A flight log commonly contains a time measured since the controller started, and may contain a UTC or GPS-related time. The camera may embed a wall-clock EXIF date, while a ground station may maintain its own clock. Matching identical-looking numbers across those domains without an explicit synchronization step is unsafe.
PX4's camera-capture message definition distinguishes a timestamp since system start, a UTC/GPS capture time and an image sequence number. A successful timing workflow needs to establish which clock generated each field and how it was synchronized, not merely whether the photo has latitude and longitude tags.
Mission Planner's geotagging procedure offers two approaches. CAM messages can be matched to photographs captured under autopilot triggering, and a shutter-lag field is provided. Alternatively, an estimated offset between the camera's internal clock and the flight log can be applied. The documentation warns that the offset estimate is only a starting point and that image-count discrepancies can stop the CAM-message process.
For a survey, count and order matter. Compare the number of stored images, trigger events and capture feedback events before using the coordinates. Check whether numbering restarts after a camera reboot or pauses when the camera is busy. Even a perfect clock calibration cannot repair a photo-to-event match that slips by one frame without identifying the mismatch.
Rolling shutter adds time inside the photograph
A global shutter exposes the frame together in the relevant sense. With a rolling electronic shutter, successive rows are exposed at different times. A single timestamp is then a reference for an image whose geometry was collected over a readout interval.
That produces another failure mode. If the drone translates or rotates while the sensor is scanned, straight features may shift or lean in the image. The correction needs a credible model of camera motion and the readout time. It should not be confused with correcting a fixed delay between autopilot trigger and the start of exposure.
OpenDroneMap maintains an independent RSCalibration project describing how a flashing LED can reveal rolling-shutter row timing. Its rolling-shutter-readout parameter allows an explicit sensor readout duration instead of a database lookup. A database value or a result measured with one capture mode should not automatically be applied to another resolution, crop, electronic-shutter configuration or firmware state.
This is also why a photograph can look sharp enough for an operator while still containing motion-dependent geometry errors relevant to photogrammetry. Image sharpness, correct camera geolocation and correct per-row readout modeling answer different questions.
Ground control can constrain the result without proving timing was right
Ground control points are valuable constraints on an aerial reconstruction. They are not, by themselves, proof that each photograph was assigned the true shutter-time vehicle pose. Bundle adjustment can sometimes absorb incorrect position priors, yielding a surface that aligns acceptably near the controls while retaining distortion elsewhere.
A useful verification design therefore separates fitting from assessment. Put independently surveyed checkpoints outside the set used to constrain the model. Compare their errors across flight directions and over different portions of the block. An along-track bias that reverses with direction is worth investigating as a timing signature, though wind, attitude, camera calibration and trajectory processing can also contribute. No single pattern proves the cause.
Do not try to infer sub-decimetre mapping performance from a manufacturer's RTK accuracy specification alone. The survey chain also includes antenna-to-camera lever arm, camera orientation, timing association, calibration, control-network quality and reconstruction settings. Those terms have to be tested together.
A practical acceptance test before the large survey
Start with an observable event path on the ground. Confirm what the camera's physical feedback means, whether the flight controller logs it, and whether feedback stops when a photograph fails to save. Confirm the pulse's electrical compatibility rather than assuming all trigger and hot-shoe circuits share the same voltage. Record the firmware, camera mode and relevant configuration along with the test.
Then run a short, permitted survey over features with independent known positions. Fly repeatable straight legs in opposing directions at a controlled speed, and include deliberate changes of speed or heading only when the operating environment permits. Preserve the raw photos and flight logs so that timing offsets can be tested without altering the original evidence. Match event counts before geotagging.
Process a baseline and an alternative with a documented time-offset assumption, changing one relevant variable at a time. Inspect positional and reprojection residuals, but also evaluate independent checkpoints. If rolling shutter is present, test an appropriate readout value separately from any whole-image shutter delay. A better visual mosaic alone does not settle whether the timing model is correct.
This is a proposed diagnostic method, not a report of a test performed for this article. Safety, lawful operating permissions and a reliable flight plan take precedence over trying to provoke errors in the air.
What the metadata ought to prove
A dependable dataset should let an analyst answer four questions: which photograph corresponds to which capture event; whether that event marks a command or a real exposure; which clock it used; and how that event was associated with the navigation solution. Where rolling shutter matters, there is a fifth question about the sensor readout interval.
The underlying issue is an evidence gap, not an excuse to distrust GNSS. A good navigation solution can still be paired with the wrong time. Before tightening a mapping accuracy claim, establish the shutter event, verify the clock conversion, check image-event alignment and test the reconstructed result against measurements withheld from fitting.