Integración INS-ROS2 para plataformas robóticas autónomas de nueva generación

¿Por qué es necesaria la integración INS-ROS2 en los robots autónomos?

Los robots autónomos necesitan información continua y fiable de posición, velocidad y actitud para la localización, la planificación de trayectorias y el control. Es posible que el GNSS por sí solo no ofrezca una navegación ininterrumpida debido a bloqueos de señal, interferencias o entornos sin GNSS.

Integrar un INS con ROS2 permite a los robots:

1. Lograr una estimación continua de posición, velocidad y actitud

2. Mantener la navegación durante interrupciones temporales del GNSS

3. Realizar navegación por estima en condiciones sin GNSS

4. Fusionar los datos del INS con GNSS, LiDAR, cámaras y odometría

5. Proporcionar datos de navegación de alta frecuencia a la pila de autonomía y control de ROS2
   

Pollux 3 combina un C-SWaP muy bajo con una navegación de alto rendimiento, lo que lo hace muy adecuado para plataformas robóticas autónomas compactas.

Entre sus capacidades principales se incluyen:

1. Diseño ultraminiatura, ligero y de bajo consumo (bajo SWaP)

2. Alta precisión de actitud y rumbo

3. Estimación precisa de posición y velocidad

4. Navegación por estima fiable en condiciones sin GNSS

5. Salida de navegación a 200 Hz, hasta 1000 Hz de datos de IMU

6. Controlador ROS2 específico para simplificar la integración

7. GNSS multiconstelación integrado y fusión de sensores basada en EKF

8. Diseñado para UAV, UGV y robótica

9. Cadena de suministro asegurada

10. Calificación MIL / IP65 cuando corresponda
    

En esencia, ROS2 aporta el marco de autonomía, mientras que Pollux 3 aporta la base de navegación fiable para las plataformas robóticas autónomas.

Por qué importa la precisión de navegación en la robótica autónoma

Los sistemas autónomos modernos dependen de varios sensores para la localización y la percepción. Las cámaras, el LiDAR y los codificadores de rueda tienen cada uno sus limitaciones.

Un sistema de navegación inercial cubre estas carencias estimando de forma continua:

1. Posición

2. Velocidad

3. Orientación

4. Velocidad angular

5. Aceleración

Cuando hay GNSS disponible, Pollux 3 fusiona el posicionamiento por satélite con las mediciones inerciales mediante algoritmos avanzados de fusión de sensores para entregar datos de navegación suaves y fiables, incluso durante interrupciones temporales del GNSS.

Esto permite a los robots mantener una localización estable en entornos dinámicos y difíciles.

Controlador ROS2 de Pollux 3

El controlador Pollux 3 ROS2 está diseñado como un nodo de ciclo de vida gestionado y un componente componible. Publica topics de ROS2 conformes con REP-103, REP-105 y REP-145, lo que permite la compatibilidad con paquetes ROS2 de uso extendido sin necesidad de middleware personalizado. Además de los topics estándar de ROS2, el controlador expone también flujos de datos brutos de Aeron para usuarios avanzados y diagnóstico.

Características principales

El controlador ROS2 ofrece:

1. Integración del INS con ayuda de GNSS

2. Arquitectura de nodo de ciclo de vida

3. Componentes ROS2 componibles

4. Conformidad con REP-103, REP-105 y REP-145

5. Topics de ROS2 estándar y en bruto

6. Calidad de servicio (QoS) configurable

7. Diagnóstico integrado y monitorización del estado

8. Servicios de calibración del dispositivo

9. Compatibilidad con TF estático y dinámico

10. Comunicación serie robusta con reconexión automática

11. Datos de ayuda externa mediante un nodo ROS2 para admitir la ayuda a bordo.

Estas capacidades permiten a los desarrolladores integrar el Pollux 3 de forma eficiente en sistemas robóticos autónomos, manteniendo un flujo de datos y un diagnóstico fiables.

Compatible con los principales marcos de navegación de ROS2

El controlador ROS2 de Pollux 3 está diseñado para integrarse con los marcos de navegación de ROS2 más utilizados, entre ellos:

1. robot_localization

2. Nav2

3. navsat_transform_node

Como el controlador cumple los estándares REP de ROS2, los desarrolladores pueden usar estos marcos sin capas de interfaz adicionales, lo que reduce el tiempo y la complejidad de la integración.

¿Cómo integrar un sistema de navegación inercial (INS) con ROS2 en robots autónomos?

