Meu drone mantém 0,9% de deriva numa bolha de bloqueio de GPS. O código de que me orgulho é a linha que se recusa a voar.

Eu não esperava que a parte mais importante deste projeto fosse a parte que desiste.

Eu tinha passado a melhor parte de uma tarde encarando a repetição de um voo sintético. Um drone atravessa uma missão de 80 segundos ao longo de um trajeto de 245,3 m. O GPS se mantém nos primeiros 18 segundos e então morre quando a aeronave cruza uma bolha simulada de guerra eletrônica. Na tela, três trajetórias se abrem a partir daquele momento. Uma delas, uma linha rosa brilhante, se desvia em direção ao canto do mapa e continua, confiante e completamente errada, enquanto um pequeno indicador ao lado insiste que está tudo bem.

Aquela linha rosa é a odometria visual-inercial padrão, e vê-la mentir para mim foi o que mudou toda a forma do que eu estava construindo. Eu havia assumido que o problema difícil na navegação sem GPS era permanecer preciso. Não é. O problema difícil é saber, no único momento em que importa, que você não está.

Em espaço aéreo sem GPS, uma posição confiante-mas-errada é mais perigosa do que um honesto "eu não sei".

Esta é a história de construir Lodestar, nosso motor de integridade de navegação, e da semana que passei resolvendo o problema errado antes de entender o certo.

Eu corri atrás da precisão por uma semana antes de entender o problema real

Comecei onde a maioria das pessoas começa, que é com o estimador. A guerra eletrônica tornou o GPS não confiável exatamente nos lugares onde drones autônomos agora importam: espaço aéreo contestado, cavas de mineração, túneis, cânions urbanos. Bloqueio e spoofing em espaço aéreo contestado agora são amplamente reportados, comuns o bastante para que a navegação sem GPS tenha deixado de ser uma curiosidade de pesquisa e se tornado um requisito duro. A correção óbvia é acoplar odometria visual-inercial, fundir a câmera com os sensores inerciais e torcer para que a deriva continue pequena.

Então construí um EKF de VIO real, fortemente acoplado, e passei a primeira semana tornando-o preciso. O mesmo filtro, três configurações honestas: uma linha de base de IMU por dead-reckoning sem visão alguma, uma VIO padrão que funde cada característica visual que vê, e uma versão com consciência de integridade que é mais cuidadosa sobre em quais características acredita. Rodei todas contra uma verdade de referência que o simulador gera independentemente de cada estimador, para que nada pudesse corrigir o próprio dever de casa. A missão inteira tem seed fixa, reproduzível byte a byte, o que importou mais do que eu percebi na época.

Os números de precisão eram genuinamente bons. Através da bolha de bloqueio, o estimador com consciência de integridade mantém 0,92% de deriva, 2,26 m de erro final naquele trajeto de 245,3 m. O dead-reckoning, por comparação, explode para 30,95% de deriva e 75,92 m de erro final, que é a diferença entre pousar na plataforma e pousar no município vizinho. Fiquei satisfeito comigo mesmo por cerca de um dia.

Então rodei o comboio.

O que uma bolha de bloqueio faz a um drone que confia nos próprios olhos

Quero ser honesto sobre o quão ordinária parece a transição do GPS, porque essa é a parte que funciona. Quando o GPS cai em t=18 s, o filtro redistribui o peso para a fonte visual-inercial sem mudança de modo, sem alarme, sem costura visível ao operador. A estimativa simplesmente permanece contínua. Se você estivesse voando a missão, não sentiria o chão desaparecer.

Aqui está o que eu subestimei. Um drone rodando visão não falha piorando lentamente. Ele falha travando na coisa errada e reportando uma posição limpa e confiante que é simplesmente lixo. O estimador não sabe que foi enganado, porque a maquinaria que calcula a posição é a mesma maquinaria que teria de perceber que a posição está errada. Eu havia construído um sistema que era preciso até o momento em que estava catastroficamente, silenciosamente equivocado, e não tinha como distinguir os dois de dentro.

Isso não é um problema de ajuste fino. Não se resolve com ajuste um sistema que está confiante de estar errado. Eu precisava de algo que ficasse completamente fora do estimador.

O comboio que ensinou um bom estimador a mentir

Construí o cenário do comboio especificamente para quebrar meu próprio trabalho, e funcionou. Entre t=30 e t=43 uma coluna de veículos atravessa uma clareira de baixa textura, espalhando características espúrias que parecem, para um front-end de VIO faminto, exatamente como os marcos estáveis que ele quer rastrear. Esta é a falha documentada do ORB-SLAM3, aquela em que o algoritmo rastreia o caminhão e conclui que o drone está parado.

