Tiempo real no significa solo rapidez
En el control de un robot, decir que una tarea es de tiempo real no significa simplemente que se ejecute deprisa. Significa que su resultado debe estar disponible dentro de un plazo relevante para la aplicación. Si una tarea de control tiene que leer sensores, calcular una respuesta y actualizar actuadores antes de cierto límite, importa tanto el tiempo de ejecución como la variabilidad de ese tiempo y la posibilidad de incumplir el plazo. Un promedio bajo no basta para demostrar que el comportamiento será predecible.
La distinción es importante porque una tarea puede ser rápida en la mayoría de las ejecuciones y, aun así, tardar demasiado en otras. El promedio describe el comportamiento medio, pero no indica por sí solo qué ocurre en los casos más lentos ni con qué frecuencia se producen. Para valorar el requisito temporal hay que observar la respuesta en relación con el plazo que debe respetar, no limitarse a comparar velocidades medias.
La exigencia concreta cambia según la función. Una interfaz de supervisión puede tolerar demoras que serían inaceptables en un lazo de control. También puede haber distintos plazos para adquisición de datos, procesamiento y comunicación con actuadores. Por eso, antes de elegir una arquitectura, conviene definir qué tarea debe responder, cuál es su plazo, con qué frecuencia se repite y qué consecuencia tendría llegar tarde. Sin esos requisitos, «tiempo real» corre el riesgo de convertirse en una etiqueta imprecisa, no en un criterio verificable. Definirlos por separado evita tratar como equivalentes etapas con funciones y necesidades temporales distintas.
Qué aporta ROS 2 a la ejecución
La documentación de ROS 2 aborda la programación en tiempo real como una cuestión con requisitos y dificultades de implementación, no como una propiedad que se obtenga automáticamente por utilizar el framework. Por eso conviene separar las herramientas que ofrece ROS 2 de la demostración de que una aplicación concreta cumple sus plazos. La documentación técnica puede orientar la configuración y el análisis, pero no sustituye la definición de los requisitos del robot ni las pruebas de la implementación elegida.
En particular, no se debe interpretar la presencia de mecanismos de configuración como garantía de que el resultado llegará dentro de un plazo extremo a extremo. Una ruta de datos puede incluir comunicación, planificación, procesamiento y respuesta a actuadores; el tiempo observado depende de la ruta evaluada y de las condiciones en las que se ejecuta. La lectura correcta es condicional: cada mecanismo debe valorarse dentro de una configuración concreta y junto con el resto de la aplicación.
Por tanto, al evaluar una configuración conviene describir qué componentes participan en el recorrido relevante y qué límite temporal se está comprobando. Esa descripción ayuda a interpretar las mediciones y a evitar atribuir el resultado a una sola opción de configuración. La documentación consultada trata la programación en tiempo real como un asunto de implementación; no establece una garantía global aplicable a cualquier robot.
Ejecutores, callbacks y planificación
Los ejecutores forman parte de la arquitectura de ejecución de ROS 2. La investigación académica sobre programación de cadenas de procesamiento en un ejecutor multihilo de ROS 2 analiza la planificación y el tiempo de respuesta como cuestiones que deben estudiarse en el contexto de la cadena, no solo midiendo la velocidad de un nodo aislado. Esto respalda la necesidad de evaluar la organización del trabajo y las dependencias entre tareas para la configuración concreta que se pretende utilizar.
En términos prácticos, evaluar un ejecutor implica mirar cómo se organiza el trabajo y no únicamente cuánto tarda una función cuando se ejecuta sin otras tareas. La atención de callbacks forma parte de la ruta que lleva de una entrada a una respuesta, así que las decisiones de distribución y ejecución deben considerarse junto con el resto de esa ruta. El número de hilos, por sí solo, tampoco describe toda la planificación: importa cómo se relaciona con las tareas que la aplicación realmente ejecuta.
En una cadena, el análisis puede abarcar las distintas etapas que participan en el procesamiento y las relaciones entre ellas. La estructura del ejecutor y las dependencias entre tareas forman parte del sistema evaluado. Un resultado de análisis o experimento asociado a una versión y configuración no debe trasladarse automáticamente a otras versiones, cargas o plataformas. La investigación citada aborda una configuración multihilo concreta; no equivale a una garantía para todos los sistemas ROS 2.
Lo que queda fuera del framework
ROS 2 no elimina la influencia del sistema operativo ni de la plataforma donde se ejecuta. La documentación del proyecto sobre programación en tiempo real presenta el tema como un conjunto de requisitos y dificultades de implementación, no como una propiedad que se active por usar ROS 2. Para un ejemplo específico, la documentación del controlador ROS 2 de Universal Robots recomienda un sistema Ubuntu con capacidades de tiempo real para su controlador y señala que un kernel de baja latencia puede ser suficiente en muchas situaciones descritas en esa guía. Esa recomendación pertenece a ese controlador y no debe generalizarse a todos los robots o aplicaciones.
Esto significa que dos implementaciones que emplean ROS 2 no tienen por qué exhibir el mismo comportamiento temporal si difieren en la plataforma o en la carga que ejecutan. La observación debe vincularse a las condiciones bajo las que se obtuvo: los componentes del sistema y la configuración importan para interpretar el resultado. Sin esa información, una cifra aislada no permite saber si representa la situación que tendrá que afrontar la aplicación.
Tampoco basta con verificar que los mensajes llegan o que una demostración funciona en condiciones controladas. Una prueba debe representar la carga y la secuencia de trabajo de la aplicación, registrar tiempos relevantes y prestar atención a los casos lentos, no solo a los promedios. Conviene medir de extremo a extremo desde el evento que inicia el trabajo hasta la respuesta que importa al robot. Si el requisito es de seguridad o de misión crítica, la evidencia de rendimiento debe formar parte de una evaluación más amplia de la arquitectura y del riesgo; una prueba de rendimiento aislada no equivale a una certificación.
Una comprobación útil antes de adoptar ROS 2
Empiece por documentar cada plazo: qué evento lo inicia, qué respuesta lo satisface, con qué frecuencia se repite y qué margen existe. Dibuje después la cadena de procesamiento que conecta sensores, nodos y actuadores. Para cada tramo, anote los componentes que intervienen, el trabajo que ejecutan y las dependencias con otras tareas. Esta descripción convierte una expectativa general en preguntas comprobables y ayuda a localizar si el retraso procede de la comunicación, de la planificación o del trabajo de la aplicación.
También conviene que la descripción de cada plazo distinga claramente el inicio del trabajo de la respuesta que se considera válida. Esa precisión permite comparar lo medido con el requisito correspondiente, en lugar de medir una etapa diferente por comodidad. Si hay varias etapas, conservar su relación dentro de la cadena facilita interpretar dónde se acumula el tiempo y evita confundir el rendimiento local de un componente con la respuesta completa que necesita el robot.
A continuación, fije la versión de ROS 2, el middleware, el sistema operativo, el hardware y la configuración que se va a evaluar. Pruebe la carga esperada y condiciones desfavorables plausibles, mida las etapas y la respuesta completa, y conserve la configuración junto con los resultados. Repita las pruebas después de cambios importantes y contraste cualquier conclusión con la documentación aplicable a esa versión. El objetivo no es demostrar que ROS 2 sea «en tiempo real» en abstracto, sino determinar si una implementación definida cumple los requisitos definidos bajo condiciones descritas. Las fuentes consultadas respaldan capacidades de configuración y análisis, pero no establecen una garantía universal de cumplimiento para cualquier robot.