Los desarrolladores pueden integrar rápidamente el Pollux 3 en un espacio de trabajo ROS2 con la estructura de repositorio proporcionada, el flujo de sparse checkout y el proceso de compilación con colcon. El paquete es compatible con las distribuciones ROS2 Humble y Jazzy e incluye paquetes de demostración para la visualización en RViz y Gazebo.

Aplicaciones reales: Pollux 3 es ideal para:

1. Navegación de UAV

2. Vehículos terrestres autónomos (UGV)

3. Robots móviles autónomos (AMR)

4. Robots de almacén

5. Robots de minería

6. Robots de defensa

7. Robots agrícolas

8. Robots de reparto

9. Robots de inspección
   
   

Por qué los ingenieros de robótica eligen Pollux 3

Pollux 3 combina una navegación inercial de alto rendimiento con una integración fluida en ROS2, lo que permite a los equipos de ingeniería acelerar el desarrollo sin perder precisión de navegación.

En lugar de invertir valiosos recursos de ingeniería en integraciones de sensores a medida, los desarrolladores pueden desplegar una solución de navegación lista para producción y compatible con todo el ecosistema ROS2.

Tanto si desarrolla robots autónomos, UAV o UGV como sistemas de automatización industrial, Pollux 3 ofrece el rendimiento, la fiabilidad y la flexibilidad que exigen las plataformas autónomas de nueva generación.

¿Listo para acelerar su desarrollo con ROS2?

Descubra cómo Pollux 3 puede simplificar la integración de la navegación en su aplicación de robótica autónoma.

Próximos pasos:

1. Solicite una demostración en vivo del producto.

2. Descargue la hoja de datos del Pollux 3.

3. Acceda a la documentación del controlador ROS2.

4. Póngase en contacto con el equipo de ingeniería de Aeron Systems para recibir asistencia con la integración.

Aeron Pollux 3: guía de integración con ROS2

El paquete aeron_pollux_driver incorpora el sistema de navegación inercial PLX3 a ROS2 como un ciudadano de primera clase: topics de sensores conformes a los estándares, un nodo de ciclo de vida gestionado, diagnóstico integrado y acceso a paquetes en bruto para usuarios avanzados. Esta guía le lleva desde la caja sin abrir hasta un PLX3 que alimenta su pila de navegación. Para la referencia exhaustiva de parámetros, topics y servicios, consulte la guía del usuario completa en el repositorio.

Qué obtiene: topics estándar de sensor_msgs/ nav_msgs listos para robot_localization, Nav2 y RViz; el conjunto completo de paquetes en bruto del PLX3 republicados en unidades de línea para el registro y los estimadores personalizados; difusión de TF estático dirigida por parámetros para la IMU y la antena GNSS; servicios en tiempo de ejecución para la calibración y el control del dispositivo; y ocho tareas de diagnóstico en /diagnostics.

1. Configuración del hardware

El PLX3 transmite por RS232/UART. Conéctelo a su equipo anfitrión mediante un convertidor de RS232 a USB; aparecerá como un dispositivo serie, normalmente /dev/ttyUSB0. Dos pasos únicos en el anfitrión evitan los fallos más habituales en el primer arranque:

Permisos del puerto serie. Añada su usuario al grupo dialout y luego cierre sesión y vuelva a iniciarla:

sudo usermod -aG dialout $USER

Un nombre de dispositivo estable. /dev/ttyUSB* La numeración puede cambiar tras los reinicios. Fije un nombre permanente con la regla udev que incluye el paquete (crea un enlace simbólico de su convertidor a /dev/aeron_pollux, lo más recomendable para un robot desplegado) o con la ruta /dev/serial/by-id/... integrada en el kernel (sin sudo, funciona en WSL2). La regla udev debe coincidir con los ID USB del convertidor, ya que el PLX3 está detrás de él. Consulte la guía del usuario, §1.1 para ver los comandos exactos.

2. Instalación

ARN_DRIVERS es un monorrepositorio, de modo que un sparse checkout descarga solo el paquete del PLX3 en lugar de todos los controladores de 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 recorre src/ de forma recursiva para encontrar el paquete, por lo que no hace falta ningún enlace simbólico. A continuación, resuelva las dependencias y compile desde la raíz del espacio de trabajo:

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 actualizar más adelante, git pull dentro de ARN_DRIVERS actualiza solo el paquete descargado.

3. Inicio 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

Si el puerto no existe o la velocidad en baudios es incorrecta, el nodo permanece sin configurar y registra el motivo; revise primero la consola.