A VIO padrão caiu de vez. Na mesma execução com seed fixa, ela trava nos veículos em movimento e sai voando, terminando com 28,79% de deriva e 70,61 m de erro final, com um ATE de 32,95 m que é de fato pior do que não usar visão alguma. Aquela era a linha rosa que eu vinha observando. O detalhe feio é que, enquanto falhava, sua confiança interna parecia saudável. O estimador tinha certeza de si. Tinha certeza de uma posição que derivava em direção à borda do mapa.

O estimador com consciência de integridade sobrevive ao comboio por uma razão simples: ele se recusa a acreditar em características que pertencem a objetos em movimento. No quadro acima, o mascaramento semântico rejeitou as 10 características do comboio e manteve apenas as 2 estáticas, então o estimador nunca trava na coluna. A trajetória se mantém. Mas a parte que eu não antecipei é o que meu monitor de integridade fez no mesmo momento. Ele não pintou a tela de verde e fingiu que o mundo estava bem. Ele mudou para AMBER, porque com as características do comboio mascaradas havia genuinamente apenas um punhado de marcos estáticos restantes em que confiar. Ele estava preciso e estava nervoso, ao mesmo tempo, e disse isso.

Foi a primeira vez que o monitor me disse algo que o estimador não podia, e vale mais do que a precisão por si só. Também forçou a pergunta que eu vinha evitando.

Por que o estimador não pode simplesmente se certificar?

Passei um número embaraçoso de horas tentando responder isso com os próprios números do estimador. Minha primeira verificação de integridade simplesmente lia a incerteza reportada pelo filtro, o sigma de posição, e condicionava o voo a isso. Se a covariância parecia apertada, voar. Parecia razoável.

O comboio a demoliu. Quando a VIO padrão travou no caminhão, o sigma reportado permaneceu pequeno. O filtro estava confiante precisamente porque havia encontrado algo consistente para rastrear. A consistência era uma mentira, mas a covariância não podia saber disso, porque covariância é uma declaração que o estimador faz sobre si mesmo. Eu estava pedindo à testemunha que certificasse o próprio depoimento.

A confiança não deve depender da coisa em que se confia.

Aquela frase se tornou o design. O Monitor de Integridade de Navegação vive fora do estimador de propósito, como código separado respondendo a uma pergunta diferente. Não "qual é a minha posição", que o EKF responde, mas "esta posição pode ser confiada agora", que o EKF é estruturalmente incapaz de responder sobre si mesmo. O monitor funde três sinais em um estado GREEN, AMBER ou RED com limiares rígidos: contagem de características utilizáveis (GREEN em 8 ou mais, RED abaixo de 1), sigma de posição (GREEN abaixo de 0,6 m, RED acima de 1,5 m), e NIS de visão, a consistência de inovação qui-quadrado que captura exatamente o caso em que o estimador está confiante e errado (GREEN abaixo de 7,0, RED acima de 30,0). Nenhum número isolado pode ser manipulado pelo estimador, porque dois dos três não vêm da autoavaliação do próprio estimador.

Esta é a coisa em que agora acredito com mais força sobre autonomia crítica para segurança. Uma VIO melhor não corrige a falha confiante-mas-errada, porque "isto é confiável" é uma pergunta diferente de "o que é isto," e você não pode responder a primeira com a maquinaria que produziu a segunda. A indústria continua correndo para tornar o estimador mais inteligente. A arquitetura durável não é um estimador mais inteligente. É um monitor disposto a anulá-lo.

A linha de código que se recusa a voar

O momento em que de fato entendi meu próprio produto foi o túnel, e eu me lembro dele porque é o momento em que o sistema faz o mínimo.

Entre t=52 e t=66 a missão entra em um túnel escuro e as características visuais utilizáveis colapsam para essencialmente zero. Não há nada a ver. Nenhum estimador, por mais bem ajustado, pode fabricar uma posição confiável a partir de uma cena que não consegue observar. Isso não é uma falha a corrigir. É um fato a respeitar. A VIO padrão, ainda tentando, deriva para uma posição que não tem o direito de reivindicar.

O Lodestar faz outra coisa. As características morrem, a incerteza de posição cruza o limiar, e após 0,5 segundos de RED sustentado o monitor engata o failsafe e comanda o retorno para casa em t=52,5 s. Ele não blefa uma posição. Declara a estimativa não confiável e devolve o controle a um comportamento seguro, e faz isso de forma determinística, sem nenhum modelo no loop decidindo qualquer coisa.

