ROS, siglas de Robot Operating System, es un conjunto gratuito y de código abierto de bibliotecas y herramientas para desarrollar software de robots. Pese a su nombre, no es un sistema operativo como Windows o Linux. Funciona sobre uno de ellos, casi siempre Ubuntu Linux, y ofrece a los numerosos programas de un robot una forma común de intercambiar datos, compartir drivers y aprovechar el trabajo de los demás.

El nombre se presta a mucha confusión, así que conviene precisar qué abarca ROS. Organiza muy bien todo lo que ocurre dentro de un robot: el escáner láser, las ruedas, el mapa, el planificador. En cambio, tiene mucho menos que decir sobre el edificio en el que trabaja el robot, con sus puertas, ascensores y sensores, y las personas que necesitan enterarse cuando algo falla. Dónde termina una cosa y empieza la otra es una cuestión práctica para cualquiera que despliegue robots fuera del laboratorio.

Lo esencial

  • ROS es middleware: un sistema de mensajería, un conjunto de convenciones y una amplia biblioteca de paquetes reutilizables que funcionan sobre un sistema operativo convencional.
  • Dentro de un robot, pequeños programas llamados nodos publican flujos de datos con nombre, los llamados topics, y se suscriben a ellos, de modo que el driver de un lidar y un planificador de navegación pueden escribirlos personas distintas y aun así funcionar juntos.
  • ROS 2 es la generación actual; ROS 1 llegó al final de su vida útil en mayo de 2025, así que los proyectos nuevos parten de una versión de soporte a largo plazo de ROS 2.
  • ROS coordina las piezas de un robot. Conectar ese robot con las puertas, los sensores y las alarmas de unas instalaciones requiere una capa aparte por encima.

¿Qué es un sistema operativo robótico?

Un robot es un conjunto de hardware de distintos fabricantes: un escáner láser de un proveedor, controladoras de motor de otro, cámaras, sensores de choque, una placa de gestión de la batería. Cada pieza llega con su propia interfaz. Antes de ROS, cada laboratorio y cada empresa escribía su propio código de integración para que esas piezas se entendieran, y muy poco de ese código servía para el siguiente robot.

Un sistema operativo robótico resuelve esto situándose entre los drivers del hardware y el comportamiento del robot. Da a los programas una forma estándar de enviarse datos, de manera que el código que lee el láser no necesita saber quién utiliza lo que produce. Define formatos de mensaje estándar para los datos más habituales, como un barrido láser, una imagen de cámara o una orden de velocidad. Y trae herramientas para grabar datos, visualizar lo que ve el robot y simularlo antes de que toque hardware real.

Lo de «sistema operativo» es una metáfora. Igual que un sistema operativo permite a las aplicaciones olvidarse de qué disco o tarjeta de red tiene el ordenador, ROS permite al software del robot olvidarse de qué marca de escáner lleva atornillada, siempre que un driver publique el mensaje estándar.

ROS nació en 2007, con los primeros trabajos en Stanford y el desarrollo en la empresa de robótica Willow Garage. Hoy lo mantienen Open Robotics y la Open Source Robotics Foundation, y una gran comunidad de empresas y universidades aporta paquetes. Dos de los más conocidos son Nav2, la pila de navegación para robots móviles, y MoveIt, que planifica el movimiento de brazos robóticos.

¿Cómo funciona un sistema operativo robótico?

La forma más sencilla de entenderlo es seguir a un robot concreto. Pensemos en un robot de reparto que lleva suministros por el pasillo de un hospital.

  1. Un nodo driver lee el escáner láser y publica cada barrido en un topic llamado /scan, entre diez y cuarenta veces por segundo, aproximadamente, según el sensor.
  2. Un nodo de localización se suscribe a /scan y a la odometría de las ruedas, los compara con un mapa guardado y publica dónde cree el robot que se encuentra.
  3. La pila de navegación recibe un objetivo, como «ir a la sala 3», planifica una ruta que esquiva los obstáculos del último barrido y publica órdenes de velocidad en un topic llamado /cmd_vel.
  4. Un nodo controlador de motores se suscribe a /cmd_vel y convierte esas órdenes en velocidades de rueda.

Ninguno de estos nodos llama directamente a otro. Solo comparten los nombres de los topics y los tipos de mensaje, así que basta con sustituir un único nodo driver para cambiar el escáner láser por otro modelo.

