Introducción a ROS 2: Distribución segura del control de robots entre nodos, temas y DDS.

ROS 2 no es el robot en sí. Es la base para ejecutar el controlador de la cámara, la autolocalización, la planificación de trayectorias y el control de motores como programas independientes (nodos), combinándolos mediante mensajería y comunicación estandarizadas. Puedes comenzar con un solo archivo Python en la etapa de prototipo y escalar a C++, ejecución en tiempo real, múltiples computadoras y monitoreo de seguridad para un producto completo. Lo importante no es memorizar la API, sino diseñar quién es el propietario de los datos, la sincronización, la fiabilidad y el estado seguro al apagar el sistema.

ROS 2

Imagen: Robot Logotipo del Sistema Operativo, Wikimedia Commons (CC BY-SA 4.0). El logotipo identifica el middleware y no garantiza una distribución o configuración DDS específica.

Resumen de 30 segundos

• Un nodo es un proceso con una responsabilidad, un tema representa un flujo continuo, un servicio representa una solicitud/respuesta breve y una acción representa una tarea larga con retroalimentación intermedia.

• La comunicación de ROS 2 se ejecuta en DDS, y la calidad de servicio (fiabilidad, historial, profundidad, durabilidad, plazo) se puede configurar para cada extremo. Los sensores y el control no necesitan usar la misma configuración.

• TF2 gestiona un árbol de sistemas de coordenadas junto con el tiempo. Si se mezclan los sistemas de coordenadas map, odom, base_link y los de los sensores, el robot se dirigirá al lugar incorrecto, incluso si la percepción es correcta.

• En hardware real, se debe añadir gestión del ciclo de vida, mecanismos de vigilancia, separación de privilegios, registro de eventos y mecanismos de seguridad para la detección de fallos de red. Trabajar en simulación no garantiza la seguridad.

• Se debe corregir desde el principio una versión con soporte a largo plazo como ROS 2 Jazzy, junto con una combinación adecuada de DDS, sistema operativo y controlador, y crear un entorno de trabajo reproducible.

1. Panorama general de ROS 2

Figura 1 — En ROS 2, los nodos se descubren y se comunican entre sí mediante DDS. No solo los nombres de los temas, sino también la QoS, el tipo, el tiempo y el sistema de coordenadas se tratan como parte del contrato.

Un gráfico de ROS 2 se puede configurar en tiempo de ejecución. Un nodo de cámara publica imágenes, un nodo de percepción se suscribe a ellas y un nodo de control toma los resultados, junto con la autolocalización, y publica comandos de velocidad. Incluso si se traslada un nodo a un ordenador diferente, el mismo gráfico se mantiene siempre que el descubrimiento y la serialización DDS funcionen correctamente.

2. Elección de la primitiva de comunicación adecuada

Un mensaje de tema debe contener no solo el valor, sino también header.stamp y frame_id. Si la marca de tiempo de la imagen y la del IMU no están sincronizadas, el algoritmo aún puede calcular un resultado, pero estimará erróneamente el movimiento. Reenviar imágenes de la cámara con fiabilidad puede saturar el ancho de banda, por lo que se debe elegir la QoS adecuada para cada sensor.

3. QoS como un "contrato de comunicación"

Los ajustes mínimos de QoS que se deben verificar en ROS 2 son: Fiabilidad (Mejor esfuerzo/Fiable), Durabilidad (Volatil/Transitorio local), Historial (Conservar último/Conservar todo), Profundidad, Plazo límite y Viabilidad. Un LiDAR de alta velocidad puede ser adecuado para Mejor esfuerzo, que descarta los paquetes obsoletos, mientras que los comandos de velocidad, que no toleran la pérdida de mensajes, deben usar Fiable con un Plazo límite corto.

Si la calidad de servicio (QoS) del emisor y del suscriptor no son compatibles, no se comunicarán ni siquiera con el mismo nombre de tema. Verifique la configuración real con ros2 topic info -v /scan en lugar de confiar ciegamente en la configuración preestablecida del controlador del sensor. Al cruzar una red, pruebe la MTU, la retransmisión Wi-Fi, las restricciones de multidifusión y la sincronización horaria simultáneamente.

4. TF2 y tiempo

La pose de un robot se expresa como una transformación entre sistemas de coordenadas. Un árbol típico se ve así:

map ──(SLAM/Localization)──> odom ──(odometry)──> base_link
                                                        ├── base_laser
                                                        ├── imu_link
                                                        └── camera_link

map es el sistema de coordenadas global a largo plazo, odom es la odometría suave a corto plazo y base_link es el sistema de referencia del vehículo. SLAM corrige map → odom, mientras que la estimación de la rueda/IMU actualiza odom → base_link a alta velocidad. TF2 almacena transformaciones con marcas de tiempo y las interpola al tiempo de adquisición de cada sensor.

Estandarice los sistemas de coordenadas como diestros y explicite la diferencia entre el sistema óptico (z hacia adelante, x a la derecha, y hacia abajo) y el sistema del vehículo (x hacia adelante, y a la izquierda, z hacia arriba). Corrija las transformaciones estáticas con static_transform_publisher y no publique una transformación dinámica como estática. Un ciclo o múltiples padres en el árbol TF es un error de diseño.

5. Paquetes y flujo de implementación

Un nodo mínimo de Python para ROS 2 tiene este aspecto.

import rclpy
from rclpy.node import Node
from std_msgs.msg import Float32

class Speed(Node):
    def __init__(self):
        super().__init__('speed_node')
        self.pub = self.create_publisher(Float32, '/speed', 10)
        self.timer = self.create_timer(0.02, self.tick)  # 50 Hz
    def tick(self):
        msg = Float32(); msg.data = 0.2
        self.pub.publish(msg)

rclpy.init(); node = Speed(); rclpy.spin(node)

En hardware real, no envíe comandos de velocidad directamente al motor; coloque un nodo aguas arriba, limitación de velocidad, parada de emergencia y monitorización del hardware entre ellos. Incluso al usar rclcpp de C++, verifique los grupos de devolución de llamada, el ejecutor, la asignación de memoria y el comportamiento en tiempo real.

Separe el espacio de trabajo en src, build, install y log, y resuelva las dependencias con rosdep. Fije el sistema operativo, DDS y el compilador con Docker o un contenedor de desarrollo, e integre ros2 doctor, ros2 node list, ros2 topic hz y tf2_tools en los diagnósticos de CI y de campo.

6. Ciclo de vida y seguridad

Los sensores y actuadores no necesariamente deben aceptar comandos al encenderse. Las transiciones de estado del nodo de ciclo de vida (Sin configurar → Inactivo → Activo → Finalizado) gestionan de forma independiente la inicialización del controlador, la calibración, las comprobaciones de comunicación y la autorización de salida. Si un temporizador de vigilancia pierde su señal, se debe anular el comando de velocidad y activar el freno o el relé en el hardware.

En cuanto a la seguridad, la comunicación de mensajes de ROS 2 por sí sola no cumple con los estándares de seguridad funcional. Se debe verificar el alcance aplicable de las normas IEC 61508/ISO 26262/ISO 13849 y similares, y separar las funciones de seguridad en un sistema de monitorización, un microcontrolador certificado y una parada de emergencia física. Al conectarse a una red, se deben utilizar claves y certificados de SROS 2, seguridad DDS, control de acceso y auditoría de registros.

7. Ecosistema actual e investigación

Nav2 integra la autolocalización, el mapeo, la planificación de trayectorias y el control mediante acciones y la gestión del ciclo de vida, y ros2_control estandariza la interfaz entre el hardware y los controladores. MoveIt 2 gestiona la cinemática del manipulador, la detección de colisiones y la planificación de trayectorias. La simulación en Gazebo o Webots y la reproducción de los registros de los sensores con rosbag2 permiten realizar pruebas de regresión sin detener el robot real.

La investigación avanza en la comunicación sin copia, las canalizaciones de imágenes tipadas que utilizan GPU/NPU, los ejecutores deterministas, el aprendizaje distribuido y la robótica en la nube que va más allá de DDS. Al adoptar una nueva función, pruebe no solo los benchmarks, sino también la caída de la red, la desviación temporal, los reinicios de procesos, la pérdida de sensores y la longitud incorrecta de los mensajes.

Resumen

ROS 2 transforma un robot, de un conjunto de piezas a un sistema distribuido reutilizable. Diseña las responsabilidades de los nodos, la calidad de servicio (QoS) de los temas, las coordenadas y la sincronización de TF2, el ciclo de vida y los estados seguros desde el principio, y todo el sistema se mantendrá robusto incluso al cambiar de algoritmos.