Simulation robotique pour les laboratoires de recherche : du concept à la validation matérielle

Principaux enseignements

• La simulation robotique s'avère utile pour la validation matérielle lorsque la synchronisation, les E/S et l'exécution du contrôleur sont définies avant le choix des outils.
• La simulation des capteurs et celle des systèmes embarqués revêtent une importance capitale lorsqu'elles permettent de reproduire les défaillances qui altèrent la sortie de commande, le niveau de confiance de l'estimateur et la synchronisation du micrologiciel.
• Les laboratoires passent plus facilement de la phase de conception à la validation en laboratoire lorsque le périmètre des essais HIL s'étend par étapes, avec des critères de réussite bien définis à chaque étape.

Les laboratoires de recherche devraient considérer la simulation robotique comme un système de validation bien avant qu’un contrôleur ne soit intégré au matériel.

Cette évolution est importante, car le risque le plus élevé ne réside que rarement dans la physique seule. Il réside dans la synchronisation, le décalage des capteurs, le trafic sur le bus et les hypothèses relatives au micrologiciel qui semblent correctes dans le cadre d’un modèle de bureau. Le parc mondial de robots industriels a atteint 4 281 585 unités en 2023, ce qui montre à quel point les logiciels de contrôle validés sont désormais essentiels tant dans les laboratoires que pour les équipes de production. Si votre simulation robotique ne peut pas fonctionner en boucle fermée avec un timing déterministe, elle ne vous fournira pas suffisamment d’informations lorsque vous passerez de la phase de conception aux essais sur banc.

Les laboratoires de recherche ont besoin d'un processus de validation avant de choisir leurs outils

Un plan de simulation robotique efficace commence par les questions relatives au matériel auxquelles vous devez répondre, puis remonte en amont vers les modèles et les outils. Les laboratoires de recherche perdent du temps lorsqu’ils choisissent un simulateur en se basant sur les graphismes ou la taille de la communauté avant d’avoir défini les limites de latence, les besoins en E/S et les objectifs des contrôleurs. Votre processus de validation doit être défini avant que votre pile logicielle ne se développe. Ce processus déterminera tous les tests ultérieurs.

Une équipe travaillant sur un robot mobile en offre un exemple simple. Les premières étapes de conception peuvent se limiter à la cinématique, à la lecture d’une carte et au réglage du planificateur. La validation matérielle soulève toutefois des questions plus complexes : le contrôleur de roue peut-il maintenir la vitesse malgré le bruit du codeur ? L’estimateur parvient-il à se remettre d’un retard de paquets ? Le processeur dépasse-t-il les délais lorsque la charge de perception augmente ? Ces questions vous orientent vers la simulation des capteurs, la simulation des systèmes embarqués et les vérifications de synchronisation en boucle fermée bien avant même que vous ne compariez les outils.

Cette séquence est importante car chaque étape de validation ajoute des contraintes dont la mise en œuvre a posteriori s'avère coûteuse. Les contrats d'interface, les fréquences d'échantillonnage et les cas de défaillance doivent être définis dès le début, tant que les modèles sont encore faciles à modifier. Les laboratoires qui sautent cette étape se retrouvent souvent contraints de refaire les modèles de l'installation et les « wrappers » des contrôleurs par la suite. La meilleure approche est simple : définir ce qui doit être vérifié sur le matériel, puis concevoir la simulation en fonction de cette vérification.

L'exécution en boucle fermée définit la valeur de simulation pour la validation matérielle

L'exécution en boucle fermée signifie que le contrôleur, le modèle de l'installation et les E/S évoluent tous selon une synchronisation fixe, avec une latence mesurée. C'est ce qui confère toute sa valeur à la simulation lors de la validation matérielle. Un modèle qui semble stable alors qu'il existe un décalage temporel entre les composants masquera justement les défauts que vous devez détecter. À ce stade, le déterminisme prime sur la qualité du rendu.

Une configuration à deux roues permet de le constater. La boucle de courant du moteur peut fonctionner à 1 kHz, l’estimateur d’état à 100 Hz et le pipeline lidar à 10 Hz. Si le solveur de l’installation se met en pause sous charge, le contrôleur semble toujours fonctionner correctement sur un tracé de bureau, alors que la même logique peut osciller lorsque les actionneurs physiques exigent des délais fixes. Il vous faut une configuration qui mette en évidence les pas manqués, la gigue et les dépassements du planificateur, au lieu de les masquer.

C’est pourquoi la simulation robotique en temps réel destinée à la validation matérielle commence par le respect de la taille des pas, le découpage des tâches et la gestion des horodatages. Les modèles à plusieurs fréquences sont tout à fait acceptables, mais chaque fréquence doit être choisie de manière réfléchie et reproductible. Vous validez le comportement du système de contrôle, et les graphiques de mouvement ne suffisent pas à eux seuls. Lorsque la synchronisation reste fidèle à la réalité, vos résultats de test deviennent transférables de la revue de modèle aux essais sur banc.

« L'exécution en boucle fermée signifie que le contrôleur, le modèle de l'installation et les E/S évoluent tous selon une synchronisation fixe, avec une latence mesurée. »

