Real-time loosely coupled GNSS and IMU integration via Factor Graph Optimization

Este artigo propõe uma arquitetura de integração GNSS/IMU em tempo real baseada em Otimização de Grafos de Fatores (FGO) para ambientes urbanos desafiadores, demonstrando que, embora haja uma redução na precisão de posicionamento em comparação com métodos de processamento em lote, a abordagem oferece maior disponibilidade de serviço e eficiência computacional, estabelecendo um equilíbrio crítico entre precisão, disponibilidade e desempenho em tempo real.

O essencial

Imagine que você está dirigindo um carro autônomo (um carro que se dirige sozinho) em uma cidade muito movimentada, cheia de prédios altos. O objetivo é saber exatamente onde o carro está a cada segundo.

Para fazer isso, o carro usa dois "olhos" principais:

1. O GNSS (o GPS): É como olhar para o céu e contar as estrelas (satélites) para saber onde está. Funciona perfeitamente no campo aberto, mas nas cidades, os prédios bloqueiam o sinal, refletem o sinal (como um eco) ou o sinal some completamente. É como tentar ouvir uma música no rádio dentro de um elevador de concreto: a qualidade cai muito.
2. O IMU (o Giroscópio/Acelerômetro): É como o seu ouvido interno. Ele sente quando você acelera, freia ou vira. Ele funciona muito bem por curtos períodos, mesmo sem ver o céu. O problema é que ele tem um "defeito": com o tempo, ele começa a errar um pouquinho a cada movimento, e esse erro vai se acumulando (como se você fechasse os olhos e tentasse andar em linha reta; logo, você estaria torto).

O Problema

A maioria dos sistemas tenta juntar esses dois dados. Mas os métodos antigos (chamados de "Fator de Otimização" ou FGO) são como um chef de cozinha que só serve o prato depois de cozinhar tudo de uma vez. Eles esperam ter todos os dados do trajeto inteiro para então calcular a posição perfeita. Isso é ótimo para precisão, mas inútil para um carro que precisa decidir agora se vai virar à esquerda ou não. É um método de "pós-processamento".

A Solução Proposta (RTFGO)

Os autores deste artigo criaram um novo método chamado RTFGO. Eles transformaram o "chef de cozinha" em um cozinheiro de fast-food que serve o prato imediatamente, mas ainda tenta mantê-lo saboroso.

Aqui está como eles fizeram isso, usando analogias simples:

1. A "Janela Deslizante" (Marginalization)

Imagine que você está escrevendo uma história. Se você tentar lembrar de tudo o que escreveu desde a primeira página até a última, sua mente vai ficar sobrecarregada e lenta.
O método antigo tentava lembrar de tudo. O novo método (RTFGO) usa uma janela deslizante. Ele foca apenas no que aconteceu nos últimos segundos (digamos, os últimos 50 segundos). O que aconteceu há muito tempo é "esquecido" (marginalizado) para liberar espaço na memória do computador. Isso permite que o cálculo seja feito em tempo real, milissegundo a milissegundo.

2. O "Salto no Escuro" (IMU Propagation)

Quando o GPS some (por exemplo, ao entrar em um túnel ou entre prédios altos), o carro não pode parar. O RTFGO usa o IMU para "adivinhar" onde o carro está baseado na última posição conhecida e na velocidade.

• O Truque: Eles limitam esse "salto no escuro". Se o GPS sumir por muito tempo, o erro do IMU cresce demais. Então, o sistema para de tentar adivinhar após um certo tempo para não entregar uma localização totalmente errada. É como dizer: "Se não vejo o céu por mais de 10 segundos, melhor avisar que não tenho certeza, do que inventar uma posição".

3. O "Atraso Controlado" (Smoothing Latency)

Aqui está o grande dilema do artigo.

• Opção A (Precisão Máxima): O sistema espera um pouquinho (digamos, 5 segundos) para ver se o GPS vai melhorar com novos dados antes de confirmar a posição atual. Isso é como esperar a chuva passar para ver se o chão está realmente molhado. É mais preciso, mas lento.
• Opção B (Tempo Real): O sistema entrega a posição imediatamente. É mais rápido, mas pode ter um pouco mais de erro se o GPS estiver ruim naquele instante.

