ROS 2: Nodos, Topics, Servicios y Acciones

El Robot Operating System 2 (ROS 2) permite que programas que se ejecutan de forma independiente intercambien datos tipados. Un driver de cámara, un controlador de motores, un planificador y una interfaz de usuario pueden ser nodos separados conectados a través del grafo de ROS. La decisión de diseño importante no es solo el tipo de mensaje; es si la interacción es un flujo, una petición corta, o un objetivo de larga duración.

Esta guía se mantiene neutral respecto a la distribución. Los comandos y los conceptos básicos son estables, pero los detalles de instalación y las versiones de paquetes deben seguir la documentación de la versión de ROS 2 que uses realmente.

Modela una responsabilidad por nodo

Un nodo es un participante en el grafo de ROS. Los buenos límites de nodo siguen a las responsabilidades: un driver de lidar publica barridos, un nodo de odometría estima el movimiento, y un navegador acepta objetivos. Evita hacer de cada función un nodo—la sobrecarga de procesos y comunicación se justifica cuando el límite mejora la reutilización, el aislamiento, el despliegue o la propiedad.

Los nombres hacen el grafo comprensible. Usa nombres de nodos e interfaces descriptivos como /front_lidar, /wheel_odometry y /cmd_vel. Los espacios de nombres permiten que dos robots ejecuten grafos equivalentes sin colisiones.

Inspecciona un sistema en marcha antes de cambiarlo:

ros2 node list
ros2 node info /wheel_odometry
ros2 topic list -t
ros2 service list -t
ros2 action list -t

node info revela los publicadores, los suscriptores, los servidores y clientes de servicios, y las acciones conectados a ese nodo. Suele ser la forma más rápida de encontrar una interfaz que falta o que tiene el nombre equivocado.

Usa topics para flujos continuos

Un topic es comunicación asíncrona de publicación y suscripción. Los publicadores envían mensajes tipados sin esperar una respuesta directa, y cualquier número de suscriptores puede recibirlos. Los topics encajan con datos que cambian a lo largo del tiempo:

• imágenes de cámara y barridos de lidar;
• estados de las articulaciones y odometría de las ruedas;
• estado de la batería;
• velocidad ordenada;
• eventos de diagnóstico.

Comprueba un flujo desde la línea de comandos:

ros2 topic echo /scan --once
ros2 topic hz /scan
ros2 topic info /scan --verbose

El tipo de mensaje es parte del contrato. Los marcos de referencia, las unidades, las marcas de tiempo y la covarianza son tan importantes como los nombres de los campos. Un suscriptor no puede interpretar una posición de forma segura si no sabe si el valor son metros en map o milímetros en el marco de una cámara.

Los ajustes de Quality of Service (QoS) afectan a la entrega. Los flujos de sensores suelen preferir datos recientes antes que retransmitir muestras obsoletas, mientras que un estado tipo configuración puede necesitar un comportamiento reliable o transient-local. Un publicador y un suscriptor con políticas QoS incompatibles pueden aparecer en el grafo pero no intercambiar ningún dato.

Usa servicios para petición y respuesta cortas

Un cliente de servicio envía una petición y espera la respuesta de un servidor. Los servicios encajan con operaciones rápidas que tienen una respuesta definite:

• leer o actualizar una configuración;
• restablecer la odometría;
• limpiar un mapa;
• preguntar si un componente está listo.

Encajan mal con datos de sensor continuos o con una maniobra que puede tardar segundos. Una llamada síncrona que espera a una acción lenta de motor puede bloquear a quien llama y no proporciona ningún mecanismo estándar de progreso ni de cancelación.

Inspecciona y llama a un servicio con:

ros2 service type /reset_odometry
ros2 interface show example_interfaces/srv/Trigger
ros2 service call /reset_odometry example_interfaces/srv/Trigger "{}"

El tipo exacto en el último comando debe coincidir con el del servidor. Diseña las respuestas para que indiquen tanto el éxito del transporte como el estado significativo de la operación; recibir una respuesta no garantiza que la acción de hardware solicitada fuera posible.

Usa actions para objetivos de larga duración

