Integração INS-ROS2 para plataformas robóticas autônomas de nova geração

Por que a integração INS–ROS2 é necessária para robôs autônomos?

Robôs autônomos precisam de informações contínuas e confiáveis de posição, velocidade e atitude para localização, planejamento de trajetória e controle. O GNSS sozinho pode não oferecer navegação ininterrupta por causa de bloqueio de sinal, interferência ou ambientes sem GNSS.

Integrar um INS ao ROS2 permite que os robôs:

1. Obtenham estimativa contínua de posição, velocidade e atitude

2. Mantenham a navegação durante interrupções temporárias do GNSS

3. Realizem navegação por estimativa (dead reckoning) em condições sem GNSS

4. Fundam os dados do INS com GNSS, LiDAR, câmeras e odometria

5. Forneçam dados de navegação de alta taxa à pilha de autonomia e controle do ROS2
   

O Pollux 3 combina um C-SWaP muito baixo com navegação de alto desempenho, o que o torna ideal para plataformas robóticas autônomas compactas.

Principais recursos:

1. Projeto ultraminiaturizado, leve e de baixo consumo (baixo SWaP)

2. Alta precisão de atitude e de rumo

3. Estimativa precisa de posição e velocidade

4. Navegação por estimativa confiável em condições sem GNSS

5. Saída de navegação a 200 Hz, com dados da IMU de até 1000 Hz

6. Driver ROS2 dedicado para uma integração simplificada

7. GNSS multiconstelação integrado e fusão de sensores baseada em EKF

8. Projetado para UAVs, UGVs e robótica

9. Cadeia de suprimentos assegurada

10. Qualificação MIL / IP65 quando aplicável
    

Em essência, o ROS2 fornece a estrutura de autonomia, enquanto o Pollux 3 fornece a base de navegação confiável para plataformas robóticas autônomas.

Por que a precisão da navegação importa na robótica autônoma

Os sistemas autônomos modernos dependem de vários sensores para localização e percepção. Câmeras, LiDAR e encoders de roda têm, cada um, suas limitações.

Um sistema de navegação inercial preenche essas lacunas ao estimar continuamente:

1. Posição

2. Velocidade

3. Orientação

4. Taxa angular

5. Aceleração

Quando há GNSS, o Pollux 3 funde o posicionamento por satélite com as medições inerciais por meio de algoritmos avançados de fusão de sensores para entregar dados de navegação suaves e confiáveis, mesmo durante interrupções temporárias do GNSS.

Isso permite que os robôs mantenham uma localização estável em ambientes dinâmicos e desafiadores.

Driver ROS2 do Pollux 3

O driver Pollux 3 ROS2 foi projetado como um nó de ciclo de vida gerenciado e um componente composável. Ele publica tópicos ROS2 compatíveis com REP-103, REP-105 e REP-145, o que garante compatibilidade com os pacotes ROS2 mais usados sem exigir middleware personalizado. Além dos tópicos ROS2 padrão, o driver também expõe os fluxos de dados brutos da Aeron para usuários avançados e para diagnóstico.

Principais recursos

O driver ROS2 oferece:

1. Integração de INS auxiliado por GNSS

2. Arquitetura de nó de ciclo de vida

3. Componentes ROS2 composáveis

4. Conformidade com REP-103, REP-105 e REP-145

5. Tópicos ROS2 padrão e brutos

6. Qualidade de serviço (QoS) configurável

7. Diagnóstico e monitoramento de integridade integrados

8. Serviços de calibração do dispositivo

9. Suporte a TF estático e dinâmico

10. Comunicação serial robusta com reconexão automática

11. Dados de auxílio externos por meio de um nó ROS2, para dar suporte ao auxílio a bordo.

Esses recursos permitem que os desenvolvedores integrem o Pollux 3 com eficiência a sistemas robóticos autônomos, mantendo um fluxo de dados e um diagnóstico confiáveis.

Compatível com os principais frameworks de navegação ROS2

