Programação de drones e VANT

O que está incluso na programação de drones

Escrevemos a lógica de missões autônomas de VANT e configuramos o controlador de voo no equipamento do cliente: o drone continua sendo dele, nós preparamos o firmware, as rotas e o comportamento no ar. O trabalho inclui o planejamento de rotas de aerofotografia e de sobrevoo de objetos, a definição de pontos de interesse para inspeção, a calibração dos sensores, dos modos de falha e das geofences. Configuramos o stack PX4 ou ArduPilot para o frame, o gimbal e a carga útil específicos, conectamos a telemetria por MAVLink à estação de solo. À parte configuramos os cenários de retorno à base, o comportamento em caso de perda de conexão e de perda de satélites, para que o aparelho não entre em voo descontrolado. A programação de drones nesse nível não é montagem de hardware, mas configuração do piloto automático e escrita das missões que esse piloto automático executa.

Como funciona a missão autônoma

Na base está o controlador de voo com piloto automático, que lê o GPS, os sensores inerciais, o barômetro e a bússola, e mantém o aparelho na trajetória definida. A missão é descrita como uma sequência de waypoints com altitude, velocidade e ações em cada ponto: tirar uma foto, pairar, girar o gimbal, mudar de altitude. A estação de solo e o piloto automático trocam comandos e telemetria pelo protocolo MAVLink, por isso o operador vê a posição, a carga e o status em tempo real. Os algoritmos de estabilização e navegação recalculam os sinais de controle para os motores dezenas de vezes por segundo, mantendo o rumo com vento e deriva. A nossa parte é montar esse cenário, definir os parâmetros e os limiares de acionamento de modo que o aparelho do cliente execute a rota de forma previsível.

De onde surgiram os pilotos automáticos de drones

Os pilotos automáticos abertos modernos surgiram de dois projetos do fim dos anos 2000. A comunidade DIY Drones apareceu em maio de 2007, e Jordi Muñoz ainda no fim de 2007 escreveu para Arduino um programa de estabilização do qual cresceu o ArduPilot — a versão 1.0 ele lançou junto com Chris Anderson em 2009, e nesse mesmo ano o seu aparelho venceu a primeira competição Sparkfun AVC. Em paralelo, na Suíça, Lorenz Meier lançou no ETH Zurich o projeto de pesquisa Pixhawk: por volta de 2008 começaram os trabalhos, e em 2009 saíram os primeiros desenvolvimentos abertos de controle e visão computacional. Por volta de 2011 a equipe de Meier reescreveu o stack do zero — assim surgiu o PX4 na forma que serviu de base à plataforma atual. Essas duas linhas, ArduPilot e PX4, é que definem hoje a prática de programação de drones.

Por que software e precisão decidem

A aerofotografia e a inspeção dão um resultado aproveitável apenas com georreferenciamento preciso: um erro de posicionamento de alguns metros desloca o ortofotomosaico e estraga a construção do modelo 3D. A precisão da missão é definida pela configuração do piloto automático — calibração dos sensores, parâmetros do filtro de navegação, geometria correta da rota com sobreposição dos quadros. Não menos importante é a legalidade: geofences corretamente definidas, limites de altitude e o comportamento em caso de perda de conexão mantêm o aparelho na zona permitida e reduzem o risco de infração e de acidente. O drone fisicamente voa e captura sozinho, mas a qualidade dos dados e a segurança do voo são determinadas pelo programa e pela sua configuração, e não só pelas características do frame e da câmera. Por isso um erro em um único parâmetro de tolerância a falhas custa mais caro do que a escolha do próprio hardware.

Stack: PX4, ArduPilot, MAVLink

O stack de trabalho se constrói em torno de dois pilotos automáticos e um protocolo de transporte. O PX4 — arquitetura modular sobre tempo real, conveniente para integrar módulos próprios e visão computacional; o ArduPilot — stack maduro, com amplo suporte a tipos de aparelhos e lógica desenvolvida de missões e falhas. O MAVLink liga o piloto automático à estação de solo e a módulos externos: mensagens binárias compactas transportam telemetria, comandos e parâmetros de missão pelo canal de rádio. Sobre isso trabalhamos com estações de solo do tipo QGroundControl e Mission Planner, e para o controle programático nos conectamos ao piloto automático por comandos MAVLink. A escolha específica entre PX4 e ArduPilot é ditada pela tarefa do cliente e pelo seu controlador, e não por hábito — para ambas as plataformas escrevemos missões e ajustamos parâmetros no equipamento dele.

Quando surgiram as principais ferramentas

O protocolo MAVLink foi desenvolvido por Lorenz Meier no ETH Zurich e lançado sob licença LGPL em 2009 no âmbito do projeto Pixhawk. O ArduPilot ganhou suporte a MAVLink nas primeiras versões beta de 2011, e o PX4 o incluiu no lançamento, por volta de março de 2012; nessa mesma época a estação de solo QGroundControl adotou o MAVLink. Em 2017 saiu a versão MAVLink 2.0 — ela acrescentou a assinatura de mensagens para proteção contra falsificação de comandos e pacotes ampliados até 280 bytes. O próprio PX4 como plataforma independente se formou após a reescrita completa do stack Pixhawk em 2011, quando também se adotou como base o RTOS NuttX. Essas datas importam na prática: elas definem quais versões de firmware e de mensagens considerar como referência ao configurar o piloto automático do cliente.

Por que se pode confiar a tarefa a nós

A experiência combinada da nossa equipe de desenvolvimento em TI ultrapassa 45 anos, e o piloto automático, para nós, é antes de tudo software e a sua configuração, e não mágica de hardware. Abordamos a missão como tarefa de engenharia: fixamos os parâmetros, controlamos as versões de firmware e verificamos o comportamento do aparelho em simulação e no solo antes do voo de verdade. Os cenários de falha, as geofences e o retorno à base são testados antes, para que o primeiro voo real não seja a checagem de hipóteses. Não fabricamos drones e não passamos equipamento de terceiros como nosso — programamos e configuramos o equipamento do cliente, apoiados em PX4, ArduPilot e MAVLink. No fim o cliente recebe não uma promessa, mas uma configuração reproduzível, que pode ser verificada pelos logs e repetida nos próximos aparelhos.