Le temps réel ne signifie pas simplement rapidité
Dans la commande d’un robot, qualifier une tâche de temps réel ne signifie pas simplement qu’elle s’exécute rapidement. Cela signifie que son résultat doit être disponible dans un délai pertinent pour l’application. Si une tâche de commande doit lire les capteurs, calculer une réponse et mettre à jour les actionneurs avant une limite donnée, le temps d’exécution et sa variabilité comptent tous deux, tout comme le risque de dépasser l’échéance. Une moyenne faible ne suffit pas à démontrer un comportement prévisible.
Cette distinction est importante, car une tâche peut s’exécuter rapidement dans la plupart des cas et prendre malgré tout trop de temps dans d’autres. Une moyenne décrit le comportement habituel, mais ne montre pas à elle seule ce qui se passe dans les cas les plus lents ni leur fréquence. Pour évaluer l’exigence temporelle, il faut observer la réponse par rapport à l’échéance à respecter, et non se contenter de comparer des vitesses moyennes. La question est de savoir si la tâche se termine à temps dans les conditions évaluées, pas si elle est généralement rapide.
L’exigence précise varie selon la fonction. Une interface de supervision peut tolérer des retards inacceptables dans une boucle de commande. L’acquisition de données, leur traitement et la communication avec les actionneurs peuvent également avoir des échéances différentes. Avant de choisir une architecture, il convient donc de définir la tâche qui doit répondre, son délai, sa fréquence de répétition et les conséquences d’une réponse tardive. Sans ces exigences, le « temps réel » risque de devenir une étiquette imprécise plutôt qu’un critère vérifiable. Les définir séparément évite aussi d’assimiler des étapes aux fonctions et aux besoins temporels distincts.
Ce que ROS 2 apporte à l’exécution
La documentation de ROS 2 aborde la programmation en temps réel comme une question qui comporte des exigences et des difficultés de mise en œuvre, et non comme une propriété obtenue automatiquement par l’utilisation du framework. Il est donc utile de distinguer les outils proposés par ROS 2 de la preuve qu’une application donnée respecte ses échéances. La documentation technique peut guider la configuration et l’analyse, mais elle ne remplace ni la définition des exigences du robot ni les tests de l’implémentation retenue.
En particulier, la présence de mécanismes de configuration ne doit pas être interprétée comme une garantie qu’un résultat arrivera dans les délais de bout en bout. Un parcours de données peut comprendre la communication, l’ordonnancement, le traitement et une réponse des actionneurs ; le temps observé dépend du parcours évalué et des conditions d’exécution. L’interprétation correcte est conditionnelle : chaque mécanisme doit être évalué dans une configuration précise et en tenant compte du reste de l’application.
Lorsqu’on évalue une configuration, il convient de décrire les composants qui participent au parcours concerné et la limite temporelle vérifiée. Cette description aide à interpréter les mesures et évite d’attribuer le résultat à une seule option de configuration. La documentation consultée traite la programmation en temps réel comme un sujet de mise en œuvre ; elle n’établit pas de garantie générale applicable à tous les robots. Une évaluation utile précise donc le périmètre de chaque mesure et de chaque conclusion.
Exécuteurs, callbacks et ordonnancement
Les exécuteurs font partie de l’architecture d’exécution de ROS 2. Des travaux de recherche sur l’ordonnancement de chaînes de traitement dans un exécuteur ROS 2 multithread étudient l’ordonnancement et les temps de réponse dans le contexte de la chaîne, et non en mesurant uniquement la vitesse d’un nœud isolé. Cela confirme la nécessité d’évaluer l’organisation du travail et les dépendances entre tâches pour la configuration que l’on envisage d’utiliser.
En pratique, évaluer un exécuteur consiste à examiner l’organisation du travail, et pas seulement le temps nécessaire à une fonction lorsqu’elle s’exécute sans autres tâches. Le traitement des callbacks fait partie du parcours qui mène d’une entrée à une réponse ; les choix de répartition et d’exécution doivent donc être considérés avec le reste de ce parcours. Le seul nombre de threads ne décrit pas l’ensemble de l’ordonnancement : il faut aussi examiner son rapport avec les tâches réellement exécutées par l’application.
Pour une chaîne de traitement, l’analyse peut porter sur les différentes étapes et sur leurs relations. La structure de l’exécuteur et les dépendances entre tâches font partie du système évalué. Le résultat d’une analyse ou d’une expérience associée à une version et à une configuration ne doit pas être transposé automatiquement à d’autres versions, charges ou plateformes. La recherche citée porte sur une configuration multithread précise ; elle ne constitue pas une garantie pour tous les systèmes ROS 2.
Ce qui ne relève pas du framework
ROS 2 ne supprime pas l’influence du système d’exploitation ni de la plateforme d’exécution. La documentation du projet sur la programmation en temps réel présente le sujet comme un ensemble d’exigences et de difficultés de mise en œuvre, et non comme une propriété activée par le simple fait d’utiliser ROS 2. À titre d’exemple précis, la documentation du pilote ROS 2 d’Universal Robots recommande un système Ubuntu doté de capacités temps réel pour son pilote et indique qu’un noyau à faible latence peut suffire dans de nombreuses situations décrites dans ce guide. Cette recommandation concerne ce pilote et ne doit pas être généralisée à tous les robots ou toutes les applications.
Deux implémentations utilisant ROS 2 ne présenteront donc pas nécessairement le même comportement temporel si la plateforme ou la charge diffère. Les observations doivent être rattachées aux conditions dans lesquelles elles ont été obtenues : les composants et la configuration du système comptent pour interpréter un résultat. Sans ces informations, une valeur isolée ne permet pas de savoir si elle représente les conditions auxquelles l’application sera confrontée.
Il ne suffit pas non plus de vérifier que les messages arrivent ou qu’une démonstration fonctionne dans des conditions contrôlées. Un test doit représenter la charge et la séquence de travail de l’application, enregistrer les temps pertinents et prendre en compte les cas les plus lents, pas seulement les moyennes. Il convient de mesurer de bout en bout, depuis l’événement qui déclenche le travail jusqu’à la réponse importante pour le robot. Si l’exigence concerne la sécurité ou une mission critique, les éléments de performance doivent s’inscrire dans une évaluation plus large de l’architecture et des risques ; un test de performance isolé n’équivaut pas à une certification.
Une vérification utile avant d’adopter ROS 2
Commencez par documenter chaque échéance : l’événement qui la déclenche, la réponse qui la satisfait, sa fréquence de répétition et la marge disponible. Représentez ensuite la chaîne de traitement reliant capteurs, nœuds et actionneurs. Pour chaque segment, notez les composants concernés, le travail effectué et les dépendances vis-à-vis des autres tâches. Cette description transforme une attente générale en questions vérifiables et aide à déterminer si un retard vient de la communication, de l’ordonnancement ou du travail de l’application.
La description de chaque échéance doit également distinguer clairement le début du travail de la réponse considérée comme valide. Cette précision permet de comparer les mesures à l’exigence correspondante au lieu de mesurer, par commodité, une autre étape. S’il y a plusieurs étapes, préserver leur relation au sein de la chaîne facilite l’interprétation des accumulations de temps et évite de confondre les performances locales d’un composant avec la réponse complète attendue par le robot.
Définissez ensuite la version de ROS 2, le middleware, le système d’exploitation, le matériel et la configuration à évaluer. Testez la charge attendue et des conditions défavorables plausibles, mesurez les étapes ainsi que la réponse complète, et conservez la configuration avec les résultats. Répétez les tests après des changements importants et confrontez les conclusions à la documentation applicable à cette version. L’objectif n’est pas de prouver que ROS 2 est « temps réel » dans l’absolu, mais de déterminer si une implémentation définie respecte des exigences définies dans des conditions documentées. Les sources consultées étayent des capacités de configuration et d’analyse, mais n’établissent aucune garantie universelle de conformité pour tous les robots.