← Estudos técnicos

Como o drone navega, na prática

Os outros estudos tratam de geometria: onde está a torre, onde está o cubo, onde estão as pás. Este trata de máquina: quais peças conversam com quais, por que fios, em que ritmo, e o que roda dentro de cada uma. É o que separa um roteiro no papel de um drone que voa.

Rascunho de trabalho. Descreve a arquitetura pretendida e os números que decorrem dela. O que está marcado como “a medir na bancada” ainda não foi verificado em hardware.

1 · As três peças

Não há um computador só. São três, e cada um faz uma coisa que os outros não fazem.

O Pi é o único que decide. O C1 mede e não interpreta; o M300 executa e não sabe da turbina. Tudo o que é específico desta missão — reconhecer a torre, achar o cubo, escolher para onde ir — roda no Raspberry Pi, a bordo, sem depender de enlace com o solo.

2 · Os três fios, e o que cada um carrega

Parece detalhe de montagem, mas cada fio existe por um motivo diferente e a falta de qualquer um deles quebra uma coisa distinta.

Ligação	Carrega	Se faltar
USB C1 → Pi	As varreduras. Na porta de expansão do M300 os papéis do USB se invertem: a aeronave é o device e o Pi é o host. O tráfego IP passa por RNDIS, que faz o cabo se comportar como placa de rede.	Sem pontos. A missão não começa.
UART Pi ↔ M300	O protocolo do PSDK, nos dois sentidos: comandos de voo descem, pose e telemetria sobem. Dois fios e o terra, a 3,3 V, com TX e RX cruzados.	O Pi vira passageiro. O drone continua voando, mas ninguém o comanda.
PPS M300 → Pi	Um pulso elétrico por segundo, no início exato do segundo GNSS. Disciplina o relógio do Pi; o Pi então age como mestre PTP e acerta o relógio do C1.	Pose e nuvem deixam de compartilhar o mesmo relógio, e a nuvem borra. Ver a seção 5.

3 · Um ciclo, de ponta a ponta

A missão inteira é este ciclo repetido: dez vezes por segundo, do começo ao fim do voo. Cada volta tem 100 milissegundos para acontecer. Se atrasar, o próximo pacote de pontos chega antes de o anterior ter virado decisão.

1 / 8 — —

—

Situação

4 · O que roda dentro do Pi

Duas camadas, com responsabilidades separadas de propósito.

Camada de baixo — onde eu estou

FAST-LIO2, odometria LiDAR-inercial. Ela funde as varreduras do C1 com a IMU e devolve a pose — os seis números que dizem onde o drone está e para onde está virado. Não usa GPS. Compara cada varredura nova com o mapa acumulado e deduz o quanto o drone se moveu.

Duas nuvens, dois propósitos A mesma varredura é usada de dois jeitos, e confundir os dois é um erro comum.

A nuvem de pose passa por um downsample em grade de 0,25 m — sobra no máximo um ponto a cada 25 cm. Numa corda de pá de 2 m isso deixa 8 pontos. É grosseiro de propósito: só precisa ser bom o bastante para casar varreduras, e é o que faz a odometria caber no Raspberry Pi.

A nuvem de medida guarda tudo, na resolução cheia: a 6 m de afastamento, os pontos ficam a 7,5 cm um do outro, cerca de 26 numa corda de 2 m. É dela que sai o modelo da pá.

Camada de cima — para onde eu vou

A lógica da missão. Recebe a pose e a nuvem, e faz o que os outros estudos descrevem: separa o alvo do resto, ajusta o círculo, empilha os centros, compara com o afastamento desejado e produz uma correção. Aqui é onde vivem o RANSAC, o ajuste de esfera do spinner e os portões de qualidade.

O ponto arquitetural é que essa camada nunca comanda motor. Ela produz um setpoint — uma velocidade desejada — e entrega ao PSDK. Quem voa continua sendo o controle de voo do M300.

5 · O relógio, e por que ele é levado a sério

Cada ponto do LiDAR só vale alguma coisa se soubermos onde o drone estava no instante em que aquele ponto foi medido. Se o relógio do C1 e o do Pi discordarem, os pontos vão para o lugar errado e a nuvem borra.

Erro de relógio	a 0,3 m/s perfilando	a 0,5 m/s aproximando	a 1,5 m/s em trânsito
1 ms	0,03 cm	0,05 cm	0,15 cm
10 ms	0,3 cm	0,5 cm	1,5 cm
50 ms	1,5 cm	2,5 cm	7,5 cm
100 ms	3,0 cm	5,0 cm	15,0 cm

