La robótica moderna es tanto software como hierro. Por fuera vemos brazos, ruedas, cámaras, sensores, y a veces carcasas pulidas que dan pie a bonitas imágenes de robótica en notas de prensa. Por dentro late un sistema operativo de robots que coordina todo sin descanso. ROS, el Robot Operating System, nació para resolver justo eso: la “pegajosa” integración entre algoritmos, drivers y hardware heterogéneo. Hoy, en entornos académicos y en automatización y robótica industrial, ROS es una columna vertebral de proyectos que escalan, colaboran y evolucionan con rapidez.
He visto equipos perder meses por no planear bien los mensajes entre nodos, o por subestimar la latencia de una cámara USB barata. También he visto startups acelerar prototipos desde un carrito con LIDAR y un portátil con Ubuntu hasta un robot que navega almacenes con seguridad, usando bibliotecas maduras y un ecosistema vibrante. Este texto condensa experiencia práctica con ROS 1 y ROS 2, y apunta a mejores prácticas que reducen fricción, evitan sorpresas en campo y sostienen un ciclo de vida largo.
Qué es ROS, y qué no es
ROS no es un kernel ni reemplaza Linux. Es una capa de software que facilita que pequeños procesos, llamados nodos, hablen entre sí mediante temas (topics), servicios y acciones. Aporta mecanismos de descubrimiento, tipos de mensajes, herramientas de depuración, visualización y simulación. También ofrece paquetes listos para tareas comunes: navegación, SLAM, planificación de movimiento, percepción 3D, control de brazos, entre otras.
Tampoco es una receta obligatoria. Es un conjunto de convenciones, bibliotecas y herramientas. Puedes usar una parte, reemplazar otra, o integrarlo con sistemas propietarios en robots comerciales. En automatización y robótica industrial, muchos fabricantes combinan controladores PLC con ROS para la capa de percepción y planeación, manteniendo la capa dura de seguridad en hardware certificado.
ROS 1 surgió con un modelo centralizado (ROS master) y una fuerte dependencia de TCPROS y UDP. ROS 2, reescrito sobre DDS, ofrece comunicación más robusta, QoS configurables, seguridad, y soporte real para sistemas distribuidos y multinodo en redes no confiables. Si empiezas hoy, la recomendación general es ROS 2, salvo que debas mantener integraciones con ecosistemas ROS 1 muy específicos. Hay puentes entre ambos, pero conviene minimizar esa superficie.
Por qué ROS ganó tracción
Porque encapsula dolor. Un LIDAR de marca A, una cámara de marca B, un IMU de marca C y un motor de marca D no hablan el mismo idioma. ROS se encarga de que compartan datos en tiempo casi real, con tipos de mensajes estandarizados. Además, la comunidad provee paquetes probados: no necesitas escribir tu propio filtro de partículas para localización si AMCL ya existe y tiene miles de horas de vuelo.
Sumemos visualización con RViz, introspección de datos con rqt y registro con rosbag/ros2 bag. Estas herramientas reducen la incertidumbre. Cuando tu robot se desvía en una esquina oscura, puedes revisar un bag, medir latencias, ver la nube de puntos y entender si falló la calibración, el mapeo o el controlador. Esa capacidad de mirar “por dentro” diferencia a los equipos que corrigen rápido de los que apagan incendios sin fin.
Ecosistema en capas: sensores, percepción, decisión y acción
Me gusta dividir un sistema ROS en cuatro capas prácticas.
La capa de sensores es el origen. Drivers para LIDAR, depth cameras, GPS, IMUs, encoders y sensores de fuerza publican datos crudos. Aquí, la calidad del timestamp es crucial. Sin sellos de tiempo consistentes, una fusión sensorial perderá precisión. Evita mezclar relojes sin sincronización. Chrony con PTP puede darte microsegundos de precisión en redes cableadas, lo que mejora alineación entre imagen y odometría.
La capa de percepción convierte datos en conocimiento: detección de obstáculos, segmentación de planos, estimación de pose, mapas de ocupación. Paquetes como PCL, OpenCV, image pipeline y nav2costmap_2d son pilares. En visión, la calibración intrínseca y extrínseca vale oro. Si una cámara RGB y un LIDAR no están registrados con cuidado, tu planificador esquivará fantasmas o ignorará paredes.
La capa de decisión engloba localización, mapeo y planificación. En navegación móvil, Nav2 en ROS 2 combina un planificador global, uno local, recuperación ante fallos y plugins de costo. En brazos, MoveIt 2 ofrece cinemática inversa, verificación de colisiones y planificación con OMPL. El truco está en ajustar parámetros a tu dinámica real, no solo a simulación. Los defaults funcionan en demos, pero un AMR con 200 kg de carga y ruedas gastadas necesita ganancias, límites y radios de inflación realistas.
La capa de acción conecta la decisión con actuadores: control de motores, grippers, control de fuerza, PLCs. Aquí se cruza el mundo ROS con buses industriales como CAN, EtherCAT o Modbus. He visto mejoras radicales al migrar control de bajo nivel hacia microcontroladores dedicados con bucles a 1 kHz, y dejar ROS para la lógica de alto nivel. ROS 2 permite QoS confiables, pero no busques tiempos duros de control de milisegundos en un Linux genérico sin RT.
ROS 2 en la práctica: nodos, QoS y composición
ROS 2 utiliza DDS, que ofrece perfiles de calidad de servicio. Esto importa más de lo que parece. Sensores de alta frecuencia pueden saturar la red o la CPU si usas QoS “reliable” sin necesidad. Para streams de cámara donde alguna pérdida es tolerable, “best effort” con una cola pequeña reduce latencia. Para odometría, reliable suele ser mejor. La compatibilidad de QoS entre publicador y suscriptor es clave. Una mala combinación genera suscriptores silenciosos, sin errores visibles.
La composición de nodos dentro de un mismo proceso reduce overhead. Si tu pipeline de visión tarda, digamos, 60 ms por frame, evita copias innecesarias. Componer los nodos de captura, rectificación y detección en un contenedor de componentes puede recortar varios milisegundos. En ROS 2, rclcpp_components facilita esto.
La seguridad llegó a ROS 2 con SROS2, que añade autenticación y cifrado de tráfico. En entornos industriales y en robots conectados a redes corporativas, activar SROS2 deja de ser opcional. No quieres que un escaneo de puertos reconfigure tu robot. La curva de adopción existe, pero es manejable con plantillas de políticas y certificados.
Simulación: Gazebo, Isaac Sim y pruebas con intención
La simulación no sustituye pruebas en campo, pero ahorra tiempo y evita golpes caros. Gazebo y su sucesor, Gazebo Harmonic, brindan física, sensores virtuales y plugins ROS. Si trabajas con visión y aprendizaje, Isaac Sim ofrece pipelines realistas, materiales PBR y generación sintética con anotaciones. Elige según tu stack. Para navegación 2D sencilla en interiores, Gazebo con mapas de ocupación cumple. Si haces manipulación con objetos brillantes y variación de iluminación, la simulación basada en ray tracing ayuda a evitar sorpresas.
El secreto está en diseñar escenarios que expondrán tus fallos: pasillos estrechos, superficies reflectantes, rampas, palets mal colocados, luces parpadeantes. Guarda resultados, registra bags, crea regresiones. Un equipo con disciplina de simulación detecta regresiones después de cada cambio de parámetro, no después de chocar con una estantería.
Estándares de mensajes y calibración: la mitad invisible del éxito
Un sistema ROS robusto comienza con un buen contrato de datos. Define mensajes claros y versiones. Si cambias el frame_id, documenta. Si introduces un nuevo campo en un mensaje custom, considera semántica hacia atrás. Evita proliferación de mensajes ad hoc sin razón.
La calibración es una inversión que paga sola. Intrínsecos de cámara, extrínsecos cámara - LIDAR, y sobre todo el árbol TF del robot. Un TF mal definido causa errores sutiles: la nube de puntos parece bien, pero el planificador cree que el sensor está 5 cm a la izquierda. En manipulación, 2 mm de desfase entre la base del brazo y su modelo URDF se traducen en fallos del 20 por ciento en inserciones ajustadas. https://robotica10.com/ Dedica una jornada a ajustar el URDF y validar con mediciones físicas. Vale la pena.
ROS y robotica educativa: aprender con propósito
Para quien se pregunta qué es la robótica en un contexto de aprendizaje, ROS es una escuela entera. La robotica educativa no necesita hardware caro. Un TurtleBot en un laboratorio, o incluso simuladores en un portátil modesto, enseñan computación y robótica con problemas reales: sincronización, frames, control, PID, SLAM. Estudiantes que arman un pipeline de navegación, desde la cámara hasta la orden de velocidad, entienden mejor la relación entre sensores y acción que con una clase solo teórica.
Me gusta proponer mini proyectos de dos semanas: seguir una línea con cámara monocromática, navegar un laberinto simple con LIDAR barato, o hacer pick-and-place de cubos de colores con un brazo pequeño. Se documenta cada decisión: por qué “best effort” en la cámara, por qué subimos el inflation radius cuando el robot toca muebles, por qué limitamos la velocidad angular. La comprensión práctica se queda.
Automatización y robótica industrial: integrar con PLCs y seguridad
En plantas, ROS convive con PLCs, redes deterministas y celdas con resguardos. El reto no es técnico solamente, es organizacional. Los responsables de seguridad confían en estándares y certificaciones. El camino sensato separa funciones: ROS maneja percepción, planeación y HMI avanzada, mientras el paro de emergencia, enclavamientos y control de motores críticos recae en hardware certificado y PLCs.
La integración con OPC UA y MQTT permite que ROS se comunique con sistemas SCADA. He visto líneas donde un AGV con ROS 2 recibe pedidos por MQTT, usa Nav2 para navegar, y confirma estados a un MES. Los datos de sensores se agregan en un broker perimetral con políticas claras. Nada de llevar tráfico bruto de cámara a la red corporativa sin control.
Un detalle operativo: evita sorpresas de latencia por WiFi saturado. Si la misión depende de comunicación continua, usa red cableada o WiFi industrial con QoS prioritario. Si el robot debe ser autónomo con pérdidas, diseña para desconexiones: buffer local de órdenes, objetivos persistentes y reintentos con backoff.
Mejores prácticas de desarrollo: repos, CI y bags con etiqueta
Equipo que cuida su repositorio entrega robots que vuelven al muelle. Mantén workspaces limpios: paquetes con propósito, dependencias declaradas, y nodos con responsabilidades nítidas. No todo tiene que ser un nodo. A veces una librería compartida reduce duplicación y bugfixes dispersos.
La integración continua en ROS 2 con colcon y GitHub Actions o GitLab CI evita roturas. Compila en matrix de versiones, ejecuta pruebas unitarias y algunas pruebas de integración con simulación headless. Subir un bag pequeño con fixtures sintéticos acelera depuración. Etiqueta bags reales con fecha, commit, lugar y versión de firmware. No hay nada peor que un bag excelente sin contexto.
Para parámetros, YAML bien comentado, versionado y con valores por entorno: sim, staging, prod. Evita hardcodear rutas. Usa lifecycle nodes para controlar estados y reinicios limpios después de cambios de configuración.
Rendimiento en el borde: CPU, GPU y el precio de cada milisegundo
La computación y robótica se encuentran en la orilla del hardware. En visión 3D y detección con redes neuronales, la GPU manda. En un Jetson Orin puedes correr detección, segmentación y seguimiento a 30 FPS, pero solo si cuidas copias entre CPU y GPU. Zero-copy, codificadores NVMM, y pipelines GStreamer bien armados marcan la diferencia. Si la cámara ofrece H.264, decide si decodificar en GPU o capturar sin comprimir según latencia y ancho de banda.
El CPU aún importa. La fusión de sensores y la planificación local suelen ir en CPU. Si ves picos de uso que rompen el loop, usa perfiles con perf, ros2_tracing o eBPF. Microoptimizaciones como reservar memoria en vectores que crecen por frame evitan jitter. Y, aunque suene aburrido, compilar en Release con -O3 hace magia.
El sistema operativo también juega. Un kernel con PREEMPT_RT mejora predictibilidad, pero no resolverá un diseño de software con bloqueos. Evita colas gigantes y cálculos que dependen de datos que pueden llegar tarde. Implementa timeouts y watchdogs. Prefiere estructuras lock-free cuando sea sensato, y mide.
Navegación que no engaña a nadie
La navegación de robots móviles seduce en demo y traiciona en campo. Un mapa perfecto en sim no incluye personas, charcos ni brillos. En interiores con suelos reflectantes, muchos LIDARs devuelven echos extraños. En almacenes con estanterías metálicas, las lecturas vienen y van según el ángulo. Nav2 ofrece plugins para fusionar sensores y capas de costo específicas. Úsalos con criterio. Si tus obstáculos dinámicos son frecuentes, considera sensores redundantes: un LIDAR a 30 cm y otro en el bumper detectan lo que uno solo deja pasar.
Los límites de velocidad importa afinarlos en base a frenado real con carga máxima. Un AMR de 100 kg que va a 1,5 m/s necesita metros de margen. Ajusta lookahead del controlador local al espacio y al ruido en odometría. Y no descartes marcadores de suelo o códigos AR en zonas críticas. En entornos mixtos con personas, una dosis de infraestructura barata redunda en seguridad.
Manipulación con MoveIt 2: el detalle hace la diferencia
Mover un brazo en RViz es bonito. Atornillar en producción, otra cosa. La planificación de trayectorias debe considerar la flexibilidad del efector, cables, herramientas y límites térmicos. MoveIt 2 es potente si le das un modelo URDF fiel y una escena de colisión actualizada. La percepción de la escena con cámaras montadas en muñeca, combinada con filtros de profundidad, evita choques bajos.
La precisión llega con control de fuerza y detección de contacto. Muchas aplicaciones se benefician de una transición desde control de posición a un modo de impedancia en el último centímetro. No confíes solo en la cámara para inserciones ajustadas. Un sensor de fuerza barato bien filtrado reduce scrap y desgaste. Si el ciclo pide 10 segundos, gasta uno en acercamiento cuidadoso y te ahorrarás horas de paro.
Datos, telemetría y mantenimiento predictivo
Los robots generan telemetría que sirve para algo más que gráficos bonitos. Temperaturas de motores, consumo, ciclos de frenado, errores de localización, rotación de ruedas. En ROS, es fácil publicar estos datos. Lo difícil es decidir qué guardar y por cuánto tiempo. Una regla pragmática: alta resolución local por horas, agregados por días, y resúmenes por meses. Al detectar tendencias, actúa. Una rueda que vibra 15 por ciento más que la semana pasada anuncia un rodamiento que pide cambio.
Evita cargar la red con bags gigantes en tiempo real. Extrae métricas y eventos, y sube bags completos solo cuando hay incidentes. Da visibilidad a operaciones con paneles simples: porcentaje de misiones completadas, desvío medio de rutas, top 3 de fallos, tiempo medio entre fallos. Si la gente de piso entiende el panel, te avisará antes de que la cosa escale.
Seguridad funcional y ciberseguridad: dos caras igual de serias
La seguridad funcional protege a las personas, la ciberseguridad protege al sistema. Ambas son imprescindibles. Define zonas de velocidad y paros de emergencia cableados, con sensores de presencia que no dependen de ROS. A la par, segmenta la red del robot, usa SROS2 para cifrado y autenticación, y aplica políticas de firewall. Las credenciales por defecto en un robot son una invitación al desastre.
Cuando interactúas con PLCs, documenta estados y transiciones. Qué sucede si ROS deja de enviar heartbeats, si el LIDAR pasa a fault, si una cámara se desconecta. Diseña circuitos de degradación. El robot puede detenerse, retroceder, o esperar asistencia. Lo que no puede es quedar en un limbo.
Formación de equipo: roles y ritmos que funcionan
Los mejores proyectos de computación y robótica combinan perfiles. Una persona fuerte en percepción, otra en control, otra en DevOps/infra, y otra que hable con operaciones. Las reuniones de revisión con bags reproducibles, no con relatos, cambian la cultura. Un ritmo saludable incluye demos cada dos semanas con metas incisivas: hoy pasamos la puerta de 80 cm sin tocar. Si no lo logramos, mostramos por qué, con datos.
La documentación vive en el repo. Diagrama TF, diagrama de nodos, parámetros críticos. Un README que permite a alguien nuevo correr la sim y reproducir un escenario es oro puro. Y una práctica sencilla: un “operational handbook” de una página para los usuarios que no programan, con pasos de arranque, parada, y señales de alerta.
Una mirada a largo plazo: sostenibilidad y evolución
El robot que entregas este año deberá actualizarse el próximo. Elige dependencias con comunidad activa. Sigue las LTS de ROS 2 cuando sean válidas para tu caso. Mantén una rama estable y otra de desarrollo. Automatiza migraciones de parámetros y mensajes cuando cambies de versión. Prueba el plan de actualización en un robot de staging, no en el que hace picking en la noche.
También piensa en energía. Un algoritmo que consume 90 por ciento de GPU para ganar 2 por ciento en precisión quizá no vale el calor extra y la batería que drena. El rendimiento sostenido en verano y con polvo es distinto al del laboratorio. Diseña ventilación, monitorea temperaturas, y considera modos de ahorro cuando el robot está inactivo.
Dónde encajan las preguntas básicas: qué es robótica, computación y robotica, y su valor
Para quien llega desde cero y pregunta qué es la robótica o qué es robótica, una respuesta honesta: es la unión entre percepción, decisión y acción, encarnada en máquinas que interactúan con el mundo físico. La computación y robótica se cruzan donde los algoritmos influyen en un motor que empuja, gira o aprieta. No es solo código, no es solo metal. Es una conversación continua entre sensores que dicen cómo está el mundo y actuadores que lo cambian.
La robotica educativa expone esa conversación a estudiantes, desde un carrito con una cámara hasta un brazo que apila bloques. Las imágenes de robótica que vemos en divulgación son la punta del iceberg. Debajo, hay calibración, latencia, trazas, tablas de parámetros y mucha paciencia. Entender esa capa invisible transforma curiosidad en oficio.
Un itinerario práctico para empezar con ROS 2
- Instalar una versión LTS de ROS 2 con paquetes base, crear un workspace limpio y compilar con colcon. Probar talker y listener, luego un sensor virtual en sim. Elegir un caso mínimo: navegación 2D en un entorno sencillo o mover un brazo de 4 DOF. Definir métricas específicas, como tiempo de misión y tasa de colisión cero. Armar simulación útil, no perfecta: un mapa simple, un obstáculo móvil y luces difíciles. Registrar bags y establecer una prueba de regresión que todos puedan ejecutar. Conectar un sensor real y verificar timestamps, TF y latencias. Ajustar QoS y parámetros hasta igualar o acercar desempeño a la simulación. Documentar el pipeline, fijar versiones, activar CI y planificar una prueba en campo con salvaguardas. Recoger métricas y repetir.
Cierres que abren puertas
ROS no se trata de magia. Es una manera ordenada de construir sistemas complejos con piezas que hablan un lenguaje común. En proyectos industriales, reduce el tiempo de integración y te deja concentrarte en el valor real: flujos, seguridad, ergonomía, eficiencia. En educación, convierte conceptos difusos en decisiones concretas que puedes medir y mejorar. Y en investigación, te permite explorar ideas sin reinventar lo esencial.
Practicar buenas normas, desde QoS hasta calibración, desde CI hasta trazabilidad, cambia el destino de un proyecto. La próxima vez que veas un robot moverse con soltura en un pasillo estrecho, piensa en todo lo que sostiene ese gesto. Si está hecho con mimo, probablemente detrás haya un grafo de nodos bien diseñado, parámetros comentados, bolsas de datos con nombre y un equipo que corrige rápido porque puede mirar por dentro. Esa es la promesa del ecosistema ROS cuando se usa con oficio.