Una action modela un objetivo que lleva tiempo. Soporta aceptación del objetivo, feedback periódico, un resultado final, y cancelación o apresamiento. Navegar a una pose y mover un brazo a lo largo de una trayectoria son actions naturales.

La interacción tiene tres partes semánticas:

• Goal (objetivo): lo que el cliente quiere, como una pose destino.
• Feedback: el progreso mientras se ejecuta, como la distancia restante.
• Result: el desenlace terminal y cualquier dato devuelto.

Los servidores de actions deberían responder con prontitud a la cancelación y dejar el hardware en un estado documentado. Un cliente debería manejar el rechazo, la cancelación, el aborto y el éxito en vez de tratar todo resultado terminal como una finalización.

Desde la línea de comandos:

ros2 action info /navigate_to_pose
ros2 action send_goal /navigate_to_pose <action_type> '<goal_yaml>' --feedback

Sustituye los marcadores de posición por el tipo y los campos que indique el grafo en marcha. Usa el comando para inspeccionar el comportamiento, no como una interfaz de producción fijada en el código.

Decide con una sola tabla de decisión

Un topic no es automáticamente «rápido», y un service no es automáticamente «fiable». La temporización y la entrega dependen del QoS, el middleware, los ejecutores, la carga de trabajo y la red. Decide primero por la semántica de la interacción.

Un mismo comportamiento puede usar las tres. Un nodo de navegación se suscribe a los topics de barridos y odometría, acepta una action de navegación, y expone un service corto para limpiar un mapa de costes. Los límites siguen claros porque cada interfaz responde a un tipo de pregunta distinto.

Diseña un grafo pequeño para un robot móvil

Considera un robot de tracción diferencial:

1. /encoder_driver publica los conteos de las ruedas.
2. /odometry se suscribe a los conteos, publica /odom y difunde odom → base_link.
3. /range_driver publica medidas de distancia.
4. /safety_controller se suscribe a las distancias y limita /cmd_vel.
5. /navigator acepta una action de movimiento y publica la velocidad deseada.

No dejes que dos nodos sin relación ordenen los motores sin arbitraje. Dale a un componente la propiedad de la orden final al actuador, o haz explícita la regla de prioridad.

Usa los tipos de mensaje estándar de ROS cuando su semántica encaje. Las interfaces personalizadas son apropiadas cuando el contrato de datos es realmente específico del proyecto, no solo para renombrar campos existentes.

Depura el grafo capa a capa

Cuando falten datos:

1. Confirma que ambos nodos aparecen en ros2 node list.
2. Confirma los nombres y los tipos de las interfaces.
3. Inspecciona los recuentos de publicadores y suscriptores.
4. Compara las políticas QoS.
5. Haz echo de un mensaje y comprueba las marcas de tiempo y los IDs de marco.
6. Revisa los registros y la carga de los ejecutores.

Cuando una action nunca termina, distingue entre «objetivo no aceptado», «el servidor dejó de producir feedback» y «el cliente ignoró el resultado». Cuando un service se cuelga, comprueba si la callback del servidor está bloqueada esperando un trabajo que debería haber sido una action.

Evita los errores de arquitectura habituales

• Todo usa un topic: quien llama no puede saber si una petición puntual tuvo éxito.
• El movimiento usa un service: el trabajo largo se queda sin semántica de progreso ni de cancelación.
• Los datos de sensor usan por defecto una cola profunda y fiable: las muestras obsoletas se acumulan cuando el procesado se queda atrás.
• Las convenciones de marco y unidades están sin documentar: los mensajes tipados siguen siendo semánticamente ambiguos.
• Un único nodo gigante es dueño de todos los subsistemas: desaparecen las pruebas y el aislamiento de fallos.
• Docenas de nodos diminutos envuelven funciones corrientes: el grafo se vuelve más difícil sin añadir un límite útil.

El Robot Arm Simulator ofrece una tarea concreta parecida a una action: pedir un destino, observar el movimiento, e informar de desenlaces inalcanzables o restringidos. Continúa con marcos de coordenadas TF2 de ROS 2 para mantener consistente la geometría de cada nodo.