Sincronização e erro de georreferenciamento em sensores pushbroom

Um sensor hiperespectral pushbroom registra uma linha do terreno por quadro. O movimento da aeronave fornece a segunda dimensão espacial do cubo. Para localizar cada amostra no solo, o georreferenciamento direto combina a geometria da câmera com a posição e a orientação da plataforma no instante da exposição.

A posição fornecida pelo sistema global de navegação por satélite (GNSS) resolve apenas parte desse problema. Um erro de orientação desloca a visada, e um erro de tempo associa a imagem à posição e à orientação de outro instante. A montagem acrescenta diferenças entre os referenciais da câmera e dos sensores de navegação. Por isso, escolher o receptor GNSS pela precisão nominal não basta para estimar o erro do produto.

O experimento do msi-hsi-sensor-sim comparou cinco arquiteturas para verificar quais atendiam a um requisito de erro horizontal radial de até cinco pixels no percentil 95 (P95). A arquitetura com navegação inercial industrial, GNSS com correção RTK, disparo por hardware e correção temporal por linha apresentou P95 simulado de 24,6 cm, equivalente a 2,4 pixels na escala adotada. Esse resultado é uma previsão de projeto, condicionada aos parâmetros do orçamento; ainda não foi validado em voo.

Geometria e escala do requisito

A comparação usou altitude de 100 m, velocidade de 3 m/s e objetiva de 19 mm. O detector IMX178 tem passo de pixel de 2,4 µm; o agrupamento espacial de oito pixels resultou em distância de amostragem no solo (GSD) transversal de 10,1 cm. A fenda de 35 µm correspondeu a 18,4 cm ao longo do voo. Para amostrar essa direção a cada 18,4 cm, o período entre quadros foi de 61,4 ms, ou 16,3 quadros/s.

O requisito de cinco pixels foi convertido em distância usando o GSD transversal: aproximadamente 51 cm. A mesma escala foi usada para expressar todos os erros radiais em pixels. Portanto, “2,4 pixels” representa uma distância normalizada por 10,1 cm; não representa um deslocamento de 2,4 células em uma grade quadrada, pois a amostragem nas duas direções é diferente.

O projeto reservou 15% de desempenho pela regra de alocação $5/1{,}15$. O limite de projeto ficou em 4,35 pixels, aproximadamente 44 cm. Os termos de erro foram avaliados na borda da faixa, a 12,9 m do nadir, onde a visada forma cerca de 7,4° com a vertical.

Quanto um erro de tempo desloca a amostra

Em movimento retilíneo, um erro temporal $\Delta t$ corresponde ao deslocamento ao longo do voo

em que $v$ é a velocidade. A 3 m/s, 1 ms corresponde a 3 mm; 10 ms correspondem a 3 cm. Essa relação descreve o termo de translação. Se a plataforma também gira, a orientação associada ao instante errado acrescenta outro deslocamento.

Próximo ao nadir, para pequenos ângulos, o termo angular pode ser aproximado por

em que $H$ é a altitude e $\omega$ é a taxa angular em radianos por segundo. Com 100 m e a taxa angular RMS de 5°/s adotada no modelo, 1 ms corresponde a cerca de 8,7 mm nessa projeção. A contribuição da rotação depende da altitude e da taxa angular, mesmo quando a velocidade de translação é baixa.

O instante de referência da exposição também precisa ser definido. A exposição configurada foi de 50 ms. Se o início for tratado como o centro da exposição, o deslocamento de referência será $v\,t_{\mathrm{exp}}/2$, ou 7,5 cm nas condições avaliadas.

Esse deslocamento de referência difere do arrasto durante a integração. Ao longo de 50 ms, a aeronave percorre 15 cm, que entram na pegada espacial da medição. Corrigir o instante de referência localiza a integração no tempo; o arrasto permanece na resposta espacial do sensor.

Como o orçamento foi calculado

O modelo separou os erros em duas classes. Os termos aleatórios foram representados por desvios-padrão: posição GNSS, rolagem, arfagem, guinada, vibração residual, variação do carimbo de tempo (jitter), altura do terreno e rotação durante a leitura. Os termos sistemáticos foram representados por limites: desalinhamento angular entre câmera e unidade inercial (boresight), erro residual no braço de alavanca, atraso do disparo, referência ao meio da exposição e cisalhamento da leitura sequencial.