Los topics están pensados para flujos continuos. ROS ofrece otros dos patrones para tareas distintas. Un servicio es una petición con respuesta rápida, como «guarda el mapa actual». Una acción es un objetivo de larga duración que informa de su progreso y puede cancelarse, y es así como suele enviarse «ir a la sala 3». Los parámetros configuran los nodos, y los archivos launch arrancan todo un conjunto de nodos con un solo comando.

Hay otra pieza que hace mucho trabajo sin hacerse notar: tf2, la biblioteca de transformaciones. Cada sensor va montado en algún punto del robot y cada mapa tiene su propio origen. tf2 registra cómo se relacionan todos esos sistemas de coordenadas a lo largo del tiempo, de modo que, si la cámara ve un obstáculo 1,2 metros por delante y 30 centímetros a la izquierda, el planificador puede convertirlo en una posición del mapa sin que cada nodo tenga que hacer su propia geometría.

Alrededor de este núcleo están las herramientas de uso diario: RViz para ver en 3D los datos de los sensores y los planes del robot, rosbag para grabar y reproducir topics, y el simulador Gazebo para probar un robot en un mundo virtual.

En ROS 2, la capa de mensajería funciona sobre DDS (Data Distribution Service), un estándar industrial de publicación/suscripción. Los nodos se descubren entre sí en la red sin el proceso maestro central que necesitaba ROS 1, y cada topic puede llevar ajustes de calidad de servicio, por ejemplo si los mensajes perdidos deben reenviarse.

ROS 1 vs ROS 2: ¿qué sistema operativo robótico elegir?

La mayoría de los equipos que empiezan hoy ya saben que van a usar ROS. Lo que les queda por decidir es la generación y la versión, y si alguna parte del robot debe funcionar con otra cosa.

ROS 1 ROS 2
Estado Última versión: Noetic, fin de vida en mayo de 2025 En desarrollo activo, nueva versión cada mayo
Mensajería Protocolo propio con un maestro central DDS, sin punto único de fallo
Soporte a largo plazo Ninguno a partir de ahora Versiones LTS con cinco años de soporte, p. ej., Jazzy Jalisco hasta 2029
Seguridad Sin seguridad de transporte integrada SROS2 añade cifrado y control de acceso
Indicado para Mantener robots existentes Proyectos y productos nuevos

En la práctica, la elección depende de unas pocas preguntas:

  • Drivers. ¿El fabricante del sensor o del brazo ofrece un driver para ROS 2? Que falte un driver puede costar más tiempo que todo lo demás junto.
  • Ritmo de versiones. Cada mayo sale una nueva versión de ROS 2. Las de los años pares tienen cinco años de soporte y las intermedias, alrededor de año y medio, por lo que los productos suelen fijar una versión LTS y planificar el salto a la siguiente.
  • Hardware pequeño. micro-ROS lleva los conceptos de ROS 2 a los microcontroladores, de modo que una placa de sensores puede incorporarse directamente a los topics del robot.
  • Brazos industriales. Muchos brazos industriales se programan con el controlador y el lenguaje propios del fabricante. A menudo ROS funciona junto a ese controlador en lugar de sustituirlo, una vía en la que el consorcio ROS-Industrial lleva años trabajando.

También conviene planificar la red desde el principio. DDS descubre los nodos automáticamente, algo cómodo en un banco de pruebas, pero que genera mucho tráfico en una red corporativa compartida con muchos robots. Los equipos suelen separar los robots con identificadores de dominio DDS, limitar el descubrimiento a hosts conocidos y activar SROS2 antes de que un robot salga del laboratorio.

Algunas empresas construyen sobre ROS 2 y añaden sus propias pilas por encima, como los paquetes Isaac ROS de NVIDIA para percepción acelerada por GPU. Otras mantienen una pila de software propietaria y solo exponen una interfaz hacia fuera. Las dos vías son habituales, y la segunda cobra importancia cuando el robot tiene que trabajar con todo lo demás que hay en unas instalaciones.

¿Cómo conectar un sistema operativo robótico con dispositivos IoT?

ROS se diseñó para el interior de un robot, o para una flota dentro de una misma red. Un edificio o una planta industrial tienen un segundo conjunto de dispositivos que el robot no puede percibir: un contacto de puerta en el otro extremo del almacén, un sensor de fugas en una sala de máquinas, el estado de una puerta cortafuegos, una medición de calidad del aire en una sala del hospital. Lo normal es que hablen LoRaWAN, MQTT, Modbus o BACnet, no topics de ROS.

