O precedente BladeInsight
Um sistema comercial de inspeção autônoma de pás, com anos de campo, foi lido de ponta a ponta a partir do release compilado que a VCI tem em mãos. Este documento descreve como ele funciona e fecha com o confronto ponto a ponto contra a arquitetura do C1: onde os dois chegaram à mesma solução por caminhos independentes, e o que vale trazer.
O sistema da BladeInsight resolve o mesmo problema do C1, com a mesma tese central — a estrutura é a referência de navegação, não o satélite — mas com um sensor de duas ordens de grandeza mais caro. A convergência não é coincidência: em oito pontos de projeto os dois times chegaram à mesma solução sem se falar.
O valor deste estudo não está no que o vnext faz melhor por ter LiDAR 3D. Está no que ele aprendeu em campo, ao longo de anos, e deixou escrito em configuração — políticas, portões, modos de falha e mecanismos de contenção que o C1 vai encontrar do mesmo jeito e que não dependem de qual sensor está a bordo. Doze desses itens estão listados na seção 14, com o custo de adoção estimado.
01Por que estudar este sistema
O material analisado é o vnext, pacote ROS bi_robotics da BladeInsight
S.A. Ele existe na pasta do projeto porque é o software que rodou no minicomputador embarcado das
missões de inspeção que a VCI acompanhou — entre elas a TURBINA SS II-03, de novembro de 2025.
É um sistema comercial maduro: 23 processos coordenados, 40 e poucos cenários de teste automatizado nomeados a partir de falhas reais de campo, e um catálogo de parâmetros que carrega décadas-homem de ajuste fino. Ele responde exatamente à pergunta que o C1 está respondendo — inspecionar as três pás de um aerogerador sem cadastro prévio e sem RTK — e chegou lá antes.
O que segue é a descrição do processo antigo, na ordem em que ele acontece, e depois o confronto com o C1.
02Ficha do sistema
O payload próprio traz câmera Sony A5100 de 50 mm, gimbal SimpleBGC de dois eixos, o Ouster e uma
câmera de navegação. Rádio Ubiquiti dedicado. Tudo sob o namespace ROS /pd/.
A configuração vive em 26 arquivos YAML e 52 arquivos de launch, em texto puro. É de lá que vem a maior parte do que este documento afirma — não de engenharia reversa de binário, mas de leitura direta da política declarada.
03Como ele sobe
A partida é encadeada e verificada. Nada sobe em paralelo torcendo para dar certo.
crontab e ambiente
Um @reboot chama o script de partida, que resolve STARTUP_MODE
(flight, hitl ou simulation) e carrega ROS, SDK da DJI e driver do
Ouster. A revisão de hardware é lida de um YAML permanente e decide quais IDs de câmera, gimbal,
LiDAR e navcam existem. É o único ponto do software que conhece o hardware físico.
Orquestrador monta a lista
Um script Python de 1.300 linhas monta a sequência de comandos conforme o modo, grava os parâmetros do voo no servidor de parâmetros do ROS e acumula a lista de nós que o watchdog vai exigir.
Partida com condição de aceite
Cada processo sobe com um leitor de saída anexado. O seguinte só arranca quando uma
frase específica aparece na saída do anterior — "Waiting for survey to
start" para a percepção, "Activation successful" para o SDK da DJI. Sem frase
declarada, espera três segundos. Se algo passa de um minuto, a pilha inteira reinicia.
Gravador primeiro, watchdog por último
O gravador de dados é inserido na posição zero da fila, para não perder as transformações estáticas. O watchdog entra no fim, quando já sabe a lista completa de quem precisa estar vivo.
04O payload e os frames
A árvore de referenciais é onde percepção e navegação se encontram. A decisão de projeto mais importante do payload está nela:
A cadeia é base_link → gimbal_roll → gimbal_pitch → lidar_link → camera_link, e existe
um referencial dedicado para a interseção das três pás — o centro do rotor estimado. A correção do
SLAM aparece como a transformação map → odom, filtrada por passa-baixa.
O envelope do gimbal é uma tabela, não um par de limites
O curso estrutural é roll ±60° e pitch ±89°. Mas existe uma segunda tabela que descreve o envelope real, onde a câmera não aparece no próprio quadro nem colide com a estrutura — e ela é uma lista de faixas de pitch permitidas por grau de roll:
roll 0 → pitch de −74° a 89°
roll 3 a 6 → pitch de −65° a 89°
roll 21 → pitch de −60° a −40° E de −20° a 89° ← buraco no meio
roll 26 a 60 → pitch de −16° a 89°A navegação consulta esse envelope antes de aceitar um waypoint, não na hora de comandar o gimbal. A diferença é que o waypoint impossível nunca entra no plano.
05A cascata de percepção
Do momento em que o drone vê a torre até ter um modelo completo da turbina, roda uma cadeia de estimadores em que cada um alimenta o próximo. É a espinha do sistema.
Achar a torre
Clusteriza a nuvem com o campo de visão horizontal restrito a 90°, pontua cada agrupamento e escolhe o que parece torre. Exige pelo menos três anéis consecutivos do LiDAR consistentes com um cilindro.
raio aceito 0,5–6,5 m trava entre 15 e 35 mTravar posição e construir
Coleta amostras para um palpite inicial, trava, e passa a ajustar círculos anel a anel enquanto sobe. Um interpolador guarda a relação raio × altura, permitindo perguntar depois "qual o raio da torre a 60 m".
altura mínima válida 25 mConfiguração das pás, cedo
Ainda durante a subida decide se o rotor está em Y invertido (uma pá para baixo) ou Mercedes (uma para cima). Essa decisão muda o método de alinhamento da própria subida e a rota subsequente.
Parâmetros da turbina
Segmenta nacele e três pás, ajusta a direção de cada uma, calcula o ponto de interseção do rotor, a orientação da máquina e o ângulo de cada pá. Roda em duas passadas: grosseira e refinada.
RANSAC para cilindro, SVD para retas refinamento com timeout de 20 sPortão de domínio
Verifica se os três ângulos são coerentes entre si, se as distâncias raiz→interseção batem, e se o ângulo da pá de referência está dentro de 10° mais 5° de margem. Fora disso a missão para: o rotor precisa estar travado na posição combinada.
Perfis aerodinâmicos
Fatia a pá a cada 2 m e ajusta uma elipse a cada fatia, extraindo corda e espessura. Depois otimiza a sequência inteira: suaviza os centros com B-spline, limita a rotação de roll entre fatias vizinhas, corrige a primeira fatia — que sempre tem poucos pontos — e refina a última continuamente conforme a pá é revelada.
corda máx. 8 m espessura máx. 8 m trava com 2 perfisOnde a pá acaba
O problema mais delicado: a pá afina até sumir do sensor. Faz varredura de posição de −1 m a +2 m em passos de 10 cm, checando voxels ocupados num raio de 30 m, e declara a ponta quando dois perfis virtuais consecutivos foram sobrevoados sem retorno. Se falhar, o operador pode forçar.
Mapa, submapa e o "desconhecido"
O mapa de medida é um octree a 0,2 m. Existe também um mapa de voxels a 1,0 m, usado exclusivamente para planejamento e verificação de segurança — mais grosso de propósito, porque precisa ser rápido. Ele distingue voxel ocupado de voxel desconhecido, e por padrão só o ocupado bloqueia.
Ao começar o lado de uma pá, o sistema recorta um submapa: tira do mapa a torre, a nacele e as outras duas pás, deixando só a pá sob inspeção. Terminado o lado, o submapa é reintegrado.
06SLAM por etapa — o achado mais transferível
Não existe "SLAM ligado o tempo todo". Cada etapa da missão tem um modo e um método de alinhamento declarados em configuração. Esta tabela é, na opinião desta análise, o item mais valioso do sistema inteiro:
| Etapa | Modo | Alinhamento | Racional |
|---|---|---|---|
| Preparação | None | — | No solo, nada a alinhar. |
| Subida da torre | SLAM | GICP_CULL_Z | Cilindro sem feição vertical: a componente Z do casamento é descartada, porque ela não tem informação e só injeta ruído. |
| Subida (rotor Mercedes) | SLAM | GICP | Nessa configuração há pás na subida — aí existe feição em Z. |
| Aproximação da pá | SLAM | GICP | Geometria rica, mapeia e corrige. |
| Lado da pá | Map | — | Só mapeia. Não corrige pose. A pá se move ao vento; corrigir contra ela induziria deriva em vez de removê-la. |
| Ponta, bordo, cubo, pouso | None | — | SLAM desligado nas transições críticas. |
| Realinhamento | Align | GICP_ICP_N | Só corrige, não mapeia. Cascata: GICP grosso, depois ICP com normais. |
| Contorno da torre | SLAM | GICP | Circundando, geometria estável. |
Qualidade do alinhamento, e o que ele recusa
Cada correção passa por um verificador de estabilidade: exige três amostras válidas consecutivas, erro linear e angular abaixo do limiar, e uma atitude "razoável". Os estados de saída dizem tudo:
Quando não consegue, escalona: tenta realinhar cortando um raio pequeno; se falha, corta um raio maior e mais devagar; se falha de novo, reinicia a referência interna. Três tentativas com parâmetros progressivamente mais frouxos, nomeadas.
07A máquina de estados
Existem duas, sobrepostas, e a distinção entre elas é intencional: uma é o que o drone está fazendo, a outra é o que o operador vê.
16 estados de controle
INITIALIZE, TAKEOFF, LOCKINGTOWER, GOTONONMAPPEDHUB, GOTOMAPPEDHUB, SCANBLADESIDE, WAITINGREALIGNMENT, CORRUPTEDMAP, GOTOASP, LAND… Cada um é uma classe com setup, loop e wrap up.
23 passos reportados
Com status TODO / EM ANDAMENTO / CONCLUÍDO / FALHOU / PULADO, duração medida por passo, e pesos de progresso que somam exatamente 1,00 no caminho feliz.
Os pesos são reveladores porque mostram onde o tempo de missão realmente vai:
| Passo | Peso | Leitura |
|---|---|---|
| Inicialização + pronto para decolar | 0,02 | Checagens de solo. |
| Voar até a torre | 0,02 | Aproximação e trava. |
| Mapear a turbina | 0,12 | Subir e medir a máquina. |
| Seis varreduras de pá | 0,13 ×6 | 78% da missão. Duas passadas por pá, cada uma cobrindo um lado e um bordo. |
| Voltar ao ponto de partida | 0,06 | Retorno. |
| Troca de bateria, retomada, remapeamento | 0,05–0,08 | Caminhos infelizes, orçados à parte. |
Os 13 comandos do operador
Chama atenção quão pouco o operador pilota e quanto ele autoriza. Não existe comando de "vá para tal coordenada": existem permissões e desbloqueios sobre um plano que o sistema já tem.
08Do modelo ao setpoint
A cadeia que transforma perfis aerodinâmicos em movimento:
| Peça | O que faz |
|---|---|
| Estimador de waypoints | Converte a lista de perfis em waypoints. O ponto visado segue a política superfície nos lados, aresta nos bordos. |
| Otimizador | Reprocessa o caminho quando perfis são acrescentados ou removidos — o modelo muda enquanto a pá é sobrevoada. Mantém 0,5 m de pá à frente intocáveis, para não puxar o waypoint corrente debaixo do drone. |
| Estimador de fotos | Calcula os pontos de disparo a partir da corda local, do campo de visão e da sobreposição desejada de 40%. Emite duas listas: modo contínuo e modo com parada. |
| Estimador de atitude | Decide para onde o conjunto drone + gimbal olha. Subindo a torre, mantém o olhar no cubo. Troca de pá quando o desvio angular passa de 10°. |
| Planejador | RRT-Connect (OMPL) — só nas transições livres, contra o mapa de voxels de 1 m. Falha vira pausa com caminho inválido. |
| Calculador de setpoint | Roda a 15 Hz. Projeta a posição desejada e aplica três filtros independentes — distância, valor e direção — limitados por aceleração de 0,875 m/s² e velocidade de 4 m/s. |
⚙Detalhe técnico — uma nota de campo preservada no código▼
O parâmetro da tolerância de disparo carrega dois comentários sobrepostos, deixados por quem manteve o sistema:
# TODO: valor anterior era 0.1. Precisou mudar para 0.3 porque
# o drone estava travando nas inspeções.
# TODO: baixado de 0.3 para 0.1 de novo porque acreditamos que o
# bug de travar foi corrigido. Volte para 0.3 se não foi.É o tipo de registro que documenta um modo de falha real melhor do que qualquer especificação — e que só existe porque alguém voou o suficiente para encontrá-lo duas vezes.
09Câmera e fotografia
O nó de câmera não é um driver: é uma máquina de estados negociando com uma câmera de consumo por USB. Boa parte do esforço do sistema está aqui, e é um esforço que o C1 não terá de fazer, por usar a câmera do próprio drone.
As contramedidas, declaradas como parâmetros
- A foto disparada só aparece no buffer depois de mais duas serem tiradas — o código compensa esse atraso de pipeline.
- O zoom é relido depois de cada pedido, porque a câmera nem sempre chega ao valor comandado.
- O foco é predito em vez de relido a cada iteração, porque reler é lento.
- Um atraso obrigatório de 1,5 s depois de cada foto antes de mexer no zoom.
Rotinas pedidas pela navegação em pontos específicos do voo
- Zoom inicial, durante a transição para a pá.
- Meio da pá, que trava o foco em manual.
- Congelar exposição, após cinco fotos: fixa o ISO para o resto do lado, evitando variação entre fotos vizinhas.
- Lado escuro: compensação de +1,3 EV na face sombreada.
- Fim do lado: reseta foco e recolhe o que sobrou no buffer.
Verificação de cobertura a bordo
Um verificador reduz cada imagem dez vezes e calcula sobreposição contra a anterior. Um segundo, mais caro, projeta nuvem de pontos e exige 99% de cobertura do lado e 10% entre fotos consecutivas. Falha vira evento nomeado, não silêncio.
10Segurança em camadas
A superfície de segurança é grande e explícita. A melhor porta de entrada é uma mensagem chamada StateWatcherState: 70 sinalizadores booleanos que descrevem tudo o que o sistema sabe dar errado — de "GPS fraco" a "não consegue calcular perfis nesta pá", de "quase sem espaço em disco" a "LiDAR superaquecendo".
Proteção geométrica, em cinco camadas
- Contra o mapa — 4 m de qualquer ponto do modelo acumulado.
- Contra o LiDAR — 5 m do ponto mais próximo medido agora, independente do mapa.
- Auto-colisão — um nó dedicado remove da nuvem os retornos do próprio drone, usando malhas simplificadas do corpo, do braço e da placa. Sem isso, o drone dispararia a própria parada de emergência.
- Coluna de decolagem — um cilindro protegido de 30 m de altura e 5 m de raio sobre o ponto de partida.
- Bolhas de estado — 5 m antes de mapear, 2 m para reiniciar um estado, 20 m para reiniciar a inspeção.
A parada de segurança sabe como sair dela
| Estado | O que o operador pode fazer |
|---|---|
| Pode sair | Retomar direto. |
| Pode sair depois de mover | Assumir manual e afastar o drone primeiro. |
| Pode sair depois de esperar | Condição transitória — aguardar. |
| Não pode sair | Irrecuperável. Só pousar. |
O operador só recebe na tela o botão correspondente ao estado corrente. Não existe "tentar sair" e ver o que acontece.
O preditor de bateria aprende durante o próprio voo
Este é o mecanismo mais engenhoso do sistema e não depende de sensor nenhum. Ele mede o custo energético da missão em curso: quanto de bateria custou subir a torre, converte em percentual por metro, e estima o custo de cada lado de pá a partir dos lados já executados. Depois responde a duas perguntas antes de cada transição:
"Bateria suficiente para varrer mais N lados/bordos."
"Para executar o próximo estado e pousar com X% de margem,
o drone precisa de Y%. Bateria atual: Z%."Se a conta não fecha, ele pousa ou pede troca de bateria antes de começar o próximo lado — nunca no meio dele.
Térmica do sensor
A temperatura do LiDAR é lida pela API HTTP do próprio sensor. A 55 °C agenda uma passagem para repouso quando o drone estiver no solo, depois de um período de graça. A 64 °C força repouso imediato e irrecuperável.
11Dados e reprocessamento
Uma inspeção é um objeto de primeira classe: tem identificador, pasta, ciclo de vida e API HTTP própria no payload — criar, consultar, parar, medir tamanho, apagar fotos, apagar artefatos. Um serviço de extração empacota tudo e só então autoriza apagar os originais.
Além disso, a percepção grava conjuntos de depuração separados por subsistema: um para o localizador de ponta, um para os parâmetros da turbina, um para a compensação de atitude, um para o SLAM. Cada um tem um arquivo de execução correspondente que reexecuta aquele estágio isoladamente. Qualquer falha de campo pode ser reproduzida em bancada, no estágio exato.
Os cenários de teste são o registro histórico das falhas
São mais de 40, e os nomes contam a história do produto:
E outros quinze nomeando turbina, data e número do voo — N149, E138, MM9, E82, G58, offshore — que validam a estimação de parâmetros contra dados reais de modelos diferentes de máquina.
12Confronto com o C1
Os dois sistemas resolvem o mesmo problema com orçamentos de sensor separados por duas ordens de grandeza. Vale ver onde a diferença de sensor realmente importa — e onde não importa nada.
13Onde os dois convergem
Oito pontos em que dois times, sem contato, chegaram à mesma solução. Convergência independente é o sinal mais confiável de que uma decisão de projeto está certa — vale mais do que argumento.
A estrutura é a referência
Nenhum dos dois se localiza por satélite. Ambos se localizam contra a máquina, que é o único objeto que interessa. O GPS é verificador nos dois.
Sempre pela raiz
Os dois abordam a pá pela raiz, e pela mesma razão: um desvio de azimute na parada do rotor desloca a ponta proporcionalmente ao raio. Perto do cubo o erro cabe no alcance do sensor.
Pose e medida separadas
O vnext mantém mapa de medida a 0,2 m e mapa de planejamento a 1,0 m. O C1 mantém nuvem de pose com downsample de 0,25 m e nuvem de medida em resolução cheia. Mesma ideia, inventada duas vezes.
Medida, não lida
Nos dois, a altura do cubo é definida pelo instante em que o retorno circular da torre deixa de aparecer. É a mesma definição operacional.
Círculo por RANSAC, eixo por ajuste de reta
Ajuste robusto de círculo em cada fatia e reta sobre a fila de centros para obter o eixo da torre. Idêntico nos dois, até no nome do algoritmo.
O ângulo entre as pás é a prova
O vnext rejeita se a pá de referência sai de 10°+5°. O C1 rejeita se o ângulo entre pás foge de 120° por mais de 3°, ou se o resíduo passa de 25 cm. Mesmo instinto: o rotor tem uma assinatura geométrica; se ela não fecha, o modelo está errado.
Nunca atravessar a estrutura
O vnext volta ao cubo entre pás e ordena as faces para que cada troca seja um quarto de volta. O C1 ordena intradorso → bordo de ataque → extradorso → bordo de fuga pela mesma razão: 90° de cada vez, nunca 180°.
Quem decide não voa
Nos dois, a camada de missão produz um setpoint e entrega ao controle de voo. Nenhuma delas comanda motor. É o que mantém a autoridade humana acima do software.
14O que dá para aproveitar
Doze itens, ordenados por relação entre valor e custo de adoção. Nenhum deles depende de trocar o sensor: são políticas, registros e portões que o C1 pode adotar como está.
Não corrigir pose contra a pá
críticocusto: decisão de projetoO vnext desliga a correção de pose enquanto varre o lado de uma pá — mapeia, mas não se corrige contra ela. A razão é que a pá não é um marco fixo do mundo: ela flexiona ao vento, e casar varreduras contra um alvo que se move injeta deriva em vez de removê-la.
No C1 essa condição é mais severa, não menos. Na fase FA o drone segue a pá a 6 m; a essa distância a torre em geral já saiu dos 8 m de alcance, e a fatia contém só a seção da pá — cerca de 26 pontos, oito depois do downsample de 0,25 m. Uma seção de pá é localmente lisa e alongada: ela restringe muito bem a distância lateral e quase nada o deslocamento ao longo do próprio eixo. É o problema da abertura, na forma clássica.
Definir o metadado da foto antes de voar
críticocusto: baixoCada foto do vnext carrega pá, face, distância ao ponto visado, distância do ponto à raiz, corda e espessura locais, pose da câmera e mm/px. Isso transforma 232 arquivos num laudo endereçável: "trinca a 34 m da raiz, extradorso da pá 2, GSD 0,9 mm/px".
O custo de não fazer isso já está medido: a análise da SS II-03 precisou reconstruir pá e face a partir de nomes de pasta e EXIF, e a distância à raiz simplesmente não existe naquele conjunto.
Preditor de bateria que aprende no voo
alto valorcusto: baixoMedir o custo em bateria da subida da torre, convertê-lo em percentual por metro, e estimar o custo de cada pá a partir das já executadas. Antes de cada transição, responder: dá para fazer a próxima e ainda pousar com margem?
Promover as 44 etapas a máquina de estados reportável
alto valorcusto: médioO C1 já tem as 44 etapas descritas na narrativa da missão. O vnext mostra o que se ganha ao torná-las um enumerado de verdade, com status por etapa (a fazer / em andamento / concluída / falhou / pulada), duração medida e pesos de progresso que somam 1,00.
Um bitfield de condições, não uma lista de erros
alto valorcusto: baixoEm vez de códigos de erro, o vnext publica 70 sinalizadores simultâneos. Vários são de interface e não de falha: pode apertar iniciar, controles de inspeção habilitados, botão de pousar habilitado. A UI não decide nada — ela reflete.
Gravar o dado bruto, não o processado
alto valorcusto: médioO vnext grava o pacote UDP cru do LiDAR e descarta a nuvem processada. Isso permite rejogar o voo inteiro contra uma versão nova do software. É a base de todo o resto do sistema de teste.
Cenários de teste nomeados por falha real
alto valorcusto: médioQuarenta cenários, quinze deles apontando para voos reais identificados por turbina, data e número. O nome do arquivo é o registro do problema: pá perdida durante a subida, travar a torre com uma pá na frente.
Duas medidas ou pare — em todas as fases
alto valorcusto: baixoO C1 já faz isso na F0: telêmetro e LiDAR discordando em mais de 0,5 m interrompem a aproximação. O vnext mantém a redundância o voo inteiro, com dois verificadores geométricos independentes — um contra o mapa acumulado (4 m) e outro contra a medida instantânea do LiDAR (5 m), sendo o instantâneo o mais conservador.
Verificar a cobertura fotográfica a bordo
valor médiocusto: médioO vnext exige 99% de cobertura da face e 10% de sobreposição entre fotos consecutivas, e falha com evento nomeado quando não atinge. O C1 calcula as 232 fotos geometricamente, mas ainda não fecha o laço verificando o que de fato saiu.
Escalonar o realinhamento em vez de desistir
valor médiocusto: baixoQuando o alinhamento falha, o vnext não aborta: tenta de novo com raio de corte maior e mais devagar, depois de novo reiniciando a referência interna. Três tentativas nomeadas, com parâmetros progressivamente mais frouxos, antes de escalar para o operador.
Envelope do gimbal como dado consultável
valor médiocusto: baixoO vnext modela o envelope do gimbal como faixas permitidas por grau de roll — incluindo buracos no meio — e consulta antes de aceitar um waypoint, não na hora de comandar.
Medir a térmica do sensor na bancada
valor médiocusto: baixoO vnext monitora a temperatura do Ouster e tem política declarada: repouso agendado a 55 °C, repouso imediato a 64 °C. Um LiDAR industrial de alto custo precisou disso.
15O que não copiar
Nem tudo no sistema antigo é lição. Quatro coisas em que o C1 está estruturalmente melhor e deve permanecer como está:
Decisões em que o projeto novo já está à frente
- Duas camadas, não 23 processos. A arquitetura do vnext é ROS distribuído com watchdog sobre 23 nós — necessária para uma equipe grande e um mini-PC, cara demais para um Raspberry Pi. A separação limpa entre odometria e lógica de missão é mais adequada e mais fácil de raciocinar.
- Usar a câmera do drone. Uma fração significativa do código do vnext existe só para domar uma câmera de consumo por USB — atraso de buffer, zoom que não obedece, foco lento. A H20 elimina esse problema inteiro por integração.
- Fotografar de 15 m. O vnext fotografa de 7,5 m porque a lente fixa não permite recuar. O C1 fotografa de 15 m com dois níveis de resolução da mesma estação — mais seguro e mais produtivo.
- Um portão humano, claro. O vnext distribui a autorização humana em vários pontos opcionais. O C1 concentra num portão obrigatório entre modelo e fotografia, com 400 bytes para revisar. É mais simples de operar e mais fácil de auditar.
E o que isso custa, honestamente
- Margem de reação. 40 m de alcance útil contra 8 m adotados. Não há como compensar isso com software — só com procedimento, que é o que o C1 já faz.
- Redundância de percepção. Nos dois o LiDAR é único, mas o vnext ainda tem o mapa acumulado como segunda opinião em qualquer instante do voo.
- Anos de campo destilados em parâmetros. Cada limiar do vnext foi ajustado contra falhas reais. Nenhum documento substitui isso — mas o item 07 é como se começa a construir o equivalente.
- Reprocessamento de voo formalizado. Cinco modos de execução, do simulador ao rejogo de bag de campo. É o que permite corrigir um bug e provar que ele foi corrigido contra o voo que o revelou.
16Ressalvas desta análise
O que é leitura direta
- Toda a configuração: 26 arquivos YAML e 52 arquivos de execução, em texto puro. Números, limiares e políticas são citação, não inferência.
- O protocolo com o solo: enumerados e identificadores de mensagem completos, gerados a partir do dialeto MAVLink próprio.
- As interfaces de dados: 81 mensagens, 12 serviços e uma ação, em texto.
- O orquestrador de partida e os processos em Python — código-fonte completo.
- A arquitetura de classes: os símbolos não foram removidos das bibliotecas, então as cerca de 180 classes de percepção e navegação são nominalmente conhecidas, junto com as mensagens de log.
O que é inferência
- A lógica dentro dos métodos C++ — deduzida de nomes, parâmetros e mensagens, não lida.
- A ordem exata de transições em falhas combinadas.
- As heurísticas internas de pontuação, como o critério que escolhe qual agrupamento é a torre.
O que não existe no material
- O código-fonte C++. Só o release compilado.
- Os módulos externos: bibliotecas comuns da BladeInsight, driver Ouster, SDK da DJI.
- A estação de solo de produção. Existe apenas uma interface de desenvolvimento.
- Qualquer registro de voo da SS II-03 — só as fotografias sobreviveram.