O driver ROS2 do Pollux 3 foi projetado para se integrar aos frameworks de navegação ROS2 mais usados, entre eles:

1. robot_localization

2. Nav2

3. navsat_transform_node

Como o driver segue os padrões REP do ROS2, os desenvolvedores podem usar esses frameworks sem camadas de interface adicionais, o que reduz o tempo e a complexidade da integração.

Como integrar um sistema de navegação inercial (INS) ao ROS2 em robôs autônomos?

Os desenvolvedores podem integrar rapidamente o Pollux 3 a um workspace ROS2 usando a estrutura de repositório fornecida, o fluxo de sparse checkout e o processo de build com colcon. O pacote oferece suporte às distribuições ROS2 Humble e Jazzy e inclui pacotes de demonstração para visualização no RViz e no Gazebo.

Aplicações reais: o Pollux 3 é ideal para:

1. Navegação de UAVs

2. Veículos terrestres autônomos (UGVs)

3. Robôs móveis autônomos (AMRs)

4. Robôs de armazém

5. Robôs de mineração

6. Robôs de defesa

7. Robôs agrícolas

8. Robôs de entrega

9. Robôs de inspeção
   
   

Por que engenheiros de robótica escolhem o Pollux 3

O Pollux 3 combina navegação inercial de alto desempenho com uma integração fluida ao ROS2, permitindo que as equipes de engenharia acelerem o desenvolvimento sem abrir mão da precisão da navegação.

Em vez de investir recursos valiosos de engenharia em integrações de sensores sob medida, os desenvolvedores podem implantar uma solução de navegação pronta para produção e compatível com todo o ecossistema ROS2.

Seja para robôs autônomos, UAVs, UGVs ou sistemas de automação industrial, o Pollux 3 entrega o desempenho, a confiabilidade e a flexibilidade que as plataformas autônomas de nova geração exigem.

Pronto para acelerar seu desenvolvimento em ROS2?

Veja como o Pollux 3 pode simplificar a integração de navegação na sua aplicação de robótica autônoma.

Próximos passos:

1. Solicite uma demonstração ao vivo do produto.

2. Baixe o datasheet do Pollux 3.

3. Acesse a documentação do driver ROS2.

4. Fale com a equipe de engenharia da Aeron Systems para obter suporte de integração.

Aeron Pollux 3 — Guia de integração com ROS2

O pacote aeron_pollux_driver traz o sistema de navegação inercial PLX3 para o ROS2 como cidadão de primeira classe: tópicos de sensores em conformidade com os padrões, um nó de ciclo de vida gerenciado, diagnóstico integrado e acesso a pacotes brutos para usuários avançados. Este guia leva você da caixa fechada até um PLX3 alimentando sua pilha de navegação. Para a referência completa de parâmetros, tópicos e serviços, consulte o guia do usuário completo no repositório.

O que você recebe: tópicos sensor_msgs/ nav_msgs padrão, prontos para o robot_localization, o Nav2 e o RViz; o conjunto completo de pacotes brutos do PLX3 republicados em unidades de fio para registro e estimadores personalizados; difusão de TF estático orientada por parâmetros para a IMU e a antena GNSS; serviços em tempo de execução para calibração e controle do dispositivo; e oito tarefas de diagnóstico em /diagnostics.

1. Configuração do hardware

O PLX3 transmite por RS232/UART. Conecte-o ao seu host por meio de um conversor RS232 para USB; ele aparecerá como um dispositivo serial, normalmente /dev/ttyUSB0. Duas etapas únicas no host evitam as falhas mais comuns na primeira execução:

Permissões da porta serial. Adicione seu usuário ao grupo dialout e depois saia da sessão e entre novamente:

sudo usermod -aG dialout $USER