Quero ser cuidadoso com os números aqui, porque a honestidade é toda a proposta. Nesta única missão com seed fixa, o monitor sinaliza o túnel genuinamente inobservável 100% das vezes e gera alarmes falsos no trecho saudável sem GPS cerca de 0,1% das vezes, mantendo GREEN em 56,3% do voo com GPS negado. Esses são os resultados desta missão, uma prova fiel à física do mecanismo, não uma garantia de teste de voo em mundo aberto. A afirmação durável é a estrutura: confiança calculada fora do estimador, RED sustentado até um retorno para casa engatado, abstenção honesta em uma cena que ninguém poderia navegar. Os metros exatos pertencem a esta execução. A arquitetura pertence a toda execução.

A linha de código mais valiosa em uma pilha de autonomia é a que se recusa a voar.

O que coloquei no relatório para que ninguém precise acreditar na minha palavra

Eu não queria que ninguém tivesse de confiar nas minhas capturas de tela, então a última coisa que construí é o recibo. Um clique exporta um Relatório de Integridade de Voo, JSON mais HTML imprimível, com o placar, as métricas de destaque, o acerto da abstenção, o tempo do failsafe, a linha do tempo de eventos e, a parte que mais me importa, uma divulgação explícita de escopo do que está stubado versus adiado.

Essa divulgação não é um aviso que eu enterro. É um recurso. O relatório declara claramente que o front-end visual é um substituto, que a fusão LiDAR é uma restrição de alcance simulada e não um fator LiDAR real, que a interface MAVLink e a vazão do Jetson não são exercitadas aqui, e que os 30-45 FPS em um Jetson Orin NX 16 GB é uma especificação de hardware-alvo, não um resultado medido. As 16.000 atualizações de propagação do EKF no relatório foram medidas na máquina da demo. Os FPS não foram, e o relatório diz isso nessas palavras.

Aquela execução com LiDAR vale a pena demorar porque é onde muitos demos trapaceariam. Ative o LiDAR simulado e o túnel se recupera: a restrição de alcance ancora a solução, a integridade se mantém, e nenhum failsafe dispara, porque a cena não é mais inobservável. Seria fácil mostrar só aquela execução e declarar o problema resolvido. Mas o relatório também carrega o custo que a página da solução admite, cerca de 250 a 400 g de carga útil e 8 a 12 W de potência. LiDAR é uma troca de engenharia real com uma conta real de SWaP-C, não uma vitória gratuita, e um comprador merece ver a conta ao lado do benefício.

Há exatamente um modelo em qualquer lugar perto deste sistema, um botão opcional que redige a narrativa de revisão técnica a partir do relatório estruturado. Ele roda inteiramente fora do loop de voo. Escreve prosa. Nunca toca em uma decisão de controle. O mecanismo que decide se voar é determinístico, com seed fixa e offline, e faria a chamada idêntica com o botão de narrativa arrancado. Fui firme nessa fronteira, porque o dia em que um modelo de linguagem ganha voto sobre se um drone confia na própria posição é um dia pelo qual eu não quero ser responsável.

Ao que continuo voltando

Eu parti para construir um drone que permanece preciso quando o GPS morre, e consegui, nesta missão, com menos de um por cento de deriva. O que eu não esperava era sair convencido de que a precisão era a metade fácil.

A precisão é uma corrida em que qualquer um pode entrar. Todo mundo neste campo está tornando o estimador um pouco mais apertado, as características um pouco mais densas, o backend um pouco mais inteligente, e tudo isso é bom trabalho. Mas nada disso responde à pergunta que de fato mata um drone em uma bolha de bloqueio, que não é "o quão errado estou" mas "estou em uma situação em que não posso saber o quão errado estou". Essa pergunta tem de ser feita de fora do estimador, por algo disposto a dizer a coisa sem glamour e entregar os controles.

A precisão é uma corrida em que qualquer um pode entrar. Um sistema que sabe quando está cego é o produto.

Você pode rodar tudo você mesmo e ver a linha rosa sair voando, depois ver o estado RED disparar, em veriprajna.com/pt-BR/demos/lodestar-autonomia-de-drones-sem-gps-que-sabe-quando-nao-pode. Tem seed fixa, então você verá exatamente o que eu vi.

E se preferir ver em vez de ler a minha descrição, aqui está a coisa toda rodando de ponta a ponta.

A pergunta que não parei de revolver é esta. Se o comportamento mais valioso na sua pilha de autonomia é a recusa de agir, quanto do seu orçamento de engenharia vai para a parte que desiste, e quanto para a parte que nunca aprendeu quando desistir?