En el mundo de la robótica enormes y complejos sistemas pueden llegar a diseñarse. Para hacerlo de una forma elegante y limpia, aunque también funcional, existe ROS. Robot Operating System es un framework para el desarrollo de software para robots muy extendido y con razón. Voy a comenzar a escribir una serie de entradas en relación a esto porque pienso que merece mucho la pena ver cómo funcionan las bases de este.
Conceptos básicos: qué son y qué hacen los nodos. Nodos que publican y/o suscriben datos
En ROS los nodos y la comunicación que existe entre ellos conforman el corazón del sistema a diseñar. Un nodo es simplemente un programa, un breve puñado de código que puede usar el core de ROS (roscore) para comunicarse.
Un nodo puede activarse de manera independiente de otros nodos, aunque su existencia solo cobra sentido cuando efectúa algún tipo de comunicación. Estos nodos pueden ejecutarse en una misma máquina, o pueden distribuirse por una red de estas. Mientras logren comunicarse, sirve.
Pueden comunicarse entre sí y, últimamente, con sensores o actuadores (servomotores, sensores de velocidad, etc.). Este intercambio de datos se da gracias a los 5 grandes: mensajes, topics, publishers, subscribers y, en el centro de todos esto, roscore.
Como verán muchos de estos conceptos se autodescriben a sí mismos. Un publisher se dedica a publicar un determinado mensaje. Un mensaje consta de un paquete de bits representado por diferentes campos. Digamos de forma muy simplista que un conjunto de estos hacen referencia al tipo del mensaje (Float64), y el resto al contenido como tal.
De este modo, un nodo cuyo propósito sea publicar información sobre un sensor, publicará esta y el subscriber interesado cogerá la información cuando la necesite, o esté disponible. De hecho, algo interesante es que un subscriber puede ser ejecutado incluso antes de que la información que necesite esté disponible. Digamos que pueden esperar.
Así mismo, cualquier mensaje publicado puede ser suscrito por más de un subscriber, si es que en un momento dado necesitan tal información para hacer otro tipo de cálculos. Además, un subscriber puede recibir mensajes de varios publishers, si el programador así lo ha diseñado en el nodo.
Lo que tenemos aquí es un sistema muy claro de: nodo A publica cierta información y nodo B la recibe cuando esté disponible. Esta es la comunicación entre nodos en la que se basa ROS. Pero aún hay algo más que no he mencionado. ¿Qué papel tienen los topics y roscore en esto?
Pues suele pasar que el mismo tipo de información es publicada por más de un nodo. ¿No es esto redundante? "Eliminemos uno de ellos". Pues no, no tiene por qué serlo. De hecho, pensemos que un nodo publica información sobre la velocidad objetivo dada por un joystick, y que el otro publica el mismo tipo de información de velocidad objetivo pero viene dada por un controlador de movimiento software. ¿Con cuál nos quedamos? ¿Desactivamos uno?
No es necesario, ni recomendable en muchos escenarios. El nodo que está a la espera de esa información necesita saber cuál de ambas es la correcta, y para esto están los topics. La lógica es la siguiente: los nodos que publican deben conocer a qué tópico van a hacerlo (pensadlo como si fuese una categoría), y nada más. Por su parte, los nodos subscriber deben conocer el topic también. De este modo abstraemos la comunicación y los subscriber no necesitan saber el publisher que les está proveyendo la información. ¿Pero igualmente quién coordina esto? Es roscore el núcleo, el máster encargado de coordinar qué nodo va a publicar en un momento dado. Así el código escrito en ambas partes, publishers y subscribers, es mucho más modularizado, permitiendo al programador escribir nuevos nodos que trabajen sobre un mismo topic y reemplazarlos en cualquier momento.
El núcleo de ROS, roscore, solo puede ser ejecutado una vez en una máquina, en una terminal. Sin este, el sistema al conjunto se caerá.
¿He dicho ya que un nodo puede ser tanto publisher como subscriber al mismo tiempo?
No hay comentarios:
Publicar un comentario