Simplifique la integración de AMR y AGV con componentes ROS 2

Los robots móviles autónomos (AMR) y los vehículos de guiado automático (AGV) requieren una estrecha coordinación entre múltiples subsistemas, incluidos sensores, motores, navegación y toma de decisiones basada en inteligencia artificial (IA). Integrar todos estos subsistemas supone un reto para los desarrolladores.

El Sistema Operativo Robótico (ROS) ofrece un camino a través de esta complejidad. ROS es un middleware robótico de código abierto que proporciona marcos de comunicación estandarizados y un amplio ecosistema de paquetes reutilizables. Al seleccionar componentes con soporte ROS nativo, los diseñadores pueden utilizar módulos de hardware preconstruidos con funcionalidad direccionable por software, lo que reduce el tiempo de puesta a punto y mejora la interoperabilidad.

Este artículo repasa brevemente los retos a los que se enfrentan los diseñadores de AMR y AGV y cómo ROS puede ayudarles. A continuación, presenta el hardware compatible con ROS de Analog Devices (ADI), incluidos los controladores de motor, las unidades de medición inercial (IMU) y los sensores de tiempo de vuelo (ToF), y explica cómo se integran estos componentes con la pila de software ROS para acelerar el desarrollo de productos.

El reto de la integración de los AMR y AGV

El trabajo de integración puede dominar el calendario inicial en un diseño AMR o AGV. En la capa de hardware, los equipos deben seleccionar los componentes, diseñar las interfaces y validar la integridad de la señal y la temporización. En la capa de software, deben cargar los controladores, definir los flujos de datos y asegurarse de que el sistema se comporta de forma predecible en condiciones reales.

Los equipos con talento pueden alcanzar estos objetivos con diseños propios, pero hacerlo a menudo significa recrear capacidades ya existentes. Este esfuerzo puede ser difícil de justificar, sobre todo cuando los enfoques tradicionales pueden encerrar a los equipos en interfaces propietarias. Cuando los requisitos evolucionan, la sustitución de un componente puede requerir la reelaboración de partes sustanciales de la pila de software.

Cómo aborda ROS los retos de la integración

ROS se creó para abordar estas cuestiones. A pesar de su nombre, ROS no es un sistema operativo en el sentido clásico. En su lugar, se trata de un marco de trabajo de código abierto que ofrece un amplio conjunto de herramientas, bibliotecas y convenciones.

El concepto clave de ROS es la estructuración de aplicaciones robóticas complejas en nodos modulares (figura 1). Estos procesos del tamaño de un bocado realizan tareas específicas, como leer los datos de los sensores o controlar la velocidad del motor.

Figura 1: Los componentes básicos de ROS incluyen paquetes, nodos, mensajes y servicios. (Fuente de la imagen: Analog Devices, modificado por Kenton Williston)

Los nodos se comunican a través de dos mecanismos principales:

• Temas: Un modelo editor-suscriptor adecuado para el flujo continuo de datos, como las alimentaciones de sensores
• Servicios: Un modelo de solicitud-respuesta, mejor para acciones poco frecuentes, como la configuración e inicialización de dispositivos.

Varios nodos y sus dependencias (incluidos los temas y servicios asociados) pueden combinarse en un paquete para ofrecer una funcionalidad más completa. Por ejemplo, Analog Devices ha creado paquetes de controladores ROS para sus módulos de sensores y actuadores diseñados para AGV y AMR. Estos paquetes encapsulan los nodos, las definiciones de mensajes y los archivos de configuración necesarios para integrar el hardware en un sistema basado en ROS.

Cómo ROS agiliza el diseño de AMR y AGV

Esta arquitectura modular permite la interoperabilidad y acelera el desarrollo. En la capa de hardware, ROS proporciona interfaces estandarizadas para componentes como cámaras y controladores de motor. Esto acelera la integración al tiempo que libera a los diseñadores de la dependencia de un proveedor y de los costos de licencia.

En la capa de software, ROS ofrece herramientas y middleware que ayudan a los diseñadores a desarrollar, probar, implementar y mantener robots complejos. La versión actual del marco, ROS 2, ofrece características especialmente útiles para los AMR y los AGV. Entre ellos se incluyen:

