Fundamentos de ROS 2: nodos, marcos TF2 y visión robótica
Podrá estructurar un robot en nodos de ROS 2, discriminar topics, servicios y acciones e integrar observaciones de visión artificial en el árbol TF2.
Todo lo demás de este sitio funciona sobre un microcontrolador: un programa, un bucle, control total. ROS 2 es a lo que se muda cuando un robot crece más allá de eso, cuando tiene una cámara y un planificador y una pila de drivers que necesitan correr a la vez, escritos por gente distinta y reiniciables de forma independiente.
El precio es un conjunto nuevo de ideas, y la primera es que un robot con ROS 2 no es un programa sino un grafo de nodos que se hablan entre sí. Buena parte de la confusión inicial es elegir mal entre las cuatro formas en que pueden hablar, así que por ahí empieza esta ruta: topics para flujos, servicios para peticiones rápidas, acciones para trabajos largos que quizá necesite cancelar.
Después TF2, que es la parte que en silencio derrota a la gente. Un robot es un árbol de marcos de coordenadas —la base, las ruedas, cada sensor— y casi todo fallo real es una transformación que falta, que está obsoleta, o que está colgada del padre equivocado. Una vez que los marcos tienen sentido, una cámara calibrada deja de ser más que otro nodo publicando una postura en ese árbol, que es exactamente como la visión se une al resto del robot.
Antes de empezar
Debe sentirse cómodo en una línea de comandos de Linux y ser capaz de leer Python o C++. Una Raspberry Pi es el objetivo habitual, pero todo lo anterior a los nodos de hardware funciona en un portátil. Cuente con que el montaje en sí lleva una tarde: ROS 2 es un sistema distribuido y se comporta como uno desde el primer comando.
Lo que podrá hacer
- Elegir correctamente entre topic, servicio y acción, en vez de convertirlo todo en topics y descubrir los límites más tarde.
- Construir un árbol de marcos TF2 que transforme un punto del marco de un sensor al del robot, y depurarlo cuando falte una transformación.
- Calibrar una cámara, obtener la postura de un marcador, y entender respecto a qué son los números.
- Convertir un twist
cmd_velen velocidades de rueda izquierda y derecha, con saturación que conserve el arco comandado.
Dónde se atasca la gente
Los nodos no se ven entre sí. El descubrimiento de ROS 2 es automático hasta que deja de
serlo. Dos máquinas con valores distintos de ROS_DOMAIN_ID son invisibles la una para la otra, y
un Wi-Fi que bloquea el multicast rompe el descubrimiento por completo mientras todos los nodos se
informan de que están perfectamente sanos.
QoS incompatibles. Un publicador que ofrece best-effort y un suscriptor que exige reliable nunca se conectarán, y —para nada útil— ninguno de los dos registra un error. El topic sencillamente no transporta nada. Los datos de sensor son el culpable habitual, ya que los drivers de sensor suelen venir por defecto en best-effort.
Olvidar hacer source del workspace. Una terminal nueva no sabe nada de sus paquetes hasta que
hace source, así que ros2 run informa de un paquete que existe claramente como ausente.
Un marco con dos padres. TF2 es un árbol. Publicar el mismo marco hijo desde dos fuentes le da dos padres, y las consultas empiezan a fallar intermitentemente según el momento: uno de los fallos de ROS más difíciles de ver, porque funciona la mayor parte del tiempo.
Marcas de tiempo y frame IDs vacíos. Un mensaje cuyo header no tiene frame_id no se puede
transformar, y uno cuya marca es cero no se alinea con nada. Ambos atraviesan el sistema de tipos
sin quejarse y fallan solo cuando algo intenta usarlos juntos.
Qué necesita
| Qué | Por qué lo necesita esta ruta | Notas |
|---|---|---|
| Una línea de comandos de Linux en la que se sienta cómodo | ROS 2 es un sistema pensado primero para Linux y el instrumental lo asume | Ubuntu coincide con los binarios oficiales; cualquier otra cosa implica compilar |
| Python o C++ | El código de los nodos se escribe en uno de los dos | Python se aprende más rápido; C++ es lo que usan los nodos críticos en rendimiento |
| Una máquina con pantalla real | Depurar un sistema distribuido por SSH es innecesariamente doloroso | Un portátil es mejor objetivo de aprendizaje que una Pi sin pantalla |
| Una Raspberry Pi (solo nodos de hardware) | Solo hace falta cuando el robot lleva su propio ordenador | Pi 4 o mejor; una Pi Zero decepcionará |
| Una cámara (solo el nodo de visión) | El último nodo de la ruta | Un módulo Pi Camera o cualquier webcam UVC |
| Una tarde para el montaje | No es una broma: esto es parte de la ruta | La instalación es de verdad el primer paso difícil |
Por qué la ruta sigue este orden
Los patrones de comunicación van primero porque elegir mal sale caro después. Las cuatro formas en que hablan los nodos de ROS 2 no son intercambiables, y el fallo estándar del principiante es convertirlo todo en topics, y luego descubrir, trescientas líneas dentro, que necesitaba cancelación y realimentación de progreso y llevaba reimplementando acciones a mano. Diez minutos decidiendo entre topic, servicio y acción ahorran una reescritura.
TF2 va segundo porque es la parte que en silencio derrota a la gente. Una vez que varios nodos publican datos sobre el mundo físico, cada uno de ellos significa «3 metros» respecto a algo distinto: la cámara, la base, el mapa. TF2 es cómo se relacionan esos, y la mayoría de los fallos reales de ROS son una transformación que falta, que está obsoleta, o que está colgada del padre equivocado. Aprenderla como materia, antes de necesitarla, sale mucho más barato que toparla como un fallo de consulta misterioso.
La calibración de cámara va tercera porque depende por completo de la segunda. Una postura de marcador no significa nada sin saber respecto a qué está. Una vez que los marcos tienen sentido, una cámara calibrada es justo otro nodo publicando una postura en el árbol, y la visión deja de ser un caso especial.
El nodo de tracción cierra la ruta porque es donde ROS se encuentra con el hardware del que
trata todo lo demás de este sitio. Un twist cmd_vel es la interfaz estándar que habla todo
componente de navegación de ROS, y convertirlo en velocidades de rueda izquierda y derecha —con
saturación que conserve el arco comandado en vez de deformarlo— es el puente entre el mundo de ROS
y el mundo de los motores.
Puntos de control: cómo saber que una etapa caló
| Etapa | La comprobación | Qué es un aprobado |
|---|---|---|
| Instalación | ros2 topic list en una terminal nueva |
Funciona tras el source, y ya sabe por qué falla antes de hacerlo |
| Dos nodos | Ejecute talker y listener en dos máquinas | Los mensajes llegan, y puede nombrar el domain ID que comparten |
| Topic frente a servicio | Escriba uno de cada para los mismos datos | Puede decir en una frase por qué cada patrón encaja con su trabajo |
| Acciones | Arranque una acción larga y cancélela a mitad | Se detiene limpiamente, y recibió realimentación mientras corría |
| QoS | Incompatibilice la fiabilidad a propósito en un topic | No transporta nada en silencio: ahora reconoce el síntoma |
| Árbol TF2 | Ejecute ros2 run tf2_tools view_frames |
Un árbol, una raíz, ningún marco con dos padres |
| Consulta de transformación | Transforme un punto del marco de un sensor al marco de la base | El número es correcto, y puede contrastarlo con una cinta métrica |
| Transformaciones obsoletas | Detenga un publicador de transformaciones mientras se hace una consulta | Obtiene un error de extrapolación: el fallo ya tiene nombre |
| Calibración de cámara | Calibre y compruebe el error de reproyección | Bien por debajo de un píxel; un valor grande significa que el conjunto de capturas fue pobre |
| Postura de marcador | Ponga un marcador a una distancia medida y lea su postura | Coincide con la cinta métrica, y puede decir en qué marco está |
cmd_vel |
Publique un twist con término lineal y angular | Ambas ruedas giran bien, y saturar una escala la otra para conservar el arco |
Dónde termina esta ruta
Esta ruta construye los cimientos que hay bajo un robot con ROS 2: cómo hablan los nodos, cómo se relacionan los marcos, y cómo un sensor y un tren motriz se unen al grafo. Se detiene deliberadamente antes de los grandes subsistemas que dan por supuesto todo eso.
No cubre la pila Nav2, que es la respuesta estándar a la navegación autónoma en ROS 2 y es un
sistema en sí mismo de considerable envergadura: mapas de coste, árboles de comportamiento,
planificadores y controladores, todo configurado en vez de escrito. Nav2 da por supuesto un árbol TF
en marcha y una interfaz cmd_vel, que es exactamente lo que le da esta ruta.
No cubre URDF ni la descripción del robot, el formato XML que le dice al resto de ROS qué forma tiene su robot. Todo lo de aquí publica transformaciones a mano; URDF es la forma de dejar de hacerlo.
No cubre la simulación en Gazebo, que es como ocurre en realidad la mayor parte del desarrollo serio de ROS, ni ros2_control, la capa estándar de abstracción de hardware para trenes motrices reales.
Y no cubre el comportamiento en tiempo real. ROS 2 está construido sobre DDS y es mucho más capaz aquí de lo que era ROS 1, pero una máquina Linux ejecutando un nodo de Python no es un sistema de control en tiempo real. Los lazos rápidos —equilibrio, control de corriente, cualquier cosa a kilohertz— siguen perteneciendo a un microcontrolador, con ROS 2 por encima. Esa división es la arquitectura normal de un robot serio, no un compromiso.
Ruta de aprendizaje
La ruta
Sigue los nodos en orden: cada uno desbloquea el siguiente cuando lo completas. Tu progreso se guarda en este dispositivo.
0 / 5 completados
Preguntas comunes
Preguntas frecuentes
¿Cuándo conviene migrar un robot desde Arduino hacia ROS 2?
Cuando un único bucle secuencial resulta insuficiente. Un microcontrolador ejecutando un programa continuo es la arquitectura óptima y determinista para seguidores de línea o laberintos. ROS 2 justifica su complejidad cuando la plataforma requiere ejecutar de forma concurrente procesos con cadencias heterogéneas (visión artificial, planificadores globales de trayectoria y capas de comunicación de red) desarrollados de forma modular e independientemente reiniciables. La contrapartida es gestionar un sistema distribuido.
¿Topic, servicio o acción: cómo elegir en ROS 2?
Adaptando el patrón a la naturaleza de la tarea. Un topic es un flujo de datos unidireccional sin confirmación (telemetría de sensores, odometría continua, comandos periódicos de velocidad) donde prima recibir el dato más reciente. Un servicio es una petición síncrona inmediata con respuesta rápida (milisegundos), como consultar un parámetro o conmutar un modo. Una acción se destina a misiones prolongadas en el tiempo que exigen reporte continuo de progreso y posibilidad de cancelación (navegar a un destino o cerrar una pinza).
¿Por qué mis nodos de ROS 2 no se descubren entre sí?
Principalmente por tres factores. Discrepancia en la variable ROS_DOMAIN_ID: dos equipos con identificadores distintos permanecen completamente aislados sin emitir avisos de error. Redes Wi-Fi que bloquean el tráfico multicast: impiden la autonegociación DDS, razón por la cual los nodos suelen funcionar en Ethernet por cable pero fallan en puntos de acceso inalámbricos corporativos. Incompatibilidad en la Calidad de Servicio (QoS): si el publicador emite en modo best-effort y el suscriptor exige reliable, el enlace nunca se establece.
¿Qué es TF2 y por qué fallan las transformaciones de coordenadas?
TF2 mantiene el árbol cinemático de marcos espaciales del robot (chasis base, ruedas, articulaciones y sensores) para transformar coordenadas entre cualquier par de sistemas de referencia. Los errores provienen de: asignar dos nodos padre a un mismo marco hijo (violando la estructura en árbol), emitir encabezados con frame_id vacío (impidiendo ubicar el dato) o consultar transformaciones con marcas temporales desfasadas o nulas. Estos tres fallos superan la compilación pero rompen el flujo en tiempo de ejecución.
¿Es indispensable una Raspberry Pi para aprender ROS 2?
No. Salvo los controladores directos de hardware físico, el núcleo de nodos, visualizadores y algoritmos se ejecuta directamente en un ordenador portátil con Linux, ofreciendo compilaciones más veloces y herramientas gráficas como RViz. La placa monoplaca se hace indispensable cuando el robot móvil debe portar su propia computación autónoma. En ese caso, una Raspberry Pi 4 de 4 GB o superior representa el mínimo aconsejable.
¿Por qué ros2 run reporta que el paquete no existe si está compilado?
Porque no se ha ejecutado el comando 'source' sobre el entorno de trabajo (workspace) en ese terminal. Cada nuevo terminal arranca sin visibilidad de los paquetes compilados hasta que se carga el script de instalación (source install/setup.bash). Es el contratiempo más recurrente en ROS 2; una práctica común consiste en añadir dicha instrucción al archivo .bashrc, teniendo la precaución de aislarlo si se manipulan múltiples entornos simultáneos.