
UAV Mission Planning & Automation System
Grid-based autonomous flight planner with battery-aware mission segmentation.
Problem
Manual waypoint planning for large survey areas is tedious and error-prone. I was using online FOV calculators to figure out ground coverage at different altitudes and camera angles, then clicking waypoints one by one in Mission Planner. For anything beyond a simple grid, I'd spend 20+ minutes planning, then realize halfway through the flight that I miscalculated overlap or didn't account for a battery swap.
Larger missions that needed multiple batteries were worse - I had to manually split the survey area, plan return-to-home points, and track where to resume. One mission I planned required four battery changes and took over an hour just to set up the waypoint files.
What I Built
A desktop application that generates complete survey missions from boundary polygons. You define the search area, set camera parameters and overlap requirements, and the system outputs a MAVLink .mission file with waypoints, camera triggers, and automatic battery swap handling.
The planner accounts for:
- Camera FOV and altitude to calculate ground coverage
- Front/side overlap percentages to determine grid spacing
- Drone battery capacity for auto-inserted RTH waypoints
- Video recording start/stop commands at segment boundaries
Technical Implementation
Grid Generation & Boundary Handling
The core algorithm generates a grid of parallel flight lines based on camera coverage and desired overlap. Horizontal and vertical FOV inputs (e.g., 70 x 50 degrees) combine with altitude to calculate the ground footprint dimensions. Grid spacing comes directly from those dimensions and the overlap percentages - 70% front overlap and 40% side overlap in practice.
Waypoints are clipped to the survey boundary using Shapely for polygon intersection checks. For severely concave boundaries, the system inserts additional waypoints at polygon edges to prevent the flight path from cutting across areas outside the boundary. Every waypoint falls inside the defined area.
Battery-Aware Mission Segmentation
The planner takes drone battery specs as input and calculates total mission time. When flight time exceeds battery capacity, it automatically inserts RTH waypoints at the threshold, then resumes from the last surveyed position after the battery swap.
On the mission I tested with four battery changes, the system correctly placed all RTH points and continuation waypoints. Total planning time went from over an hour to about five minutes.
Video Management
The app generates camera control commands in the mission file to stop recording right before each RTH sequence and restart when the drone returns to position. This keeps footage nearly seamless across battery swaps without manual intervention.
MAVLink Integration
Used DroneKit-Python and pymavlink for protocol handling. Missions export as .mission files with full MAVLink command sequences - waypoints, mode changes, camera triggers, and RTH actions. I tested generated missions by uploading them to Mission Planner and flying with ArduPilot. Everything executed as planned with no command errors.
UI & Visualization
Built with PyQt6 for offline capability - I needed this to work in the field without internet. The map view uses Folium embedded in QWebEngineView for interactive boundary drawing and flight path preview. The left sidebar shows a list of saved and imported missions, similar to a chat history interface. You can switch between missions to review or modify them.
Integrated ArduPilot SITL for pre-flight simulation testing, accessible through a "Start Simulator" button in the connection panel.
Key Challenges
Concave Boundary Edge Cases
Initially, the grid generator would create flight lines that technically stayed within the boundary at waypoint locations but crossed outside the polygon between waypoints. I added intersection point calculation so the path geometry actually follows the boundary edge, not just the individual GPS coordinates.
Natural Language Mission Planning (Abandoned Feature)
I attempted to add AI-driven boundary generation where you could describe a search area ("the park north of the river") and the system would interpret it and create the polygon automatically. Boundary interpretation was unreliable - the model would hallucinate locations or misunderstand spatial relationships. Removed it after repeated failures. Manual polygon drawing ended up faster and more accurate.
FOV-to-Grid Math Accuracy
Getting the overlap calculations right took iteration. The relationship between camera angle, altitude, and ground coverage has to account for lens distortion and gimbal tilt. I validated against real flight data to make sure the generated grids actually produced the intended overlap in captured imagery.
Results
The mission with four battery changes - covering a large survey area that would've been brutal to plan manually - took five minutes to generate and flew perfectly. The system placed RTH points correctly, resumed from the right positions, and the video segmentation worked as designed.
For typical single-battery missions, planning time dropped from 15-30 minutes to under a minute. The .mission files worked directly with Mission Planner and ArduPilot with no compatibility issues.
What I Learned
Battery-aware segmentation turned out to be more valuable than I expected. Being able to plan a multi-hour survey in minutes and trust that the battery swaps were accounted for changed how I approached larger projects.
The natural language feature failure reinforced that precise technical tasks need precise inputs. A boundary polygon drawn on a map is unambiguous. A text description isn't.
Offline capability was the right call - most survey sites don't have reliable internet, and depending on cloud services would've made the tool useless in the field.
Next Steps
Terrain-following altitude adjustment is the obvious next feature. Right now, missions fly at a fixed altitude above the home point. Integrating elevation data (likely SRTM) would allow the system to generate waypoints that maintain a constant altitude above ground level, which matters for camera resolution and coverage consistency in hilly terrain.