QGC4QGIS

The Problem

Planning a drone survey means working in two places at once. The area of interest, the cadastral boundary, the road network and the terrain all live in QGIS, while the survey grid is drawn in QGroundControl on top of a generic satellite basemap with none of those layers in sight. The polygon ends up redrawn by hand inside the flight app, and the gap between what was designed and what will be flown only shows up during image processing, after the flight has already cost battery and travel time.

The second friction is the file format. QGroundControl writes .plan, Litchi reads .csv and .kml in the classic hub and .kmz in Hub 2, and DJI Fly uses WPML inside a .kmz renamed with the mission GUID. Each target has its own waypoint ceiling and its own way of handling altitude, and none of them warns you when the mission exceeds them: the classic Litchi hub converts an altitude of 0 m into 30 m and silently truncates anything outside the -200 to 500 m range.

The Solution

QGC4QGIS reimplements QGroundControl's survey grid generator (the SurveyComplexItem class) inside QGIS, with a live preview drawn over the project layers and export to the formats the flight apps actually accept. The polygon already in the project becomes a flight grid without leaving the program.

The dockable panel splits planning into five steps: pick the coverage polygon, pick the camera (from the built-in library or by entering sensor size, resolution and focal length), set flight altitude or GSD, tune the grid (overlaps, angle, turnaround, entry corner and a 90° cross grid) and export. Transects, photo capture centres and image footprints are redrawn on the map at every parameter change.

The same operations are registered as a Processing Provider (qgc4qgis), so grid generation and export can be chained in a graphical model or a script without going through the panel.

Fidelity to QGroundControl holds even where QGroundControl is limited. The plugin inherits two constraints from the original algorithm: concave polygons and polygons with holes are swept by their envelope, with no decomposition into convex subpolygons, and the conversion between flight altitude and GSD uses only sensor width and image width. Reproducing that behaviour is what guarantees that the .plan opened in QGC shows the same grid QGIS drew.

Key Features

Survey grid with the QGC parameters: side and front overlap, transect angle relative to North, turnaround distance so the aircraft stabilises outside the polygon, the corner where the sweep starts, and a perpendicular cross grid for surveys that need a double pass.

Camera and GSD coupled: changing the flight altitude recalculates the GSD and the other way round, preserving the optics of the chosen camera. The library ships with ready-made models and accepts a manual camera defined by sensor size, resolution and focal length.

Statistics before takeoff: covered area, total transect length, estimated photo count and flight time are computed in QGIS, with the footprints drawn over the project layers. This is where you find out the mission does not fit in a single battery.

Four export targets: native QGroundControl .plan, .csv and .kml for the classic Litchi Mission Hub, and WPML in a .kmz for DJI Fly, which Litchi Hub 2 also imports. One plan serves all three platforms.

DEM downloaded automatically: the plugin fetches Copernicus DEM GLO-30 for the mission area from the same Auterion endpoint QGroundControl queries, so the sampled altitudes match the ones QGC recalculates. The raster arrives loaded and selected in the project, with a configurable margin to cover the turnaround curves and the takeoff point.

Terrain mode converted to WPML: DJI Fly has no native terrain following in the format, so terrain-mode altitudes are converted to heights relative to the takeoff point, and the plugin warns when any of them ends up at or below zero.

Warnings where the apps stay silent: Litchi's 99 waypoint limit, DJI Fly's practical ceiling of 200, the 0 m to 30 m altitude conversion and the classic hub's altitude truncation become messages before export instead of surprises in the field. The photo trigger mode is checked as well, since without it the KML carries only the endpoints of each transect.

Seven algorithms in the Processing Toolbox: grid generation, photo capture centres, Copernicus DEM download and the four exporters, all as ordinary QGIS algorithms.

Qt6, QGIS 4 and no NumPy in the way: version 0.7.1 clears the 106 findings raised by the official repository's Qt6 check, with scoped enums and field types built according to the Qt version. DEM writing uses GDAL's native bindings without touching osgeo.gdal_array, which avoids the error raised by an extension compiled against NumPy 1.x in environments running NumPy 2.x.

Technology Stack

Python PyQGIS QGIS Processing Framework Qt5 / Qt6 QGroundControl (.plan) WPML / DJI Fly KML / KMZ Copernicus DEM GLO-30 GDAL

Impact

Planning stops being a drawing redone in the flight app and comes out of the same project that holds the area boundary, the cadastre and the terrain. Before takeoff you already know the photo count, the estimated flight time and whether the computed height above ground is workable, and the same mission goes on to QGroundControl, Litchi or DJI Fly without being replanned.

The plugin is at version 0.7.1, not experimental, licensed under GPL-3.0, and compatible with QGIS 3.34 through the 4.x series on both Qt5 and Qt6. The interface is written in English and ships with a Brazilian Portuguese translation applied automatically in pt-BR locales. Using the Copernicus DEM requires the attribution © Airbus Defence and Space GmbH.