QGC4QGIS

O Problema

Quem planeja um levantamento com drone trabalha em dois lugares ao mesmo tempo. A área de interesse, o limite cadastral, a rede viária e o relevo estão no QGIS; a grade de voo é desenhada no QGroundControl, sobre uma imagem de satélite genérica e sem nenhuma dessas camadas. O polígono acaba redesenhado à mão dentro do aplicativo de voo, e a diferença entre o que foi projetado e o que será voado só aparece no processamento das imagens, quando o voo já custou bateria e deslocamento.

O segundo atrito é o formato. O QGroundControl grava .plan, o Litchi lê .csv e .kml no hub clássico e .kmz no Hub 2, e o DJI Fly usa WPML dentro de um .kmz renomeado com o GUID da missão. Cada destino tem seu próprio teto de waypoints e seu próprio jeito de tratar altitude, e nenhum deles avisa quando a missão os ultrapassa: o hub clássico do Litchi converte altura 0 m em 30 m e trunca qualquer altitude fora do intervalo de -200 a 500 m sem dizer nada.

A Solução

O QGC4QGIS reimplementa o gerador de grade do QGroundControl (a classe SurveyComplexItem) dentro do QGIS, com pré-visualização sobre as camadas do projeto e exportação para os formatos que os aplicativos de voo realmente aceitam. O polígono que já está no projeto vira grade de voo sem sair do programa.

O painel acoplável organiza o planejamento em cinco passos: escolher o polígono de cobertura, escolher a câmera (da biblioteca embutida ou informando sensor, resolução e distância focal), definir altura de voo ou GSD, ajustar a grade (sobreposições, ângulo, turnaround, canto de entrada e grade cruzada a 90°) e exportar. Os transectos, os centros de tomada de foto e as pegadas aparecem no mapa a cada mudança de parâmetro.

As mesmas operações estão registradas como um Processing Provider (qgc4qgis), o que permite encadear a geração da grade e a exportação em modelo gráfico ou script, sem passar pelo painel.

A fidelidade ao QGroundControl vale inclusive onde ele é limitado. O plugin herda duas restrições do algoritmo original: polígonos côncavos ou com furos são varridos pelo envelope, sem decomposição em subpolígonos convexos, e a conversão entre altura de voo e GSD usa apenas a largura do sensor e a largura da imagem. Reproduzir esse comportamento é o que garante que o .plan aberto no QGC mostre a mesma grade que o QGIS desenhou.

Funcionalidades Principais

Grade de voo com os parâmetros do QGC: sobreposição lateral e frontal, ângulo dos transectos em relação ao Norte, distância de turnaround para estabilizar a aeronave fora do polígono, canto de início da varredura e grade cruzada perpendicular para levantamentos que exigem dupla passagem.

Câmera e GSD acoplados: alterar a altura de voo recalcula o GSD e vice-versa, mantendo a relação óptica da câmera escolhida. A biblioteca traz modelos prontos e aceita uma câmera manual com sensor, resolução e distância focal informados.

Estatísticas antes do voo: área coberta, extensão total dos transectos, número estimado de fotos e tempo de voo são calculados no QGIS, com as pegadas desenhadas sobre as camadas do projeto. É onde se descobre que a missão não cabe em uma bateria.

Quatro destinos de exportação: .plan nativo do QGroundControl, .csv e .kml para o Litchi Mission Hub clássico, e WPML em .kmz para o DJI Fly, que o Hub 2 do Litchi também importa. Um mesmo planejamento atende às três plataformas.

DEM baixado automaticamente: o plugin busca o Copernicus DEM GLO-30 para a área da missão no mesmo endpoint da Auterion que o QGroundControl consulta, o que faz as altitudes amostradas coincidirem com as que o QGC recalcula. O raster chega carregado e selecionado no projeto, com margem configurável para cobrir as curvas de retorno e o ponto de decolagem.

Modo terreno convertido para o WPML: o DJI Fly não tem acompanhamento de relevo nativo no formato, então as alturas do modo terreno são convertidas para altura relativa ao ponto de decolagem, e o plugin avisa quando alguma delas fica igual ou menor que zero.

Avisos onde os aplicativos são silenciosos: o limite de 99 waypoints do Litchi, o teto prático de 200 do DJI Fly, a conversão de altura 0 m em 30 m e o truncamento de altitude do hub clássico viram mensagens antes da exportação, e não surpresa no campo. O modo de disparo por foto também é conferido, porque sem ele o KML carrega apenas as pontas de cada transecto.

Sete algoritmos na Caixa de Ferramentas: geração da grade, centros de tomada de foto, download do DEM Copernicus e os quatro exportadores, todos como algoritmos comuns do QGIS.

Qt6, QGIS 4 e nenhum NumPy no caminho: a versão 0.7.1 fecha as 106 ocorrências apontadas pela verificação Qt6 do repositório oficial, com enums escopados e tipos de campo montados conforme a versão do Qt. A gravação do DEM usa os bindings nativos da GDAL sem tocar em osgeo.gdal_array, o que evita o erro de extensão compilada contra NumPy 1.x em ambientes com NumPy 2.x.

Stack Tecnológica

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

Impacto

O planejamento deixa de ser um desenho refeito no aplicativo de voo e passa a sair do mesmo projeto onde estão o limite da área, o cadastro e o relevo. Antes de decolar já se sabe a quantidade de fotos, o tempo estimado e se a altura calculada sobre o terreno é viável, e a mesma missão segue para o QGroundControl, para o Litchi ou para o DJI Fly sem replanejamento.

O plugin está na versão 0.7.1, não experimental, sob licença GPL-3.0, compatível com QGIS 3.34 até a série 4.x em Qt5 e Qt6. A interface tem os textos originais em inglês e tradução para português do Brasil, aplicada automaticamente em locais pt-BR. O uso do Copernicus DEM exige a atribuição © Airbus Defence and Space GmbH.