O braço de alavanca é a distância entre os pontos de referência dos sensores, como a antena GNSS e a câmera. Seu termo no orçamento representa o erro residual após considerar essa distância. O boresight descreve a rotação entre os referenciais. Ambos exigem calibração da montagem, além da precisão dos sensores individuais.

Para cada eixo, o orçamento combinou os desvios-padrão independentes por soma quadrática e os limites sistemáticos por soma linear:

Nessa expressão, $j$ identifica o eixo, $\sigma_{i,j}$ é o desvio-padrão de um termo aleatório e $b_{k,j}$ é o limite de um termo sistemático. A hipotenusa dos dois valores $B_j$ forneceu um envelope analítico conservador. O fator 1,96 refere-se ao intervalo gaussiano bilateral por eixo; esse envelope não é o percentil radial calculado diretamente.

O P95 radial foi estimado separadamente com 200 000 amostras de Monte Carlo por arquitetura. Os termos aleatórios foram sorteados de distribuições gaussianas e os sistemáticos de distribuições uniformes entre seus limites negativos e positivos. O erro radial de cada amostra foi calculado a partir dos dois eixos. Esses percentis descrevem as distribuições assumidas no modelo, sem constituir intervalos de confiança obtidos de medições de campo.

Cinco arquiteturas de navegação e sincronização

A unidade de medição inercial (IMU) fornece medições de aceleração e velocidade angular. Um sistema de navegação inercial (INS) combina essas medições para estimar o estado da plataforma, podendo integrar GNSS. A comparação usou classes de desempenho de uma IMU de consumo, de uma INS industrial e de uma INS tática pós-processada.

RTK e PPK designam correções GNSS em tempo real e por pós-processamento, respectivamente. Nas arquiteturas corrigidas, o disparo foi sincronizado por hardware ao sinal de um pulso por segundo (PPS) do receptor. A montagem dessas arquiteturas incluiu boresight calibrado e isoladores de vibração.

A execução registrada em 13/09/2026 produziu os resultados da tabela. A incerteza temporal foi expressa como desvio-padrão equivalente (1σ), com requisito de até 1 ms.

A3, A4 e A5 ficaram abaixo da alocação de 44 cm. A2 atendeu ao requisito temporal, mas seu P95 radial permaneceu acima do requisito geométrico. A1 excedeu os dois requisitos.

A Figura 1 reúne as contribuições por fonte para A1 e A3, a comparação geométrica das cinco arquiteturas, uma grade de solo simulada e as taxas de dados.

RTK e PPS não resolvem o erro de atitude

A comparação entre A2 e A3 manteve GNSS corrigido, disparo por hardware e montagem calibrada. A mudança foi a classe de desempenho da estimativa inercial. O P95 radial passou de 125,0 cm para 24,6 cm. Na A2, os maiores termos individuais foram rolagem, arfagem e guinada.

A dependência angular pode ser vista pela aproximação $\Delta x \approx H\,\Delta\theta$. A 100 m, um erro de 0,25° corresponde a cerca de 44 cm próximo ao nadir; 0,03° corresponde a cerca de 5,2 cm. Esses valores são projeções individuais, antes da combinação com os demais termos.

Na A3, a vibração residual e o boresight passaram a ocupar as maiores contribuições individuais. O modelo adotou 0,03° para vibração residual e 0,05° como limite de desalinhamento após calibração. Esses valores são hipóteses de engenharia. A escolha de uma INS com menor erro nominal não verifica, por si só, que a câmera mantém esse alinhamento em voo.

A A5 apresentou P95 de 22,5 cm, contra 24,6 cm da A3. Nas condições adotadas, a redução foi de 2,1 cm. Esse resultado limita o ganho previsto da troca de classe inercial enquanto os resíduos de montagem permanecem nos valores assumidos.

Correção temporal do rolling shutter

No rolling shutter, as linhas do detector integram em instantes sucessivos. Na orientação considerada pelo projeto, cada linha corresponde a uma posição ao longo da fenda, e suas colunas percorrem as bandas espectrais. Assim, as bandas de um mesmo ponto compartilham o instante de integração, enquanto pontos diferentes da linha espacial têm instantes diferentes.

