Modelling and Model-Checking a ROS2 Multi-Robot System using Timed Rebeca

Dans le monde de la robotique, construire une seule machine qui bouge et réfléchit est déjà assez difficile. Construire une équipe de machines qui travaillent ensemble sans s'entrechoquer est un défi d'une tout autre nature. Ces machines, souvent appelées robots mobiles autonomes, sont conçues pour naviguer dans des environnements réels, en évitant les murs, les personnes et les unes les autres tout en essayant d'atteindre des destinations spécifiques. Le logiciel qui les fait fonctionner est incroyablement complexe, s'appuyant sur un flux constant de données provenant de capteurs tels que des lasers pour comprendre où elles se trouvent et ce qui les entoure. Parce que ces robots opèrent dans un monde physique continu, leurs mouvements sont fluides et réguliers, changeant par de minuscules fractions de seconde et de millimètres de distance. Cependant, les ordinateurs qui les contrôlent pensent en étapes discrètes, traitant l'information en blocs de temps distincts. Ce fossé entre la réalité fluide de la physique et la logique par étapes du code crée un angle mort dangereux. Si le logiciel n'est pas parfaitement réglé, un robot pourrait se déplacer trop vite pour que ses capteurs détectent un obstacle, ou deux robots pourraient arriver à la même intersection au même instant exact, menant à une impasse où aucun ne peut bouger.

Pour résoudre cela, les chercheurs ont besoin d'un moyen de tester tous les scénarios possibles auxquels une équipe de robots pourrait être confrontée avant même d'allumer les machines réelles. C'est là qu'intervient un domaine appelé la vérification formelle. Au lieu de lancer une simulation quelques fois en espérant que tout se passe bien, la vérification formelle utilise la logique mathématique pour vérifier chaque chemin possible qu'un système pourrait emprunter. Elle pose une question simple mais puissante : existe-t-il une séquence d'événements, aussi improbable soit-elle, qui puisse causer la défaillance du système ? Pour une équipe de robots, cela signifie prouver qu'ils ne se percuteront jamais, qu'ils ne resteront jamais bloqués indéfiniment et qu'ils atteindront toujours leurs objectifs. Le défi a toujours été que les robots réels se déplacent dans un monde continu, tandis que ces preuves mathématiques nécessitent que le monde soit décomposé en une grille d'étapes fixes. Si les étapes sont trop grandes, la preuve manque de petits accidents critiques. Si les étapes sont trop petites, l'ordinateur est submergé par le nombre colossal de possibilités et ne peut terminer le calcul.

Une équipe de chercheurs de l'Université de Mälardalen et de l'Institut royal de technologie (KTH) en Suède a développé une nouvelle façon de combler ce fossé. Ils ont créé un système qui permet aux ingénieurs de concevoir une équipe de robots multi-agents en utilisant un langage de modélisation spécialisé appelé Timed Rebeca, qui traite chaque robot comme un acteur indépendant réagissant à des messages. Ce modèle est ensuite rigoureusement vérifié par un ordinateur pour garantir la sécurité. De plus, l'équipe a également écrit le logiciel réel des robots en utilisant un système standard appelé ROS2, garantissant que le modèle mathématique et le code réel étaient parfaitement alignés. Ils n'ont pas seulement simulé les robots ; ils ont construit une version du modèle qui était assez abstraite pour être vérifiée par un ordinateur, mais assez détaillée pour refléter la physique réelle des machines. En faisant cela, ils ont pu prédire des défaillances rares et dangereuses que les simulations standards manquent souvent.

Les chercheurs se sont concentrés sur un scénario impliquant cinq robots se déplaçant sur une grille de cinquante par cinquante, un espace à peu près de la taille d'un grand sol d'entrepôt. Ils ont mis en place un environnement complexe où les robots devaient naviguer autour d'obstacles et croiser leurs trajectoires pour atteindre leurs cibles. Dans le monde réel, ces robots utilisent des scanners laser pour détecter des objets, prenant des mesures des centaines de fois par seconde. L'équipe a dû trouver comment traduire ces faisceaux laser continus et ces mouvements fluides en étapes discrètes requises par l'ordinateur pour vérifier la logique. Ils ont découvert qu'il existe une relation stricte entre la vitesse à laquelle un robot se déplace et la fréquence à laquelle il scanne son environnement. Si un robot se déplace trop rapidement, il peut parcourir toute la distance entre deux scans sans que le capteur ne remarque un obstacle sur son chemin. Les chercheurs ont prouvé que, pour que leur modèle soit précis, la vitesse du robot devait être limitée afin qu'il ne puisse pas traverser une cellule de la grille plus vite que le temps nécessaire à la mise à jour du capteur. Cette règle, dérivée d'un principe fondamental du traitement du signal, garantissait que le modèle numérique ne manque aucune collision potentielle.