La simulation du capteur doit reproduire le bruit de synchronisation auquel votre robot sera confronté

La simulation des capteurs doit reproduire de manière suffisamment fidèle les paramètres de synchronisation, de bruit, de quantification et de pertes de données pour mettre à l'épreuve la pile de contrôle. Un flux de données de capteurs « propre » ne vous apprend pas grand-chose sur l'état de préparation du matériel. Votre robot devra gérer des horodatages décalés, des flous de mouvement, des paquets manqués et des dérives de biais. Ces effets doivent apparaître avant que le matériel ne soit connecté.

Un robot de terrain équipé d’un lidar, d’un capteur inertiel et d’un système d’odométrie sur roues illustre bien l’importance de cette question. Le lidar peut fournir des données à 10 Hz, le capteur inertiel à 200 Hz, et chaque source peut comporter sa propre erreur d’horodatage. Les ventes de robots de service professionnels ont atteint 205 000 unités en 2023, et bon nombre de ces plateformes dépendent de la perception en mouvement et dans des conditions d’éclairage variables. Un modèle de capteur qui ignore ces effets faussera la localisation et le suivi de trajectoire.

Il n’est pas nécessaire d’obtenir un rendu visuel parfait pour chaque étude. Ce qui compte, ce sont les modes de défaillance qui modifient la sortie du contrôleur, le niveau de confiance de l’estimateur ou la logique de sécurité. Cela implique généralement de commencer par analyser la synchronisation, le biais, la saturation et la perte de paquets avant de se pencher sur les détails visuels. La simulation de capteurs prend tout son sens lorsqu’elle perturbe le contrôleur de la même manière que le ferait le matériel.

La simulation des systèmes embarqués permet de détecter les défauts d'interface avant les essais au banc

La simulation des systèmes embarqués permet de détecter des défauts que les modèles purement logiciels ne parviennent pas à repérer, car elle teste la synchronisation du micrologiciel, les plages de signaux et les contrats d'E/S par rapport au système physique. Cela vous permet de vérifier plus tôt que le contrôleur est capable de supporter le trafic matériel réel. Le temps passé au banc d'essai s'avère plus fructueux lorsque les erreurs d'interface sont déjà connues. Vous détectez ainsi plus rapidement les erreurs de câblage et de protocole.

Un contrôleur commun sur un bras robotisé en est un bon exemple. Le micrologiciel lit les compteurs du codeur, filtre la vitesse, calcule le couple et envoie des commandes de modulation de largeur d'impulsion selon un calendrier fixe. Une simulation portant uniquement sur le système asservi peut montrer un suivi stable alors que, dans la réalité, le micrologiciel omet une interruption, écrête une valeur signée ou interprète incorrectement une impulsion d'index après une réinitialisation. La simulation des systèmes embarqués permet de mettre en évidence ces défauts avant même que le moteur et la charge ne soient présents.

Cela revêt une importance particulière lorsque le contrôleur est intégré à un microcontrôleur ou à un bus de terrain soumis à des contraintes de synchronisation strictes. Il est en effet préférable que les erreurs de somme de contrôle, les paquets périmés et les problèmes de séquence de démarrage apparaissent dans un environnement de test contrôlé. Cela permet de raccourcir les boucles de débogage matériel et de renforcer la fiabilité des critères de réussite ou d'échec. Cela favorise également une meilleure coordination entre les équipes chargées des contrôles, du micrologiciel et des essais en laboratoire.

Les workflows ROS ont atteint leurs limites lors de la validation de la synchronisation matérielle

Un workflow ROS permet aux équipes de mettre rapidement en place la perception, la planification et le flux de données, mais il ne garantit pas une synchronisation déterministe pour la validation matérielle. Le passage de messages est utile pour les itérations de recherche. L’exécution à pas fixe et la synchronisation stricte des E/S constituent des exigences distinctes. Ces deux éléments sont indispensables dès lors que les contrôleurs et les interfaces physiques entrent en jeu.

Une équipe de planification peut rejouer les sujets de capteurs enregistrés et visualiser le tracé fluide de la trajectoire sur plusieurs semaines. Le problème survient lorsque ce même contrôleur doit envoyer des commandes à un variateur de vitesse toutes les millisecondes, tandis que les informations de rétroaction d’état parviennent via un bus distinct. Les files d’attente de messages, la dérive d’horloge et la planification de l’hôte peuvent modifier suffisamment la synchronisation des paquets pour altérer le comportement du contrôleur. Le logiciel semble fonctionner correctement jusqu’à ce que le banc d’essai impose des délais stricts.

Cela ne rend pas pour autant la pile de recherche inutile. Cela signifie simplement que vous devez la placer là où elle s'intègre le mieux, c'est-à-dire autour du développement d'algorithmes, de l'orchestration et de l'échange de données. La validation de la synchronisation matérielle nécessite un contrôle plus strict sur l'exécution, la synchronisation et les E/S. Une fois cette limite clairement établie, votre workflow de simulation robotique cesse de mélanger les considérations pratiques de la recherche avec la validation matérielle.