O modelo adotou 9,44 µs por linha e 2064 linhas para o intervalo de leitura, totalizando cerca de 19,5 ms. A 3 m/s, a diferença entre as extremidades corresponde a 5,8 cm de translação, ou aproximadamente ±2,9 cm em relação ao instante central. A rotação durante esse intervalo acrescenta uma contribuição geométrica.

A correção proposta atribui um instante a cada linha pelo índice e pelo tempo de linha, e interpola a atitude nesse instante. O orçamento conservou um resíduo de 3% do efeito da leitura, correspondente à incerteza adotada para o tempo de linha. Portanto, a correção foi representada como uma hipótese de desempenho residual; sua execução em hardware ainda precisa ser verificada.

A4 substituiu o detector por um de global shutter, cuja exposição é simultânea. Seu P95 radial foi 24,7 cm, próximo dos 24,6 cm da A3. A diferença de 0,1 cm entre as estimativas de Monte Carlo não sustenta uma vantagem geométrica. O modelo indica que, com a correção temporal assumida, montagem e navegação predominam sobre o resíduo de leitura sequencial. A comparação não avaliou todos os efeitos radiométricos e ópticos de trocar o detector.

Vazão de dados e armazenamento

A leitura do quadro inteiro de 3072 × 2048 pixels, a 12 bits e 16,3 quadros/s, resultou em taxa prevista de 1,23 Gbit/s. O orçamento assumiu enlace útil de 3,2 Gbit/s e gravação de 400 MB/s. Sob essas capacidades, o quadro inteiro ficou dentro do limite de vazão.

O volume previsto para 20 min foi de 184 GB. O agrupamento de duas amostras na câmera reduziu a estimativa para 92 GB a 12 bits. Esses números pressupõem dados de 12 bits compactados, sem contabilizar metadados e outros custos de armazenamento. Uma implementação que armazene cada amostra em 16 bits terá outro volume. A capacidade útil do enlace e a gravação sustentada precisam ser medidas no computador embarcado.

Alcance da previsão e ensaios necessários

O resultado sustenta a escolha da A3 como arquitetura de projeto: INS industrial, receptor GNSS com RTK, disparo sincronizado ao PPS e correção temporal por linha no IMX178. Essa escolha atende ao orçamento simulado com reserva e preserva o detector previsto no estudo ponta a ponta.

A previsão depende de precisões de navegação ainda tratadas como classes típicas, de vibração e alinhamento não medidos e da independência entre posição e atitude. Um estimador GNSS/INS real pode correlacionar esses erros. O terreno foi representado por uma superfície plana com erro de altura gaussiano de 0,3 m; a extensão a terrenos com relevo exige rever essa geometria.

O requisito temporal pode ser verificado com um LED disparado pelo PPS e registrado pela câmera. A caracterização deve incluir atraso até a exposição, variação entre disparos e tempo de linha no modo de leitura utilizado. Acelerômetros no ponto de fixação permitem rever a hipótese de vibração. Voos sobre pontos de controle, com linhas cruzadas, permitem calibrar o boresight e avaliar o erro geométrico contra uma referência independente.

Até esses ensaios, os 24,6 cm permanecem uma estimativa do orçamento. A comparação identifica o que precisa ser verificado: após corrigir posição e tempo, a atitude e os resíduos da montagem condicionam o atendimento ao requisito.

Reprodução e arquivos do experimento

No ambiente do projeto msi-hsi-sensor-sim, o orçamento pode ser regenerado com:

uv sync
uv run msi-hsi-sensor-sim georref --amostras 200000

A implementação usa semente padrão 11. A configuração foi lida de configs/georreferenciamento.toml e os limiares de configs/requisitos.toml. As saídas ficam em resultados/georref/. O experimento usa NumPy para o orçamento e as amostras, sem depender do traçado óptico ou de um renderizador 3D.

Os arquivos que sustentam este texto estão disponíveis para consulta:

• Configuração de geometria, navegação, tempo e dados.
• Requisitos e reservas de desempenho.
• Orçamento por termo e arquitetura, em CSV.
• Resumo da execução registrada.

O código integral permanece no projeto local, sem endereço público configurado no repositório consultado. Os arquivos disponibilizados documentam as entradas e os resultados da execução; a reprodução computacional completa requer acesso ao código e ao seu ambiente de dependências.