Um nome de dispositivo estável. /dev/ttyUSB* A numeração pode mudar entre reinicializações. Fixe um nome com a regra udev que o pacote inclui (cria um link simbólico do seu conversor para /dev/aeron_pollux, o melhor para um robô em operação) ou com o caminho /dev/serial/by-id/... nativo do kernel (sem sudo, funciona no WSL2). A regra udev deve corresponder aos IDs USB do conversor, pois o PLX3 fica atrás dele. Consulte o guia do usuário, seção 1.1 para ver os comandos exatos.

2. Instalação

ARN_DRIVERS é um monorepositório, portanto um sparse checkout baixa apenas o pacote do PLX3, e não todos os drivers da Aeron:

cd ~/ros2_ws/src 

git clone --filter=blob:none --sparse https://github.com/aeron-systems/ARN_DRIVERS.git

cd ARN_DRIVERS

git sparse-checkout set ROS2/pollux3/v01.00/aeron_pollux_driver

colcon percorre src/ recursivamente para encontrar o pacote, então não é preciso criar link simbólico. Depois, resolva as dependências e faça o build a partir da raiz do workspace:

cd ~/ros2_ws 

sudo rosdep init      #first time on this machine only (harmless warning if already done)

rosdep update

rosdep install --from-paths src -y --ignore-src
 
colcon build --packages-up-to aeron_pollux_driver

source install/setup.bash

Para atualizar depois, basta executar git pull dentro de ARN_DRIVERS, que atualiza somente o pacote baixado.

3. Início rápido

#Launch (auto-configures+auto-activates)
 
ros2 launch aeron_pollux_driver aeron_driver.launch.py \
    
device_path:=/dev/aeron_pollux baud_rate:=921600 

#Watch data and confirm health 

ros2 topic echo /imu/data 

ros2 topic echo /navsat/fix 

ros2 topic echo /diagnostics 

ros2 run rqt_runtime_monitor rqt_runtime_monitor

Se a porta não existir ou a taxa de baud estiver errada, o nó permanece não configurado e registra o motivo; verifique primeiro o console.

A taxa de saída é definida no dispositivo, não no driver. Configure as taxas por pacote do Pollux 3 na interface gráfica Aeron Connect Suite antes da implantação e depois ajuste o data_rate_hz do driver para o mesmo valor, de modo que o diagnóstico de taxa saiba o que esperar. Para mais informações, consulte a seção sobre o AICS no manual do usuário do INS Pollux 3.

4. O nó de ciclo de vida

O driver é um nó de ciclo de vida gerenciado, exatamente o que se quer em um robô em que um orquestrador decide quando os sensores sobem. Ele passa por unconfigured → inactive → active: configure valida os parâmetros, abre a porta e difunde os TFs estáticos (ainda sem dados); activate inicia a thread de E/S e os dados passam a fluir. O arquivo de launch incluído faz as duas etapas por você. Para conduzir as transições manualmente (testes de bring-up, orquestração externa), inicie com auto_configure:=false auto_activate:=false e use ros2 lifecycle set /ins_driver <transition>. O nó também está registrado como componente composável, para compartilhar um processo com o restante do seu pipeline.

5. O que é publicado

Tópicos padrão: consumidos diretamente por pilhas ROS2 prontas para uso, todos em ENU/FLU e unidades do SI:

/imu/data (sensor_msgs/Imu), /imu/mag, /imu/temperature, /imu/pressure, /imu/velocity (twist no referencial do corpo, sem dependência do GNSS), /navsat/fix e /navsat/status (sempre RELIABLE, para que as pilhas de navegação nunca percam uma correção), /navsat/ecef, /odom (a solução fundida do PLX3), /time_reference, /tf + /tf_static e /diagnostics.

Tópicos de pacotes brutos: todos os pacotes nativos do Pollux 3 em unidades de fio, para registro e estimadores personalizados: /aeron/nav_fused, /aeron/nav_extended, /aeron/sensors, /aeron/gnss_extended, /aeron/gnss, /aeron/device_info, /aeron/status, /aeron/calib_progress.

