Préparation de la stratégie du robot sur simulateur
Dans cette article, nous allons aborder le développement du code de “stratégie” au sein du club Robot ESEO. Nous allons tout d’abord présenter notre simulateur, appelé Toolkit, avant de décrire plus en détail la méthodologie de développement des différentes machines à états implémentant la stratégie de nos robots.
1- Présentation de notre simulateur: la Toolkit
La Toolkit est un outil indispensable au développement de la stratégie de nos robots. Il s’agit d’un simulateur multi-plateformes (Windows et Linux) codé sous Qt qui permet de faire de la simulation hardware-in-the-loop. La carte électronique principale du robot, appelé fond de panier, est directement connectée au PC sur lequel s’exécute le simulateur via deux liaisons RS232. Sur cette carte électronique viennent se plugger trois STM32: une gérant la stratégie, une gérant les actionneurs, et une gérant la propulsion du robot. Les entrées/sorties de ces cartes ne sont donc pas reliées aux capteurs et actionneurs physiques du robot mais redirigées vers le simulateur.
La Toolkit offre différentes fonctionnalités permettant d’accélérer et de faciliter le développement de la stratégie du robot. Différents terminaux série permettent d’afficher toutes les infos renvoyées par le fond de panier. Parmi ces informations, appelées logs, on trouve les messages CAN envoyés entre les différentes STM32 dont les ordres de déplacements et les ordres actionneurs ainsi que leurs acquittements. Les logs contiennent aussi les informations relatives aux changements d’états des machines à états (sans doute l’info la plus importante), le temps de match, les éléments actuellement stockés dans le robot, les éléments restants sur le terrain, et les flags échangés avec l’autre robot.
Une vue de l’aire de jeu en 2D permet de visualiser les déplacements (virtuels) de nos robots afin d’analyser leurs trajectoires. Il est également possible de simuler les robots adverses afin de voir les choix adoptés par nos robots lorsqu’ils rencontrent un robot adverse. Une fenêtre permet également de changer la valeurs des switchs du robots pour tester des stratégies alternatives, changer la couleur du robot, ou encore simuler des pannes d’actionneurs. À chaque fois, l’objectif est d’analyser les choix du robot (choix de trajectoires, changement de l’action à réaliser etc.) pour voir s’ils sont pertinents.
2- Notre méthodologie de développement de la stratégie
Le développement de la stratégie du robot se fait en deux étapes: une première étape sur simulateur pour mettre au point notre code, et une seconde étape sur robot réel afin de peaufiner les enchaînements des actions et faire certaines optimisations.
Le développement sur simulateur est primordial car il permet de développer la majorité de la stratégie sans avoir les robots réels. Le codage sur simulateur se fait en général en deux étapes. (1) On commence par implémenter une machine à état pour chaque action, appelée dans notre club une “subaction”. L’objectif est de développer le squelette de la machine à états avec les déplacements du robot et les ordres actionneurs. À chaque itération, le code est programmé sur la carte stratégie du fond de panier et la Toolkit est utilisée pour valider le comportement du robot. Cette première étape permet de faire une validation unitaire de chaque subaction. (2) Une fois que les différentes subactions ont été implémentées, l’objectif est de les intégrer les unes avec les autres pour enchaîner différentes actions. Toutes ces subactions sont alors gérées par un algorithme de haut-niveau (dans notre jargon la “high level”) qui permet de choisir la subaction la plus adaptée à réaliser à un instant t du match en prenant en compte la priorité des subactions restantes, le temps de match restant, les éléments stockés dans le robot, et l’action en cours de réalisation par l’autre robot. La Toolkit permet alors de simuler des matchs complets, de tester des stratégies alternatives ou encore de voir comment nos robots se comportent quand un robot adverse vient les embêter. Il devient aisé de tester un grand nombre de matchs dans plein de configurations différentes ce qui serait beaucoup, beaucoup, beaucoup plus long sur un robot réel.
Une fois le développement sur simulateur réalisé et que la mécanique du robot est opérationnelle, il est alors possible de tester des matchs en conditions réelles. Ces tests sont utiles pour d’une part faire des corrections de trajectoires, vérifier le bon fonctionnement des actionneurs et éprouver la répétabilité du code et de la mécanique de nos robots. Là encore la Toolkit est d’une grande utilité car elle permet de récupérer en temps réel ou a posteriori les logs du match. Au club robot de l’ESEO, il n’est pas rare d’entendre un codeur demander “Tu peux dépiler le match log stp !” afin de récupérer les logs du match précédent que le robot a stocké sur sa carte SD. À ce stade de développement, il est fréquent que les matchs soient filmés (parfois même en slow motion) pour analyser les moindre faits et gestes de nos robots réels. Cela permet de réaliser des optimisations et de gagner quelques centaines de millisecondes sur chaque subaction. Des compromis entre répétabilité, rapidité et simplicité doivent alors être trouvés afin de remplir au mieux chacun de ces trois critères.
La Toolkit est donc un élément primordial pour le développement de la stratégie de nos robots !!
Valentin.B