O Que Eles Descobriram?

Eles testaram isso em Hong Kong, em uma área com prédios muito altos (o "Canyon Urbano"). Os resultados foram fascinantes:

• Disponibilidade: O novo método (RTFGO) consegue entregar uma posição muito mais vezes do que os métodos antigos. Enquanto o GPS sozinho falhava 60% do tempo, o RTFGO manteve o carro "localizado" quase o tempo todo, usando o IMU quando o GPS falhava.
• Precisão vs. Velocidade: Houve um pequeno custo. Para ser rápido e estar sempre disponível, a precisão caiu um pouquinho em comparação com o método que esperava todos os dados (o "chef de cozinha" lento).
• O Equilíbrio: O artigo mostra que você pode escolher: quer ser super preciso e esperar um pouco? Ou quer estar sempre disponível e aceitar um erro de alguns metros? O sistema permite ajustar essa "alavanca".

Resumo Final

Pense no RTFGO como um navegador inteligente e ágil. Ele não espera ter todas as informações para te dizer onde você está. Ele usa o que tem agora (o GPS) e o que sente agora (o IMU), joga fora as memórias muito antigas para não ficar lento, e te diz onde você está em tempo real, mesmo que você esteja em um beco sem saída cheio de prédios.

É um passo gigante para carros autônomos, drones e aplicativos de navegação funcionarem de verdade nas cidades caóticas de hoje, onde o sinal de GPS costuma falhar.

Resumo técnico

Aqui está um resumo técnico detalhado do artigo "Real-time loosely coupled GNSS and IMU integration via Factor Graph Optimization", apresentado em português:

1. Problema e Contexto

O posicionamento, navegação e sincronização (PNT) são fundamentais para sistemas autônomos modernos. O Sistema de Navegação Global por Satélite (GNSS) é a principal fonte de localização em ambientes externos, mas sofre severamente em ambientes urbanos densos (canyons urbanos). Nessas condições, o GNSS enfrenta:

• Perda de sinal (outages).
• Efeitos de multipath (reflexões em edifícios).
• Bloqueio da linha de visada (NLOS).
• Interferências.

Para mitigar isso, a fusão de sensores com Unidades de Medição Inercial (IMU) é comum. No entanto, a IMU sofre de deriva cumulativa (drift) ao longo do tempo. Métodos tradicionais como Filtros de Kalman (EKF) são amplamente utilizados, mas abordagens mais recentes baseadas em Otimização de Grafos de Fatores (FGO) demonstraram superioridade, especialmente em cenários com ruído não-Gaussiano.

O desafio central abordado neste trabalho é que a maioria das implementações de FGO é computacionalmente intensiva e utilizada como pós-processamento (batch), o que impede sua aplicação em tempo real. O objetivo é desenvolver uma arquitetura de fusão solta (loosely coupled) GNSS/IMU baseada em FGO que opere em tempo real, mantendo alta disponibilidade de serviço em ambientes desafiadores.

2. Metodologia

Os autores propõem o RTFGO (Real-Time Factor Graph Optimization), uma evolução do método de estado da arte SFGO (Standard FGO). A arquitetura é solta, combinando estados processados pelo GNSS (posição, velocidade, tempo) com dados da IMU.

Componentes Principais:

• Grafo de Fatores: O problema de estimação é modelado como um grafo onde os nós representam os vetores de estado (pose, velocidade, viés da IMU) e os fatores representam as restrições (medidas GNSS, preintegração da IMU, viés aleatório).
• Estratégias para Tempo Real: Para tornar o FGO viável em tempo real, o RTFGO introduz três modificações críticas em relação ao método de batch (SFGO):
  1. Propagação apenas com IMU: Durante quedas de sinal GNSS, o sistema continua a estimar a posição usando apenas a IMU, aumentando a disponibilidade do serviço, embora isso introduza deriva de viés.
  2. Latência de Suavização (Smoothing Latency - $\tau$): O sistema pode atrasar a saída em um número fixo de medições futuras para refinar estados passados. $\tau=0$ significa saída imediata (tempo real estrito), enquanto $\tau$ alto aproxima-se do processamento em lote.
  3. Marginalização com Lag Fixo: Para evitar que o grafo cresça indefinidamente (o que tornaria a otimização lenta), estados antigos são "marginalizados" (removidos do grafo, mas suas informações são condensadas em um prior), limitando o uso de memória e tempo de computação.