• La pila de navegación Nav2, que admite árboles de comportamiento, zonas de retención, límites de velocidad, etc.
• Sofisticados algoritmos de posicionamiento, incluidas herramientas de mapeo y localización que permiten a los AMR y AGV comprender su entorno
• Integración con herramientas de simulación, visualización y registro que ayudan tanto al desarrollo como al diagnóstico

ROS 2 suele ejecutarse en una computadora basada en Linux, aunque se admiten otros sistemas operativos. ROS 2 también es compatible con micro-ROS, una variante que se ejecuta de forma nativa en unidades de microcontroladores (MCU) con sistemas operativos en tiempo real (RTOS), como Zephyr y FreeRTOS.

Control de motores con integración de ROS 2

Para ilustrar el potencial de ROS 2, considere las complejidades del control de la propulsión. La mayoría de los AMR y AGV utilizan una configuración de tracción diferencial, en la que dos conjuntos de ruedas controlados independientemente permiten tanto el avance como el giro. Esta arquitectura requiere un controlador de motor capaz de accionar ambas ruedas simultáneamente mientras acepta órdenes coordinadas del sistema de navegación.

El TMCM-2611-AGV de ADI (figura 2) responde directamente a esta necesidad. Esta tarjeta, que forma parte de la familia de módulos controladores de motores Trinamic (TMCM), es una plataforma de servoaccionamiento de dos ejes para motores trifásicos de corriente continua sin escobillas (BLDC), diseñada para aplicaciones de tracción AGV y AMR. Cada eje puede accionar motores de hasta 14 amperios (A) RMS a 48 voltios, con realimentación de posición mediante codificadores incrementales en cuadratura o sensores digitales de efecto Hall.

Figura 2: El TMCM-2611-AGV es un controlador/driver de doble eje para motores BLDC trifásicos. (Fuente de la imagen: Analog Devices)

El controlador adi_tmcl ROS 2 conecta este hardware al ecosistema ROS 2 principalmente a través de temas (Figura 3). Por ejemplo, una pila de navegación puede publicar comandos de velocidad para cada juego de ruedas a través de los temas /cmd_vel_X. El controlador adi_tmcl se suscribe a estos temas, traduce las órdenes en tramas del lenguaje de control de movimiento trinámico (TMCL) y las envía por el bus CAN a través de la interfaz SocketCAN nativa de Linux.

Figura 3: El paquete de controladores ROS2 de TMCL incorpora un sólido conjunto de interfaces. (Fuente de la imagen: Analog Devices)

En la otra dirección, el controlador adi_tmcl publica la retroalimentación del motor en los temas /tmc_info_X, proporcionando información sobre velocidad, posición, par y estado. Otros nodos pueden suscribirse a estos datos para el cálculo de la odometría, el diagnóstico o el control en bucle cerrado a nivel de la aplicación.

Este flujo bidireccional ilustra cómo ROS 2 permite el diseño de sistemas modulares. El algoritmo de navegación no necesita saber nada sobre TMCL o CAN bus; simplemente publica mensajes de velocidad estándar y recibe retroalimentación.

El controlador adi_tmcl también utiliza servicios para tareas como la inicialización y el acceso a parámetros. Por ejemplo, /tmcl_gap_all recupera todos los valores de los parámetros de los ejes y /tmcl_ggp_all recupera todos los valores de los parámetros globales de la placa controladora.

Medición inercial para el seguimiento de la posición

Aunque los codificadores de rueda permiten a un sistema estimar la posición basándose en el recorrido de la rueda, la odometría de la rueda por sí sola suele ser insuficiente para un seguimiento preciso de la posición. El deslizamiento de las ruedas y las superficies irregulares pueden introducir errores significativos con el tiempo. Esto es especialmente preocupante en los numerosos entornos interiores en los que las señales GPS son poco fiables y no pueden proporcionar correcciones continuas.

Las IMU proporcionan una referencia de movimiento independiente que los AMR y los AGV pueden utilizar para mejorar la precisión del punto muerto. Un ejemplo destacado es la familia ADIS16500/05/07, que ofrece detección inercial de precisión de seis grados de libertad mediante giroscopios triaxiales y acelerómetros triaxiales, todo ello en un encapsulado BGA de 15 × 15 × 5 milímetros (mm). La calibración de fábrica caracteriza cada sensor en cuanto a sensibilidad, polarización, alineación y compensación de temperatura, lo que reduce la carga de integración para los diseñadores de sistemas.