Pour rendre la vérification informatique réalisable, l'équipe a dû simplifier le monde sans perdre la vérité du problème. Ils ont représenté les robots non pas comme des formes fluides, mais comme des rectangles se déplaçant d'une cellule carrée à une autre, tournant par incréments de quarante-cinq degrés. Ils ont calculé le temps nécessaire pour passer d'une cellule à l'autre en fonction de la vitesse du robot et de la taille de la cellule. Ils ont également pré-calculé des valeurs trigonométriques complexes, telles que le sinus et le cosinus des angles, et les ont stockées dans des tables de recherche afin que l'ordinateur n'ait pas à les calculer de zéro à chaque fois. Ces optimisations ont permis au vérificateur de modèle d'explorer des millions d'états en quelques minutes. Lorsqu'ils lançaient la vérification, l'ordinateur pouvait leur dire avec une certitude absolue si un ensemble spécifique de règles mènerait à un crash ou à une arrivée sécurisée.

Les résultats de leurs expériences ont été frappants. Dans les cas où les robots étaient programmés avec des vitesses sûres et des temps d'attente variés, le vérificateur de modèle a confirmé que les cinq robots atteindraient leurs destinations sans jamais entrer en collision ni rester bloqués. Les chercheurs ont ensuite exécuté le code ROS2 réel dans une simulation, et les robots se sont comportés exactement comme leur modèle le prédisait, naviguant avec succès dans l'espace encombré. Cependant, lorsqu'ils ont modifié les paramètres pour créer une situation dangereuse — comme faire circuler tous les robots à la même vitesse exacte ou fixer un taux de balayage trop faible pour la vitesse — le vérificateur de modèle a immédiatement trouvé une faille. Il a identifié une séquence spécifique d'événements qui mènerait à une collision. Lorsqu'ils ont exécuté le code réel avec ces mêmes paramètres dangereux, la simulation a planté exactement de la même manière que le modèle l'avait prédit. Dans un test, le modèle a trouvé une collision après avoir exploré seulement quelques milliers d'états, tandis que la simulation réelle a échoué trois fois sur cinq, confirmant que le danger était réel et prévisible.

L'étude a également souligné l'importance du timing. Dans un scénario, les chercheurs ont réglé les robots sur une vitesse qui était juste un peu trop rapide pour le taux de mise à jour du capteur. Le vérificateur de modèle a découvert que cette petite violation de la règle de sécurité rendait une collision presque inévitable, quel que soit le programme utilisé par les robots pour s'éviter. L'ordinateur a montré que les robots arriveraient à un point de croisement au même moment et, comme ils ne pourraient pas se voir à temps, ils entreraient en collision. La simulation réelle a confirmé cela, les robots échouant à s'éviter dans chaque exécution. Cela a démontré que le modèle n'était pas seulement un exercice théorique, mais un outil pratique capable de détecter des erreurs subtiles et dangereuses que les ingénieurs humains pourraient négliger.

Les chercheurs ont reconnu que leur approche présente des limites. La méthode actuelle exige que les ingénieurs construisent manuellement à la fois le modèle mathématique et le code réel, ce qui est un processus chronophage pouvant introduire une erreur humaine. Ils ont également noté que, bien que leur système puisse gérer cinq robots sur une grille de cinquante par cinquante, le passage à cent robots ou à une carte beaucoup plus grande saturerait rapidement la mémoire de l'ordinateur. Le goulot d'étranglement est le nombre phénoménal de chemins possibles que les robots peuvent emprunter ; à mesure que le nombre de robots et la taille de la carte augmentent, le nombre de combinaisons croît si vite que l'ordinateur manque d'espace pour les stocker. Malgré ces limitations, ce travail prouve qu'il est possible de créer un jumeau numérique d'un système robotique complexe qui soit à la fois assez simple pour être vérifié et assez précis pour être fiable.

Cette recherche offre une nouvelle voie pour le développement de systèmes autonomes sûrs. En traitant la conception du logiciel robotique comme un processus consistant à construire et vérifier d'abord un modèle mathématique, les ingénieurs peuvent identifier les failles fatales avant qu'un seul robot ne soit construit ou déployé. L'équipe a démontré qu'en équilibrant soigneusement le niveau de détail du modèle avec la nécessité d'efficacité computationnelle, il est possible de vérifier qu'un système multi-robots se comportera de manière sûre dans le monde réel. Leur travail suggère que l'avenir de la robotique ne réside pas seulement dans la construction de machines plus intelligentes, mais dans la création de meilleures façons de prouver que ces machines ne failliront pas quand cela comptera le plus.