Implementação:

• Utiliza a biblioteca GTSAM para a otimização não linear (algoritmo iSAM2).
• Utiliza o RTKLIB para processamento inicial do GNSS.
• Otimização realizada via métodos iterativos (Gauss-Newton ou Levenberg-Marquardt).

3. Contribuições Chave

1. Arquitetura RTFGO: Proposição de um framework de fusão GNSS/IMU solta baseada em FGO capaz de operar em tempo real.
2. Análise de Trade-offs: Estudo detalhado das compensações entre:
   • Precisão: Melhorada com maior latência de suavização e menor marginalização.
   • Disponibilidade de Serviço: Melhorada com propagação IMU durante outages, mas à custa de precisão a longo prazo.
   • Eficiência Computacional: Gerenciada através da marginalização de estados antigos.
3. Validação em Cenários Reais: Demonstração experimental em um conjunto de dados urbano real (Hong Kong), provando que é possível obter soluções de tempo real com desempenho próximo ao de métodos de pós-processamento.

4. Resultados Experimentais

Os testes foram realizados no conjunto de dados UrbanNav-HK-MediumUrban-1, que contém dois loops em um canyon urbano denso com disponibilidade de GNSS de apenas ~40%.

• Comparação de Precisão (RMSE 3D):
  • O RTFGO em modo Batch (equivalente ao SFGO) alcançou um RMSE de 9.33 m (Loop 2), superando a solução apenas GNSS (13.24 m) e igualando o estado da arte (SFGO).
  • O RTFGO em Tempo Real ($\tau=0$, sem suavização futura) teve um RMSE de 11.83 m. Houve uma perda de precisão em relação ao modo batch, mas ainda superior ao GNSS puro.
• Disponibilidade de Serviço:
  • O método RTFGO com propagação IMU aumentou significativamente a disponibilidade de serviço em comparação com métodos que param durante outages de GNSS.
  • A análise mostrou que, ao permitir a propagação IMU, o sistema mantém a saída de posição mesmo sem sinais de satélite, embora a precisão degrade com o tempo.
• Impacto da Latência e Marginalização:
  • Aumentar a latência de suavização ($\tau$) melhora a precisão até certo ponto, mas medições GNSS degradadas no futuro podem, paradoxalmente, piorar estimativas passadas se não forem filtradas corretamente.
  • O aumento do lag de marginalização reduz o tempo de computação (mantendo-o na ordem de milissegundos), mas reduz a precisão, pois perde-se a capacidade de corrigir viéses antigos com dados futuros.

5. Significado e Conclusão

O trabalho demonstra que é possível implementar Otimização de Grafos de Fatores em sistemas de navegação em tempo real, superando a barreira computacional que historicamente limitava o FGO ao pós-processamento.

• Conclusão Principal: Existe um compromisso claro (trade-off) entre precisão, disponibilidade e custo computacional. O RTFGO oferece uma solução flexível onde os engenheiros podem ajustar a latência e a marginalização para atender a requisitos específicos de aplicação (ex: um táxi autônomo pode priorizar a disponibilidade contínua, enquanto um mapeamento de alta precisão pode priorizar a suavização).
• Trabalho Futuro: Os autores planejam estender a abordagem para uma integração estritamente acoplada (tightly coupled), que utiliza medições brutas de pseudorrange e Doppler, o que deve melhorar ainda mais a robustez e a precisão em ambientes urbanos extremos.

Em suma, o artigo valida o FGO como uma alternativa viável e superior aos filtros de Kalman para fusão de sensores em tempo real em ambientes urbanos desafiadores.