Par où commencer les essais HIL pour les commandes de robots ?

Les tests HIL doivent commencer par l'interface de contrôle présentant le risque le plus élevé et la plus faible observabilité. Il s'agit généralement d'une boucle de moteur, d'une chaîne d'entrée d'un estimateur d'état ou d'un verrouillage de sécurité. En commençant par des éléments simples, vous obtenez rapidement des données de synchronisation fiables. Vous pouvez ensuite accroître la complexité du système sans masquer le premier défaut.

Pour la première itération, une cellule d'essai à un seul axe s'avère plus efficace qu'un robot complet. Un actionneur, une voie de codeur et une carte de contrôle vous permettront d'en apprendre davantage sur la gestion de la taille des pas qu'une cellule de travail simulée complète, riche en détails visuels. Une fois cette boucle stabilisée, vous pourrez ajouter la reproduction des données des capteurs, le trafic réseau et la logique de supervision. Chaque couche doit répondre à une question relative au matériel avant que la suivante n'intervienne.

• Commencez par la boucle qui s'exécute à la fréquence la plus élevée.
• Veillez à ce que le premier modèle HIL soit suffisamment petit pour permettre de mesurer chaque retard.
• Ajoutez un parcours de capteur avant d'ajouter des piles de perception complètes.
• Introduisez un seul type de défaillance à la fois afin que les défaillances restent compréhensibles.
• Fixes les critères d'admissibilité avant le début de la première séance de travail.

Cette approche évite que le HIL ne se transforme en un vaste exercice d’intégration reposant sur des données peu fiables. Vous renforcez ainsi la confiance dans la synchronisation, les interfaces et la stabilité des commandes, étape par étape. Les laboratoires qui commencent par tester un robot complet se retrouvent souvent confrontés à des défaillances en chaîne. Une première boucle restreinte vous offre une base de référence claire sur laquelle les tests ultérieurs pourront s’appuyer.

« Les tests HIL doivent commencer par l'interface de commande présentant le risque le plus élevé et la plus faible observabilité. »

Le choix des outils dépend tout d'abord du temps de latence dont vous disposez pour votre laboratoire

Le choix des outils doit commencer par le budget de latence dont votre laboratoire doit disposer. La liste des fonctionnalités vient ensuite. L'exécution à pas fixe, les délais d'E/S et le partitionnement du modèle constituent les conditions minimales requises pour une validation matérielle fiable. Une fois ces limites connues, il est plus facile d'évaluer la facilité d'utilisation des logiciels. Votre choix d'outils doit refléter les besoins mesurés en matière de délais.

Un simulateur de bureau suffit souvent pour la planification de trajectoire, la lecture de cartes et le réglage hors ligne des contrôleurs. Une plateforme qu’OPAL-RT devient pertinente lorsque votre modèle doit garantir une exécution à pas fixe tout en étant connecté à des codeurs, à des signaux de modulation de largeur d’impulsion et à un trafic réseau déterministe. Cette différence n’a pas grand-chose à voir avec les aspects visuels, mais tout à voir avec la maîtrise de la synchronisation. Le choix approprié dépend du test que vous essayez de réussir.

Cette approche par points de contrôle permet de recentrer les débats sur les outils en fonction des besoins des laboratoires. Elle évite également aux équipes de considérer la simulation robotique, la simulation des capteurs et la simulation des systèmes embarqués comme des achats distincts. Pour la validation matérielle, elles forment une seule et même chaîne de test. Votre budget de latence constitue le point de départ le plus évident.

La validation par étapes permet de s'assurer que les prototypes de recherche sont compatibles avec le matériel de laboratoire

La validation par étapes permet de faire avancer les prototypes de recherche, car chaque étape permet de résoudre un problème matériel avant que l'étape suivante n'ajoute de la complexité. Cela permet de mieux cerner les échecs et de réduire le coût des corrections. Les laboratoires qui travaillent de cette manière produisent des résultats plus solides tout en limitant les essais infructueux. Le processus est rigoureux, reproductible et inspire davantage confiance.

Un projet portant sur un manipulateur mobile en démontre l'intérêt. L'équipe valide d'abord une boucle à articulation unique avec du code intégré dans la boucle, puis ajoute des entrées d'estimateur avec un délai de capteur, avant de tester le mouvement coordonné sur l'ensemble du bras et de la base. Lorsqu'un défaut apparaît, le groupe sait déjà à quelle couche il est dû. Cela réduit le temps consacré aux discussions et transforme les sessions matérielles en une vérification ciblée, plutôt qu'en un débogage sans fin.

C’est là que la qualité d’exécution prime sur le volume des modèles. OPAL-RT s’intègre naturellement dans les laboratoires qui définissent déjà des budgets temporels, des cartes d’E/S et des critères de réussite avant même que le matériel ne soit livré. La plateforme une validation rigoureuse, mais son principal atout réside dans la méthode qui sous-tend les tests. Les travaux de recherche aboutissent à la mise en œuvre matérielle avec moins de surprises lorsque le processus de simulation reste ancré dans des preuves mesurables.