Os tópicos /aeron/* usam tipos personalizados aeron_pollux_driver/msg/*, então carregue o overlay do seu workspace (source install/setup.bash) antes de executar ros2 topic echo neles. A referência completa campo a campo e os detalhes de QoS estão na seção 6 do guia do usuário.

O Pollux 3 envia apenas dados inerciais calibrados; não há fluxo de IMU bruta (imu/data_raw).

6. Configuração obrigatória

Todas as configurações são parâmetros ROS2 comuns. O caminho duradouro é um YAML de parâmetros passado no launch (params_file:=your.yaml); os parâmetros que podem mudar em tempo de execução também podem ser definidos ao vivo com ros2 param set. Todo integrador precisa definir duas coisas.

▸ Transformações de montagem

O driver difunde duas transformações estáticas a partir dos seus parâmetros: base_link → imu_link (pose do INS) e base_link → gnss_link (braço de alavanca da antena). Os deslocamentos são em metros, no referencial do corpo da REP-103 — x para a frente, y para a esquerda, z para cima:

/**:  
ros__parameters:    
mounting_translation:             # base_link → INS
x:  0.12         #12 cm forward      
y: -0.04         #4 cm right (y is left-positive)  
z:  0.18         #18 cm up    
mounting_rotation:           # only if the INS is physically rotated     
roll: 0.0      
pitch: 0.0      
yaw: 0.0    
gnss_mounting_translation:    # base_link → antenna      
x: -0.20      
y:  0.00      
z:  1.20

Verifique com ros2 run tf2_ros tf2_echo base_link imu_link. Duas regras: esses parâmetros são apenas geometria do lado do ROS (nunca são enviados ao INS; eles informam aos nós a jusante onde os sensores estão) e cada deslocamento físico deve ser aplicado uma única vez, no dispositivo ou no ROS2, nunca nos dois.

▸ Covariâncias de medição

O driver vem com covariâncias provisórias conservadoras; reajuste-as para a sua plataforma. Um utilitário incluído captura todos os sensores enquanto o robô fica parado e imprime valores prontos para YAML:

ros2 run aeron_pollux_driver estimate_variances.py 60 > measured_vars.yaml

Use diretamente o piso medido para giroscópio, acelerômetro e magnetômetro. Trate a orientation_variance estacionária apenas como um limite inferior; obtenha o valor no datasheet ou em testes dinâmicos. A covariância de posição do GNSS não precisa de ajuste: por padrão, o driver a preenche em tempo real com a precisão informada pelo próprio PLX3.

7. Integração com a sua pilha de navegação

O PLX3 é um INS completo: ele funde a bordo os dados inerciais e de GNSS e publica uma solução de navegação completa. Ao contrário de uma IMU simples somada a um receptor GNSS, você não precisa de um estimador no host para obter uma pose; a estimação já é feita no dispositivo.

▸ Recomendado: consumir diretamente a solução fundida

Alimente a sua pilha de navegação (por exemplo, o Nav2) com o /odom como fonte de localização e deixe o driver cuidar da transformação odom → base_link:

ros2 param set /ins_driver publish_tf true

/odom publica uma pose ENU local ancorada na primeira correção do GNSS e depois continua durante as interrupções seguintes graças à navegação por estimativa do PLX3. Ele depende do GNSS: até que a primeira correção seja obtida, permanece em silêncio (veja a seção 5). Este é o caminho certo para a grande maioria das integrações e aplicações. O navsat_transform_node também pode consumir diretamente o /navsat/fix se você precisar de um referencial de mapa georreferenciado; ele usa o braço de alavanca base_link → gnss_link difundido para referir a correção ao base_link.

▸ Opcional: combinação com odometria de roda ou outros sensores locais

Se a sua plataforma tem encoders de roda ou outras fontes locais que você quer combinar com o INS, é possível executar um filtro no host, como o ekf_node do robot_localization. Note que este é um pacote ROS rodando no seu computador, e não um modo do Pollux 3. Você também pode enviar dados de odômetro externo diretamente ao INS pelo protocolo de comunicação binário da Aeron. Como o dispositivo já entrega uma solução fundida, trate qualquer um dos caminhos como uma escolha deliberada, e não como o padrão, e evite refundir informações que o INS já fundiu. Uma ligação típica alimenta o filtro com orientação, taxas e aceleração do INS e com a odometria de roda, e mantém o publish_tf do driver em seu padrão false, de modo que o filtro externo cuide de odom → base_link:

ekf_filter_node:                      # robot_localization (host-side) — not a Pollux 3 mode               
    ros__parameters:    
        imu0: /imu/data    
        imu0_config: [false, false, false,       # x, y, z              
                      true,  true,  true,        # roll, pitch, yaw              
                      false, false, false,       # vx, vy, vz
                      true,  true,  true,        # vroll, vpitch, vyaw
                      true,  true,  true]        # ax, ay, az

      imu0_remove_gravitational_acceleration: true     # Pollux 3 outputs specific force (REP-145)

Apenas um publicador pode ser dono de odom → base_link. Se um filtro externo for o dono, mantenha o publish_tf do driver em false; se o driver for o dono, não execute um filtro concorrente. Dois publicadores na mesma transformação são uma patologia clássica do TF.

Para operação totalmente sem GNSS, a solução do INS faz navegação por estimativa por conta própria ou também funde auxílio externo, se houver; você também pode fundir /imu/data e /imu/velocity (nenhum depende do GNSS) no seu próprio estimador. Todo nome de tópico e de serviço pode ser remapeado (--ros-args -r imu/data:=/vehicle/imu, ou uma lista remappings=[...] no seu próprio arquivo de launch), e iniciar com namespace:=<prefix> aplica um prefixo a tudo de uma vez.

8. Calibração e operação

Calibração do magnetômetro, quando o ambiente magnético muda:

ros2 service call /calibrate_ins aeron_pollux_driver/srv/CalibrateIns   #START (default) 
ros2 topic echo /aeron/calib_progress                                   #rotate slowly about Z 
ros2 service call /reboot_device std_srvs/srv/Trigger                   #reboot to apply

O driver para e salva automaticamente perto de 100%; os novos coeficientes só entram em vigor após a reinicialização.

Como verificar um driver em execução. /diagnostics é o primeiro lugar a consultar quando algo parece errado: suas oito tarefas sinalizam quedas de enlace, condições de baud errado (bytes chegando, mas nada sendo decodificado), degradação do GNSS e crescimento de memória. O rqt_graph confirma que as conexões com os nós a jusante realmente existem.

Parar corretamente importa. A porta serial é um recurso exclusivo gerenciado pelo kernel; por isso, pare o driver com um único Ctrl+C no terminal do launch: os callbacks do ciclo de vida fecham a porta e encerram de forma limpa. Um segundo Ctrl+C escala para SIGTERM, ignora os callbacks e pode deixar a porta travada (“Device or resource busy” no próximo launch). O procedimento completo de inspeção e desligamento está em operations.md.

9. Solução de problemas

10. Referência e suporte

1. Referência completa de parâmetros, tópicos e serviços: user_guide.md

2. Manual do operador (inspeção e parada de um driver em execução): operations.md

3. Código-fonte, issues e releases: github.com/aeron-systems/ARN_DRIVERS

4. Configuração do dispositivo (taxas de saída, braço de alavanca da antena, notação de rumo): Aeron Connect Suite

5. Suporte: entre em contato com a Aeron Systems informando a versão do driver, a distribuição ROS2 e uma captura de /diagnostics. O pacote aeron_pollux_driver é distribuído sob a licença Apache-2.0.

Conheça a página do produto Pollux 3 para ver especificações detalhadas, principais recursos e capacidades de integração, ou fale com nossos especialistas para discutir os requisitos da sua aplicação.

Autor: Vinayak Pundhir (Desenvolvedor de software embarcado)