Un ejemplo representativo es el ADIS16500AMLZ (figura 4). Esta pieza tiene un alcance del giroscopio de ±2000° por segundo (˚/s), una estabilidad del sesgo en marcha del giroscopio de 8.1° por hora (˚/h) y un recorrido aleatorio angular de 0,29° por raíz-hora (°/√h). Estas especificaciones ayudan a reducir la deriva con el paso del tiempo, mejorando el rendimiento del retroceso entre correcciones externas.

Figura 4: El ADIS16500AMLZ es una IMU MEMS de precisión en un encapsulado BGA compacto. (Fuente de la imagen: Analog Devices)

Para la integración en ROS 2, la familia ADIS16500/05/07 es compatible con el controlador imu_ros2. El controlador aprovecha el subsistema de E/S industrial de Linux a través de LibIIO. Su salida es compatible con los paquetes comunes de fusión de sensores de ROS 2, como robot_localization, que implementan filtros de Kalman extendidos para combinar datos de IMU y odometría.

Los diseñadores interesados en experimentar con la IMU pueden empezar con la tarjeta de evaluación ADIS16500/PCBZ (figura 5). Esta placa expone la interfaz SPI de la IMU a través de un cabezal de 16 pines compatible con cables de cinta de paso estándar de 2 mm.

Figura 5: La placa de evaluación ADIS16500/PCBZ expone la interfaz SPI a través de un cabezal de 16 patillas. (Fuente de la imagen: Analog Devices)

Detección de profundidad para la detección de obstáculos

La detección de obstáculos es otra característica estándar de AMR/AGV. Aunque el LiDAR destaca en la detección de obstáculos a mayor distancia, muchas aplicaciones también requieren la detección de campo cercano para detectar obstáculos de poca altura, discontinuidades del suelo u objetos que quedan fuera del plano de exploración del LiDAR. Las cámaras de profundidad ToF abordan esta carencia proporcionando imágenes de profundidad densas en un amplio campo de visión.

El módulo ToF ADTF3175BMLZ (figura 6) se adapta perfectamente a estos requisitos. Combinando un sensor de profundidad CMOS con una óptica de iluminación, el módulo captura fotogramas de profundidad y luminosidad activa (AB) de hasta 1024 × 1024 de resolución con un campo de visión de 75˚ × 75°. Esta combinación de resolución y cobertura lo hace muy adecuado para la supervisión de zonas de seguridad y la detección de suelos en entornos de almacén y fabricación en los que pueden aparecer obstáculos a distintas alturas.

Figura 6: El módulo ToF ADTF3175BMLZ integra un sensor de profundidad CMOS con óptica de iluminación. (Fuente de la imagen: Analog Devices)

El controlador adi_3dtof_adtf31xx facilita el acceso a los datos de la cámara mediante la publicación de fotogramas de profundidad y AB utilizando los formatos de mensaje estándar de ROS 2. Estas salidas se integran directamente con los paquetes de percepción habituales para tareas como la generación de nubes de puntos, la detección de suelos y la supervisión de burbujas de seguridad. El controlador también admite un modo de reproducción de archivos, lo que permite desarrollar y probar algoritmos sin una conexión física de hardware.

Para el desarrollo y la creación de prototipos, el kit EVAL-ADTF3175D-NXZ (figura 7) proporciona una plataforma de sensores completa. La característica más notable del kit es una placa basada en Arm® que ejecuta Linux y que puede alojar directamente el nodo ROS 2. Como alternativa, el sensor puede transmitir los datos de profundidad a través de Ethernet a un host ROS 2 independiente, lo que proporciona flexibilidad en diferentes arquitecturas de sistemas.

Figura 7: El kit de evaluación EVAL-ADTF3175D-NXZ incluye un host Linux basado en Arm. (Fuente de la imagen: Analog Devices)

La plataforma de referencia Analog Devices Autonomous Mobot (ADAM) demuestra cómo estos componentes compatibles con ROS se integran con soluciones adicionales para la gestión de la batería, la conversión de energía y las comunicaciones para formar un sistema AMR completo.

Conclusión

La complejidad del diseño y desarrollo de AMR y AGV puede reducirse en gran medida seleccionando componentes compatibles con ROS. Utilizar una fuente de componentes probada como ADI, que proporciona controladores ROS 2 para una amplia gama de sensores y actuadores y puede ser un socio valioso.