La frecuencia de salida se fija en el dispositivo, no en el controlador. Configure las frecuencias por paquete del Pollux 3 en la interfaz gráfica Aeron Connect Suite antes del despliegue y después ajuste data_rate_hz del controlador para que coincida, de modo que el diagnóstico de frecuencia sepa qué esperar. Para más información, consulte la sección de AICS del manual de usuario del INS Pollux 3.

4. El nodo de ciclo de vida

El controlador es un nodo de ciclo de vida gestionado, justo lo que se necesita en un robot en el que un orquestador decide cuándo se activan los sensores. Pasa por unconfigured → inactive → active: configure valida los parámetros, abre el puerto y difunde los TF estáticos (aún sin datos); activate inicia el hilo de E/S y los datos empiezan a fluir. El archivo de lanzamiento incluido hace ambas cosas por usted. Para gestionar usted mismo las transiciones (pruebas de puesta en marcha, orquestación externa), inicie con auto_configure:=false auto_activate:=false y utilice ros2 lifecycle set /ins_driver <transition>. El nodo también está registrado como componente componible para compartir proceso con el resto de su canal.

5. Qué se publica

Topics estándar: los consumen directamente las pilas ROS2 estándar, todos en ENU/FLU y unidades del SI:

/imu/data (sensor_msgs/Imu), /imu/mag, /imu/temperature, /imu/pressure, /imu/velocity (twist en el sistema del cuerpo, sin depender del GNSS), /navsat/fix y /navsat/status (siempre RELIABLE, para que las pilas de navegación nunca pierdan una posición), /navsat/ecef, /odom (la solución fusionada del PLX3), /time_reference, /tf + /tf_static y /diagnostics.

Topics de paquetes en bruto: cada paquete nativo del Pollux 3 en unidades de línea, para el registro y los estimadores personalizados: /aeron/nav_fused, /aeron/nav_extended, /aeron/sensors, /aeron/gnss_extended, /aeron/gnss, /aeron/device_info, /aeron/status, /aeron/calib_progress.