A referência para julgar esses valores é o espaçamento entre pontos na própria superfície: 7,5 cm a 6 m de afastamento. Acima de uns 10 ms de erro, o borrão passa a competir com a resolução do sensor — mede-se pior por causa do relógio, não do LiDAR. É por isso que existe um fio só para o PPS.

6 · O que a missão pede ao PSDK

O PSDK é o conjunto de funções que a DJI expõe para um payload embarcado. A missão usa poucas, e vale saber quais, porque cada uma tem uma condição de uso.

Recurso	Para quê	Condição
Autoridade de controle	Passar a comandar o voo	Tem de ser pedida e concedida. O operador pode retomá-la a qualquer momento.
Comando de velocidade	Mandar o drone se deslocar	Enviado continuamente. Parar de enviar é um comando por si só — ver a seção 7.
Leitura de pose	Posição, atitude e estado do GNSS	Sempre disponível, e usada como apoio à odometria, não como fonte principal.
Sincronismo de tempo	PPS, para carimbar os pontos	Pino dedicado na porta de expansão.
Controle do gimbal	A varredura da etapa 1 da missão	Limite de inclinação para cima: +30°.
Telêmetro da H20	Medir a torre antes de o C1 alcançar	Mede um ponto só, o centro do quadro. Alcance de 1200 m.
Disparo da câmera	As 232 fotos	Com zoom comandado, dois níveis de resolução da mesma estação.
Canal MOP	Mandar o modelo ao operador	Banda limitada e compartilhada com o vídeo.

7 · O que o M300 não deixa fazer

Vale conhecer as restrições agora, porque elas moldam o roteiro tanto quanto a geometria.

Sem autoridade, nada acontece. Os comandos são simplesmente ignorados até que a autoridade de controle seja concedida — e o operador a retoma quando quiser. Do ponto de vista da segurança, isso é uma qualidade: há sempre uma mão humana acima do software.
Parar de falar é um comando. O controle de voo espera comandos em fluxo contínuo. Se eles cessarem, ele não continua a última manobra: assume que o payload travou e passa a pairar. É o watchdog, e é o comportamento certo — mas significa que um travamento no Pi vira um drone parado no ar, não um drone perdido.
O drone tem opinião própria sobre obstáculos. O sistema de desvio do M300 continua ativo e pode frear por conta própria, inclusive contra o que o Pi está comandando. Conciliar as duas lógicas é item de bancada.
O gimbal não olha para cima além de 30°. Limite físico, e é ele que impede medir a altura do cubo com o telêmetro durante a subida.

8 · O que desce pelo rádio, e o que não desce

Esta é a decisão de arquitetura que mais economiza dor de cabeça.

	Volume	Caminho
Nuvem acumulada da missão	~114 MB	Fica no cartão do Pi. Não trafega.
Modelo enviado ao operador	~400 bytes	Canal MOP, para o app no controle remoto.

São cerca de 300 mil vezes menos dados. O que desce não é a nuvem: são os parâmetros do modelo — onde está o eixo, onde está o cubo, para onde a máquina aponta, onde estão as três raízes. O operador revisa isso e confirma; só então a fase fotográfica começa.

É por isso que o processamento é a bordo. Não é preferência de projeto: mandar 5.000 pontos por segundo por um rádio que também carrega vídeo não caberia. Processar no Pi e mandar 400 bytes cabe com folga — e ainda torna a missão imune a uma queda momentânea do enlace.

9 · O que a bancada precisa responder

O que está descrito acima é arquitetura pretendida. Cinco coisas só o ensaio decide:

O ciclo fecha em 100 ms? O orçamento da animação é uma estimativa. Se o FAST-LIO2 estourar o tempo no Raspberry Pi, ou se reduz a taxa, ou se agressiva o downsample, ou se troca de computador.
O alcance real do C1. Todo o acervo usa 8 m como cenário conservador. O glossário registra 12 m. A diferença muda tolerâncias em quase todos os estudos.
A extrínseca LiDAR–IMU–corpo. Precisa ser constante e conhecida. É o que justifica o berço rígido do sensor.
A deriva da odometria, pelo ensaio de fechamento de laço.
A convivência com o desvio de obstáculos do M300 — quem cede a quem, e em que condição.

← Estudos técnicos · A subida, passo a passo · Achar o centro do cubo · Glossário