This is a practical issue for operators mixing DJI aircraft with PX4 or ArduPilot fleets. In a 3 November practitioner article for Commercial UAV News, the operators behind Pro4Aerials argue for planning from required ground detail and overlap before choosing a manufacturer's app. That is useful field advice, although the authors also sell planning software and the article is not an independent comparative trial. The underlying engineering can be checked against QGroundControl's survey documentation, ArduPilot's mission-camera interface and PX4's camera-trigger documentation.
What the survey must preserve
A job specification should be independent of the aircraft that executes it. It needs a polygon or corridor, an acceptable ground sampling distance (GSD), image overlap, position-control requirements and an inspection or mapping deliverable. Those are constraints on the data. A route file is one possible implementation.
A camera's image footprint varies with height, focal length and sensor dimensions. For a nominal downward-facing camera looking at approximately flat terrain, a useful pinhole approximation is:
[ W_{ground} \approx H \frac{W_{sensor}}{f}, \qquad GSD \approx \frac{W_{ground}}{N_{pixels}} ]
Here (H) is camera height above the imaged surface, (W_{sensor}) is the sensor width, (f) is focal length and (N_{pixels}) is image width in pixels. Real lenses, oblique views and terrain relief require more careful calibration, but the approximation is sufficient to expose why identical altitudes on two aircraft need not yield identical pixel size.
Consider an explicitly hypothetical camera with a 13.2 mm-wide sensor, 8.8 mm focal length and a 4,000-pixel-wide photograph. At 60 m above a flat surface, its nominal footprint is 90 m across, giving a 2.25 cm GSD. Changing to a camera with a narrower field of view at the same height changes both the footprint and the pixel size. The mission must be recalculated, even when every original waypoint still lies inside the survey polygon.
The QGroundControl survey planner makes the connection explicit: it requests sensor dimensions, image dimensions and lens focal length for a custom camera, and lets the operator choose either survey altitude or ground resolution. Its manual-camera mode instead asks for spacing and trigger distance directly. These are different ways to express a geometrical contract.
Overlap determines both track separation and camera workload
Image overlap is a two-dimensional requirement. Along-track overlap tells the planner how far the aircraft can travel between exposures. Side overlap governs the spacing between adjacent flight lines.
Using a rectangular nadir footprint as an approximation:
[ d_{trigger}=L_{footprint}(1-o_{front}),\qquad d_{lines}=W_{footprint}(1-o_{side}) ]
The overlap fractions are between zero and one. A 60 m along-track footprint with an 80% forward-overlap target implies a 12 m trigger distance. A new camera that covers only 45 m in that direction would need 9 m trigger spacing to hold the same percentage.
The next constraint is time. At a steady ground speed of 8 m/s, a 12 m trigger distance requests a frame every 1.5 seconds. A camera that cannot sustain that cadence will produce less overlap than planned. If the shortest practical interval is two seconds, the aircraft travels 16 m between exposures and actual along-track overlap drops to about 73% for the same 60 m footprint. Those figures are a worked hypothetical example, not the results of a particular camera test.
ArduPilot exposes a minimum camera interval parameter, CAM1_INTRVAL_MIN. PX4's trigger module likewise documents an interval limit alongside its distance-based modes. When exporting a survey, an operator must compare commanded trigger distance with actual aircraft speed and the camera's sustainable still-image cadence. Automatic exposure, raw capture, storage latency and fast turns can change the effective cadence.
A plan that silently drops exposures may still fly beautifully. Photogrammetry exposes the gaps later, as weak image matches or missing reconstruction.
The mission file preserves geometry, but often not behavior
MAVLink stores an explicit command and coordinate frame for each mission item. Its MISSION_ITEM_INT message definition differentiates geographic latitude/longitude fields from local coordinates, and the frame determines whether altitude is relative to home or referenced in another way. A route converter cannot assume that the same numeric altitude means the same vertical target.
The distinction grows across ecosystems. DJI's WPML specification represents global mission configuration and executable waylines in its own structure. DJI's flight-route importer expects a KMZ containing both wpmz/template.kml and wpmz/waylines.wpml. A GeoJSON polygon or KML overlay is valuable for exchange, but a map outline alone is not an executable, validated waypoint mission.
The action semantics also vary. ArduPilot's survey guide documents MAV_CMD_DO_SET_CAM_TRIGG_DIST, which starts a distance-based camera sequence and can be sent with zero distance to stop it. A route containing only navigation waypoints can therefore omit a crucial part of the image plan. PX4's flight-controller camera instructions require a compatible trigger interface and mode; its mission-controlled triggering is configured differently from a continuously running intervalometer.
For oblique building passes, the route must also preserve gimbal pitch, yaw reference, turn behavior and any stop-and-shoot instruction. Some commands point the camera relative to the aircraft; others use earth-referenced headings or points of interest. A viewer that displays the same waypoints cannot prove that the camera will look at the same facade.
Terrain relief can defeat a mathematically correct grid
The flat-ground calculation has a known weakness: height above takeoff is not height above the surface throughout the survey. QGroundControl's survey guide warns that its calculated overlap assumes terrain at roughly the home elevation unless terrain following is used. When ground rises under an aircraft at constant home-relative altitude, image footprint shrinks and overlap changes; clearance may also become unsafe.
Terrain following reduces that discrepancy if its surface model, resolution and vehicle behavior are appropriate. It cannot prove that the landscape is unchanged or that thin overhead objects are represented. In wooded or built-up terrain, the reference surface and the actual photographed surface may differ sharply.
This is especially important during a fleet change. One aircraft may use onboard terrain data, another ground-station terrain profiles and a third a fixed altitude from takeoff. The nominal track can be identical while the actual camera-to-surface height differs. A sensible hand-off records the vertical reference, terrain dataset, minimum clearance and the relationship between those quantities, then reviews the imported mission before flight.
Photograph position and map accuracy are separate tests
Pixel size describes image detail, not absolute map accuracy. A finely sampled orthomosaic can still be shifted or distorted if camera positions, calibration or ground controls are wrong. OpenDroneMap's high-precision workflow documentation describes supplying separate camera geolocation files and coordinate reference information rather than relying only on GPS coordinates embedded in photographs.
RTK and PPK can improve camera position estimates, but the survey still needs independent checkpoints if the output is a measured engineering deliverable. Ground-control accuracy, camera calibration, exposure timing and bundle-adjustment quality matter. A portable workflow should retain these controls across platform changes, even when a new drone advertises more precise onboard navigation.
Likewise, verifying that the camera triggered is not the same as verifying that a usable exposure was stored. The output audit should reconcile intended photo positions against actual image files, timestamps, quality and spatial coverage. The same check can reveal delayed captures, missing images or a camera pointing the wrong way.
A migration test that can actually fail
For a mixed fleet, the most useful predeployment test is a small known mapping job, with both aircraft evaluated against the same independently defined deliverable. This need not be a long experiment, but it must be set up to expose differences rather than merely confirm that both vehicles complete a path.
Record the camera intrinsics and planned GSD, then independently derive trigger spacing and transect separation. Export the mission to each ecosystem, read it back if the application permits, and compare the vertical frames, first survey altitude, camera action sequence, yaw, gimbal angles, speed and turn settings. Fly only under authorized, suitable conditions, starting with an open and low-consequence area.
After capture, compare the datasets: usable-image count against planned triggers, observed overlap, blur, gaps, camera-location metadata, checkpoint residuals and processing failures. Use the same quality criteria for both. If a newer aircraft gets better imagery but violates the speed or accuracy budget, the migration is not automatically successful. Nor is a completed mission evidence that the outputs are equivalent.
This also makes debugging more efficient. A gap in photo coverage can be traced to camera cadence, ground speed, grid geometry, trigger integration or terrain height, rather than to the vague conclusion that one drone brand maps worse.
Keep a platform-independent survey record
A robust reusable survey plan has two layers. The first is the desired result: site boundary, GSD, coverage, overlap, accuracy and safety envelope. The second is each aircraft's implementation: camera calibration, path coordinates and vertical frame, trigger mechanism, gimbal actions, mission format and failsafe settings.
The first layer can stay constant while the second changes. The Commercial UAV News practitioner's account is right to prioritize measurable image requirements rather than a memorized altitude, but the exact effort required to migrate a job is not established by one operator's experience. The official QGroundControl, ArduPilot, PX4, DJI and MAVLink documents show why conversion needs explicit verification.
A portable route gets an aircraft to the right places. A portable mapping workflow must also ensure it looks at the right surface, takes enough usable photographs and produces a dataset that passes the same independent quality checks.