Les expériences ont été menées dans le laboratoire d’informatique de l’ISEN. Il est équipé d’un plan de jeu de 2 × 1.6m. Des bandes noires forment un quadrillage de côté de 0.4 mètres. Une caméra 720p permet des prises de vues en 5/10/24 images/s du plan de jeu.
Figure 4.16 – Plan de jeu.
Les robots
Pour les expériences, plusieurs robots à deux roues indépendantes aux caractéristiques variées ont été employés :
Lego NXT Fournis sans modèle véritablement fixé, les Lego NXT permettent de créer plusieurs robots aux configurations différentes : par défaut, ils sont dotés de deux roues indépendantes d’un rayon de 14mm, reliés à deux moteurs dont la vitesse radiale maximale est de 900degrés/s, permettant une vitesse maximale d’environ 25cm/s. La stabilité est assurée par une roue folle. L’empattement est généralement contenu dans un rectangle de 25 × 15cm, l’entraxe étant fixé autour de 14cm selon les modèles. Le firmware Lejos permet d’exécuter notre plateforme APM(Robot), écrite en Java. Celle-ci se charge des communications et de l’application des commandes en vitesse linéaire/vitesse angulaire. Le positionnement est assuré par l’odométrie des moteurs. La faible durée des expériences évite de souffrir de leur importante dérive. Une mire au-dessus du robot fournit également un positionnement absolu des robots NXT, grâce à la caméra située au plafond.
iRobot Create La société iRobot fournit une version recherche de leur célèbre Roomba, le robot aspirateur autonome. Celui-ci, nommé Create, dispose des mêmes caractéristiques que son
4.7. Expérimentations
Figure4.17 – Exemple de robot à deux roues indépendantes Lego NXT.
homologue ménager sans la partie aspirante. En sus, il possède des entrées/sorties permettant l’ajout de nouveaux capteurs, ainsi que de nombreuses fixations permettant l’ajout d’un support à du matériel supplémentaire. C’est ainsi que notre iRobot Create accueille une plateforme supportant un PC portable. La communication est assurée par une liaison série vers le pc portable embarqué. Celui-ci permet au robot de jouer lui-même l’application. Le PC peut également faire relais par liaison Wifi avec un autre ordinateur disposant de la plateforme APM(Robot). Il faut noter qu’un robot de conception similaire est désormais commercialisé sous le nom de TurtleBot par Willow Garage, avec le support et un Kinect fournis d’emblée.
Figure 4.18 – iRobot Create surmonté d’une plateforme portant un ordinateur portable, des capteurs à ultra-son reliés à une brique NXT et un Kinect.
Miabot Bien que ce robot ne figure pas parmi les robots utilisés dans les expériences présentes ici, j’ai également expérimenté DKP sur des robots Miabots de Merlin Robotics. Ceux-ci sont des petits robots dénués de capteurs (en dehors d’une odométrie fort limitée). En revanche, leurs moteurs offrent une très bonne précision à faible vitesse (maximum 20cm/s à l’usage).
Figure4.19 – Miabot, petit robot à deux roues produit par Merlin Robotics.
Utilisation
Les robots se localisent eux-même grâce à l’intégration des données des odomètres. Ces données sont ensuite envoyées directement à la plateforme APM(Robot) sur laquelle DKP planifie les mouvements du robot. La plateforme génère les commandes en utilisant un suivi de trajectoire spline pour robots à deux roues indépendantes, méthode décrite dans [Defoort et al., 2007]. Ces commandes sont envoyées en retour aux robots.
4.7.1 APM(Robot) : plate forme pour le déploiement d’applications robotiques
DKP est déployé sur nos robots grâce à notre plateforme nommée APM(Robot) [Dinont et al., 2010]. Le but est de transposer les raisonnements génériques du monde agent au sein d’applications robotiques. Ainsi, APM(Robot) fournit des processus génériques de communications entre les modules et/ou les robots. Le but est de faciliter l’implémentation, le test et le déploiement de nos expérimentations. Telle qu’utilisée dans cette thèse, APM(Robot) peut être apparentée à d’autres plateformes de simulation et de contrôle telles que l’architecture CHRIS [Lallée et al., 2011], Robot Operating System [Quigley et al., 2009] ou Player/Stage [Gerkey et al., 2003]. APM(Robot) fournit un « data store » : un espace pour stocker les données auxquelles sont attachées des méta-données (type, source, timestamp, unité). Un des objectifs d’APM(Robot) avec ce data store est de mettre en place des applications robotiques modulaires auto-organisatrices, à la manière de [Ashley-rollman et al., 2007].
4.7 . E xp ér im en ta tio
Figure4.20 – Interface de APM(Robot) servant à la simulation et à l’exécution des trajectoires des robots. Nous voyons en : (1) les robots disponibles ; (2) la représentation de l’environnement ; (3) le contrôle du temps réel/simulé ; (4) les différentes couches d’information qui peuvent être affichées (Robot, trajectoire, obstacles réels, obstacles grossis) ; (5) le log d’APM(Robot), comprenant les messages qui transitent entre les entités du système (plateforme, robots contrôlés)
4.7.2 Environnement chargé d’obstacles
Cet exemple illustre la capacité de DKP à trouver rapidement des solutions dans des environnements chargés d’obstacles fixes, DKP planifie en employant le mode glouton. L’environnement contient des obstacles placés aléatoirement à la manière de la partie simulations. On obtient des environnements avec de nombreux passages sans issue, situation dans laquelle les approches par échantillonnage strictement aléatoires vont rester bloquées longtemps. DKP a été exécuté en mode glouton (bias = 10) avec les paramètres suivants :
– Tmax = 6s, la durée maximale des échantillons ;
– step = 0.5s, le pas dans la durée des échantillons générés ; – S−= 0cm/s et S+= 10cm/s, les bornes sur la vitesse linéaire ;
– A−= 0cm/s2 et A+= 10cm/s2, les bornes sur l’accélération linéaire.
Figure 4.21 – Expérimentation dans un environnement chargé d’obstacles avec (a) trajectoire planifiée appliquée au robot de (b) jusque (d).
DKP trouve une solution avec un arbre de trajectoires pourtant limité (comparé à ceux de la figure 4.13, qui sont bien plus étendus). Même si la recherche est fortement biaisée vers l’objectif, la diversité en temps sur la durée des échantillons de trajectoire permet à DKP de s’échapper des minima locaux. Le résultat est illustré par la figure 4.21.
Le suivi de trajectoire [Defoort, 2007] compense efficacement l’imprécision des déplacements du robot. Toutefois, il est parfois nécessaire de faire un compromis entre la qualité du suivi en position et la qualité du suivi en angle. Nous avons fait le choix d’une forte précision en position :
4.7. Expérimentations
ce compromis explique les rotations plus importantes que prévu dans nos expérimentations.
4.7.3 Planification en cas de panne
Cet exemple illustre la capacité de DKP à trouver des solutions malgré la présence d’une panne, modélisée sous la forme d’une restriction des points localement atteignables. Le mode optimal est utilisé. On contraint le robot à ne tourner que dans une seule direction (vers la gauche). L’environnement contient deux obstacles placés de manière à ce que le vecteur vitesse initial force le robot à tourner pour atteindre son objectif. DKP a été exécuté en mode glouton (bias = 10) avec les paramètres suivants :
– Tmax = 6s, la durée maximale des échantillons ;
– step = 0.5s, le pas dans la durée des échantillons générés ; – S− = 0cm/s et S+= 10cm/s, les bornes sur la vitesse linéaire ;
– A−= 0cm/s2 et A+= 10cm/s2, les bornes sur l’accélération linéaire.
Le résultat est illustré par la figure 4.22.
Figure 4.22 – Expérimentation d’une situation où le robot est confronté à une panne avec en (a) trajectoire planifiée appliquée au robot en (b).
4.7.4 Dépassement
L’un des objectifs de la thèse est de pouvoir décrire des comportements humains pour résoudre des situations de conduite usuelles. C’est pourquoi l’une des situations que nous allons détailler est le problème du dépassement. DKP ne dispose que d’un guidage simpliste. Cet exemple sera amélioré dans le chapitre suivant. Il est tout de même possible de confronter DKP à cette situation. De manière similaire à [Wilkie et al., 2009], des données de haut niveau peuvent être intégrées à DKP pour anticiper les futurs états possibles des obstacles mobiles à éviter : c’est l’objet du module de raisonnement présenté dans le Chapitre 5.
Cette situation est illustrée par la Figure 4.23. Deux robots R1 (en bas) et R2 (au dessus)
effectuent des déplacements en ligne à vitesse constante (respectivement 3cm/s et 4cm/s). Un troisième robot R0 utilise DKP pour planifier une trajectoire minimisant le temps tout en évitant
les robots R1 et R2. La thèse n’est absolument pas focalisée sur l’estimation de trajectoire, bien
que l’approche géométrique utilisée dans DKP pour la détermination de l’espace localement atteignable ouvre des pistes à explorer en la matière. Aussi, la trajectoire des obstacles est entièrement connue. DKP a été utilisé en mode backtrack (bias = 10) avec les paramètres suivants :
– Tmax = 6s La durée maximale des échantillons ;
– step = 0.5s le pas dans la durée des échantillons générés ; – S−= 0cm/s et S+= 20cm/s les bornes sur la vitesse linéaire ;
– A−= 0cm/s2 et A+= 10cm/s2 les bornes sur l’accélération linéaire.
Les paramètres supplémentaires, spécifiques au mode backtrack, sont :
– le rayon minimal des obstacles virtuels qui est fixé à rvobstacle,pk0...kn = Tk0...kn+1×
S+
size avec
size = 10 et Tk0...kn+1 la durée du morceau retiré ;
– la valeur de déclenchement du backtrack qui est fixée à trigger = 4. Le résultat est illustré par la figure 4.23.
Figure 4.23 – Expérimentation d’un cas du dépassement d’un robot R1 par R0 en évitant R2