Hay puentes bien conocidos. rosbridge expone los topics de ROS como JSON sobre WebSockets, varios paquetes de la comunidad retransmiten los topics elegidos hacia y desde brokers MQTT, y Open-RMF, el Open Robotics Middleware Framework, coordina varias flotas de robots con infraestructura compartida, como puertas y ascensores. Todo esto resuelve el transporte. Decidir qué evento de qué sensor debe enviar a qué robot y adónde, y probar esa lógica antes de que funcione en unas instalaciones reales, es una tarea aparte.

Conviene decidir pronto qué cruza esa frontera. Los topics en bruto, como los barridos láser o los fotogramas de cámara, generan demasiado tráfico y demasiado detalle para los sistemas de las instalaciones. Lo que necesita el resto de las instalaciones es un conjunto pequeño y estable de datos y peticiones: la posición del robot en el mapa de las instalaciones, su nivel de batería, el estado de su misión actual y unas pocas tareas que acepta, como ir a un lugar con nombre, volver a la base o ponerse en pausa. Si esa interfaz se mantiene pequeña, el equipo del robot puede cambiar todo lo que hay dentro de ROS sin romper la lógica de las instalaciones.

Esa capa de decisión es lo que un sistema operativo para la IA física añade por encima de ROS, y Kilo está pensado precisamente para ser esa capa. Si la integración del robot expone unas pocas órdenes por MQTT, por ejemplo «ir al punto de ruta» o «volver a la base», pueden guardarse en Kilo y hacer que una regla envíe una de ellas cuando un sensor de otra zona de las instalaciones informe de un evento, mientras ROS sigue encargándose de la navegación a bordo. Cada orden enviada de esta forma aparece en su historial como Pendiente, Entregado, Confirmado, Advertencia leve o Fallido.

Como esas órdenes mueven una máquina real, la regla se ensaya antes: se recorre paso a paso en el depurador de Kilo con la respuesta del robot simulada, para ver cómo se desarrolla cada camino antes de desplegar nada.

Preguntas frecuentes sobre ROS (Robot Operating System)

¿Es gratis usar ROS como sistema operativo robótico?

Sí. ROS es de código abierto y usa licencias permisivas que admiten el uso comercial sin pagar por ellas. Los costes que quedan son el tiempo de ingeniería, el hardware y cualquier contrato de soporte comercial que una empresa decida contratar con alguna de las firmas que ofrecen consultoría sobre ROS.

¿Qué lenguaje de programación usa un sistema operativo robótico como ROS?

Las dos bibliotecas cliente oficiales son C++ (rclcpp) y Python (rclpy), y es habitual que un mismo robot combine ambas. Hay bibliotecas de la comunidad para Rust, Java y otros lenguajes, y los tipos de mensaje se definen en sencillos archivos de interfaz a partir de los cuales se genera código para cada lenguaje.

¿Se puede usar un sistema operativo robótico como ROS en Windows?

ROS 2 incluye Windows entre sus plataformas compatibles, junto a Ubuntu Linux, y cada versión publica sus niveles exactos de compatibilidad en un documento llamado REP 2000. La mayoría de los tutoriales, drivers y robots en producción siguen usando Ubuntu, así que Linux sigue siendo el camino más sencillo.

¿ROS 2 es un sistema operativo robótico en tiempo real?

Por sí solo, no. ROS 2 se diseñó para poder utilizarse en sistemas de tiempo real, pero para ello también hace falta un kernel de tiempo real, como Linux con el parche PREEMPT_RT, una configuración cuidadosa de la memoria y los hilos, y un hardware que cumpla sus tiempos. El framework ros2_control es la forma habitual de ejecutar bucles de control ajustados para brazos y ruedas dentro de ROS 2.

Un robot con ROS 2 que ya esté en funcionamiento es una forma acotada de asomarse por primera vez a la parte de las instalaciones. Con uno de los puentes de la comunidad se publican en MQTT tres de sus topics, como el nivel de batería, el estado de la misión y la posición; después se registra el robot como un único dispositivo en Kilo y se representan los tres valores en un panel. Luego basta con añadir una regla que avise cuando la batería baje del 20 % con una misión todavía en curso. Es un solo dispositivo y una sola regla, muy dentro del plan gratuito, y en el robot no cambia nada salvo el puente.