Mark Smith
· 6 min read
AI checks every mission file before my drone flies
My consumer Mavic 3 has no SDK, so repeatable survey flights depend on mission files. An AI inspection caught unsafe defaults and a 22.88-metre altitude error before...

I am building a digital twin of our 1.5-acre property at Whangārei Heads. Every month, the same drone will fly the same paths and photograph the same land.
The processing pipeline will turn those photos into orthomosaics, elevation models, and a 3D model I can scrub through like a time machine. Change detection, weed surveillance, and a private vision-model benchmark will sit on top.
This week, Phase 1 shipped: the flights themselves.
Key takeaway
- The Mavic 3 has no supported software development kit for this workflow, so repeatable flights depend on DJI waypoint mission files.
- An AI inspection found unsafe return-to-home settings and a 22.88-metre altitude offset hidden by the planning interface.
- Three verified missions captured 743 photos in 25 minutes, with flown altitudes matching the design to within about 30 centimetres.
- The mission files are the source of truth, not the drone controller.
The mission is a file#
The constraint that shaped everything is simple. DJI never released a supported software development kit (SDK) for the consumer Mavic 3 that the usual mapping tools can use. Litchi, Dronelink, and the other mapping apps cannot control it for this job.
The workaround is DJI Fly's own waypoint engine. It will fly a mission stored in DJI's Waypoint Markup Language (WPML) format.
So this is not an app integration. It is a file.
Plan the flight once, export the KMZ archive, load it on the controller, and the drone can fly the same path every month. For change detection, that gives me something valuable: a versionable source of truth that cannot drift because somebody moved a line in a user interface.

The east-to-west oblique mission follows fixed passes across the property.
But a file you cannot inspect is a liability. That is where this build became more interesting.
I planned the missions in a web tool. Before anything flew, Claude unzipped every export and read the raw WPML. It found three problems I would never have caught from the planner's interface.
The first inspection found unsafe defaults#
The exports silently discarded my safety settings.
I had selected return-to-home on completion. The exported file said noAction. Its signal-loss behaviour was set to hover.
That means the drone could sit in the air burning battery instead of returning home. Every export contained the same values, regardless of what the interface showed.
The repair was two values in the XML. The important part was not making the change once. The inspection now patches and verifies those values on every mission file that goes to the controller.
This is the first reason I want AI in the workflow. It does not need to trust the interface. It can inspect what the drone will actually execute.
The second inspection found a 22.88-metre error#
The planner also zeroed waypoint altitudes against the ground elevation of whichever corner the grid started from.
My two oblique passes started from opposite corners of a property with about 20 metres of fall. Flown as exported, the second pass would have flown 23 metres lower than its twin. At the northern boundary, it would have been about 11 metres above the ground.
Claude found the problem by comparing the terrain profiles in both files. It measured an offset of 22.88 metres, with a standard deviation under one metre.
That was not a cosmetic difference. It was a mission-level error hidden inside two files that looked correct in the planner.
The fix shifted every waypoint so all three missions share one altitude reference.

The north-to-south mission starts from the opposite side of the slope, which exposed the altitude-reference error.
Rebuilding altitude from elevation data#
We then rebuilt every altitude from real elevation data.
A surveyor had measured the take-off mark on our driveway at 32.5 metres above sea level. Claude pulled Land Information New Zealand (LINZ) elevation values for all 121 waypoints, anchored them to that surveyed mark, and rewrote the missions to hold a true 30 and 35 metres above ground across the slope.
The constant bias between the elevation model and the surveyed mark cancels out in the maths. That is exactly the sort of detail I want checked by something that does not get bored halfway through 121 waypoints.
What happened in the real flight#
Yesterday, the whole chain ran for real.
The drone captured 743 photos across three missions in 25 minutes. The Exchangeable Image File Format (EXIF) data tells the story:
- Shot interval: 2.0 seconds throughout.
- Flown altitude: 15.8 to 35.7 metres.
- Designed altitude: 16.0 to 35.6 metres.
The plan and the flight agree to within about 30 centimetres. That came from a consumer drone with no real-time kinematic positioning (RTK), referenced from a painted mark on the driveway.
The AI did not fly anything. It read files, compared numbers, and refused to trust a user interface.
That is where the useful value sits right now. It is not in the glamorous part of the job. It is in the inspection most people skip.
The file is the asset#
The missions, verification method, and full project plan live in a GitHub repository because the KMZ files are the asset now.
DJI proved the point during the build. A controller update wiped every saved mission and reset the camera to its factory defaults.
Restoring the setup took minutes because the source of truth was never the drone. It was the versioned mission files and the checks around them.
That changes how I think about automation hardware. The physical device may execute the work, but the durable value sits in the inspectable configuration, the verification rules, and the record of what actually happened.
What to do next#
If you are building a repeatable drone workflow, start with the files:
- Export the mission and inspect the raw values before loading it on the controller.
- Verify completion and signal-loss behaviour rather than trusting the planner's settings.
- Compare altitude references across every related mission.
- Anchor terrain-following calculations to a known point.
- Keep the mission files under version control and verify the flight using EXIF data.
Next post: WebODM on Azure turns 743 photos into the first map.
Sources and verification#
- DJI Mobile SDK supported products, checked 3 August 2026. DJI lists the Mavic 3 Enterprise Series and Mavic 3M, but not the consumer Mavic 3 used here.
- LINZ Data Service National Elevation group, checked 3 August 2026.
- Mission-file values, EXIF results, and field measurements come from my project records and the completed flights on 2 August 2026.
Mark Smith is Principal AI Strategist at Cloverbase. To discuss this article or work with me, contact me at Cloverbase.

Mark Smith
Principal AI Strategist · Microsoft MVP
Helping people build practical AI skill in the Intelligence Age.
More from nz365guy

Why I started NZ Ledger as open financial infrastructure
NZ Ledger is my plan for open-source financial infrastructure designed for people, AI agents, and New Zealand businesses.

We made four websites agent-ready with WebMCP
AI agents already visit our websites and interpret pages built for human eyes. This weekend, we gave all four sites a structured interface they can use safely.

Why My AI DevOps Team Runs on a Ralph Loop
My AI DevOps board looked frozen for twelve hours. The fix was not smarter orchestration, but a Ralph loop with real hard stops.
Discussion
Comments
Loading the discussion for this post.
Leave a comment
Your email stays private. If it matches a Gravatar account, your public avatar can appear after the comment is approved.