Los topics /aeron/* usan tipos personalizados aeron_pollux_driver/msg/*, por lo que debe cargar la superposición de su espacio de trabajo (source install/setup.bash) antes de ejecutar ros2 topic echo sobre ellos. La referencia completa campo por campo y los detalles de QoS están en la guía del usuario, §6.

El Pollux 3 solo entrega datos inerciales calibrados: no existe un flujo de IMU en bruto (imu/data_raw).

6. Configuración obligatoria

Todos los ajustes son parámetros ordinarios de ROS2. La vía duradera es un YAML de parámetros pasado al iniciar (params_file:=your.yaml); los parámetros modificables en tiempo de ejecución también se pueden fijar en vivo con ros2 param set. Hay dos cosas que todo integrador debe configurar.

▸ Transformaciones de montaje

El controlador difunde dos transformaciones estáticas a partir de sus parámetros: base_link → imu_link (pose del INS) y base_link → gnss_link (brazo de palanca de la antena). Los desfases están en metros, en el sistema del cuerpo REP-103: x hacia delante, y a la izquierda, z hacia arriba:

/**:  
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 con ros2 run tf2_ros tf2_echo base_link imu_link. Dos reglas: estos parámetros son únicamente geometría del lado de ROS (nunca se envían al INS; indican a los nodos posteriores dónde están los sensores) y cada desfase físico debe aplicarse una sola vez, ya sea en el dispositivo o en ROS2, nunca en ambos.

▸ Covarianzas de medición

El controlador incluye covarianzas provisionales conservadoras; vuelva a ajustarlas para su plataforma. Una utilidad incluida captura todos los sensores mientras el robot permanece inmóvil e imprime valores listos para YAML:

ros2 run aeron_pollux_driver estimate_variances.py 60 > measured_vars.yaml

Utilice directamente el piso medido para el giroscopio, el acelerómetro y el magnetómetro. Trate la orientation_variance estacionaria solo como un límite inferior: obtenga el valor de la hoja de datos o de pruebas dinámicas. La covarianza de posición GNSS no requiere ajuste: por defecto, el controlador la rellena en vivo a partir de la precisión que informa el propio PLX3.

7. Integración con su pila de navegación

El PLX3 es un INS completo: fusiona a bordo sus datos inerciales y de GNSS y publica una solución de navegación completa. A diferencia de una IMU sencilla con un receptor GNSS, no necesita un estimador en el equipo anfitrión para obtener una pose: la estimación ya se hace en el dispositivo.

▸ Recomendado: consumir directamente la solución fusionada

Introduzca /odom en su pila de navegación (por ejemplo, Nav2) como fuente de localización y deje que el controlador gestione la transformación odom → base_link:

ros2 param set /ins_driver publish_tf true

/odom publica una pose ENU local anclada a la primera posición GNSS y continúa después a través de las interrupciones gracias a la navegación por estima del PLX3. Depende del GNSS: hasta que se obtiene una primera posición permanece en silencio (véase §5). Es la vía adecuada para la gran mayoría de las integraciones y aplicaciones. navsat_transform_node también puede consumir /navsat/fix directamente si necesita un sistema de mapa georreferenciado; utiliza el brazo de palanca base_link → gnss_link difundido para referir la posición a base_link.

▸ Opcional: combinación con odometría de ruedas u otros sensores locales

Si su plataforma tiene codificadores de rueda u otras fuentes locales que desea combinar con el INS, puede ejecutar un filtro en el equipo anfitrión, como ekf_node de robot_localization; tenga en cuenta que se trata de un paquete de ROS que se ejecuta en su ordenador, no de un modo del Pollux 3. También puede introducir datos externos de odómetro en el INS directamente mediante el protocolo de comunicación binario de Aeron. Como el dispositivo ya entrega una solución fusionada, considere cualquiera de las dos vías como una decisión deliberada y no como la opción por defecto, y evite volver a fusionar información que el INS ya ha fusionado. Una disposición típica introduce en el filtro la orientación, las velocidades y la aceleración del INS junto con la odometría de ruedas, y mantiene publish_tf del controlador en su valor por defecto false, de modo que el filtro externo gestione 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)

Solo un publicador puede gestionar odom → base_link. Si lo gestiona un filtro externo, mantenga publish_tf del controlador en false; si lo gestiona el controlador, no ejecute un filtro competidor. Dos publicadores sobre la misma transformación son una patología clásica de TF.

Para una operación totalmente sin GNSS, la solución del INS se mantiene por navegación por estima por sí sola o también fusiona ayuda externa si la hay; también puede fusionar /imu/data e /imu/velocity (ninguno depende del GNSS) en su propio estimador. Todos los nombres de topics y servicios se pueden remapear (--ros-args -r imu/data:=/vehicle/imu, o una lista remappings=[...] en su propio archivo de lanzamiento), y al iniciar con namespace:=<prefix> se antepone un prefijo a todo a la vez.

8. Calibración y operación

Calibración del magnetómetro, cuando cambia el entorno magnético:

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

El controlador se detiene y guarda automáticamente cerca del 100%; los nuevos coeficientes solo surten efecto tras el reinicio.

Verificar un controlador en funcionamiento. /diagnostics es el primer sitio donde mirar cuando algo parece ir mal: sus ocho tareas señalan caídas del enlace, condiciones de baudios erróneos (llegan bytes pero nada se decodifica), degradación del GNSS y crecimiento de memoria. rqt_graph confirma que sus conexiones con los nodos posteriores existen realmente.

Detenerlo correctamente es importante. El puerto serie es un recurso exclusivo gestionado por el kernel, así que detenga el controlador con una sola pulsación de Ctrl+C en el terminal de lanzamiento: las funciones de retorno del ciclo de vida cierran el puerto y salen limpiamente. Una segunda pulsación de Ctrl+C escala a SIGTERM, omite esas funciones y puede dejar el puerto bloqueado ("Device or resource busy" en el siguiente lanzamiento). El procedimiento completo de inspección y apagado está en operations.md.

9. Resolución de problemas

10. Referencia y soporte

1. Referencia completa de parámetros, topics y servicios: user_guide.md

2. Manual del operador (inspección y parada de un controlador en funcionamiento): operations.md

3. Código fuente, incidencias y versiones: github.com/aeron-systems/ARN_DRIVERS

4. Configuración del dispositivo (frecuencias de salida, brazo de palanca de la antena, notación del rumbo): Aeron Connect Suite

5. Soporte: póngase en contacto con Aeron Systems indicando la versión del controlador, la distribución de ROS2 y una captura de /diagnostics. El paquete aeron_pollux_driver se publica bajo la licencia Apache-2.0.

Explore la página de producto del Pollux 3 para ver las especificaciones detalladas, las características principales y las capacidades de integración, o póngase en contacto con nuestros expertos para tratar los requisitos de su aplicación.

Autor: Vinayak Pundhir (desarrollador de software embebido)