Environnement logiciel

L’environnement logiciel utilisé lors de nos expériences est représenté dans la Figure 4.1. Il incorpore deux composants permettant la simulation des composants matériels et de l’environnement physique d’un robot (Gazebo et Pocosim) ainsi que les composants de l’architecture LAAS présentés dans la Section 3.2.1.1.

Le simulateur de robot Gazebo2_{, disponible en logiciel libre sous la GNU Ge-} neral Public License, est utilisé pour simuler les composants physiques du robot, son environnement, et leurs interactions. En particulier, il propose la simulation de la cinématique d’objets rigides (accélération, vitesse, collision...), et de capteurs et actionneurs typiques de robot (caméras, capteurs-lasers, odométrie, roues mo- torisées...). Ce simulateur prend en entrée un fichier de description de l’environne- ment initial, comprenant d’une part la masse et la position des obstacles (et éven- tuellement leur vitesse pour des obstacles dynamiques), et d’autre part la position initiale et une description du robot, comprenant la liste de ses capteurs.

La bibliothèque Pocosim [Joyeux et al. 2005] fournit un pont logiciel entre les modules GenoM qui contrôlent l’architecture matérielle du robot réel et le robot simulé dans Gazebo. Elle transforme les requêtes matérielles des modules en ac- tions ou mouvements à exécuter par le robot simulé, et transmet aux modules les données de capteurs simulées par Gazebo.

Le système autonome cible reproduit un système autonome existant, déve- loppé au LAAS et implanté sur un robot de type ATRV (All Terrain Robotic Vehicle) commercialisé par iRobot. Il utilise des procédures OpenPRS et des modules Ge- noM directement repris du système autonome existant. FTplan est intégré à l’ar- chitecture et gère deux instances d’IxTeT, utilisant deux modèles diversifiés ainsi que présenté dans la Section 3.2.2. Le robot dispose d’un chassis à roues moto- risées non-holonome, de deux caméras disposées sur un banc orientable, et d’un capteur-laser de proximité.

Le composant R2C n’est pas implanté dans le système autonome simulé, car il est incompatible dans sa version actuelle avec le pont logiciel Pocosim. En ef- fet, Pocosim enveloppe les modules GenoM pendant leur exécution, masquant au

4.1 Environnement d’évaluation

77

CAMERA PLATINE ANTENNA

SICK ARCHITECTURE Modèle2 Modèle1 Objectifs LAAS ENVIRONNEMENT DE SIMULATION du monde Description IxTeT1 IxTeT2 FTplan OpenPRS

Figure 4.1: Environnement logiciel des expériences

reste du système un espace de mémoires partagées utilisées par les modules pour s’échanger des données. Dans le système réel, R2C récupère des informations sur la couche fonctionnelle directement dans ces mémoires partagées, alors qu’il n’y a pas accès dans le système simulé. La suppression du composant R2C diminue la robustesse globale de l’architecture LAAS, avec ou sans le composant FTplan, et probablement, dans une moindre mesure, sa tolérance aux fautes. Cependant, l’architecture LAAS, même sans le composant R2C, nous semble une architecture suffisamment représentative des systèmes autonomes pour évaluer l’efficacité du composant FTplan proposé dans le chapitre précédent.

La partie fonctionnelle du système autonome comporte huit modules GenoM, qui peuvent être distingués selon trois groupes :

• Les modules SICK et RFLEX utilisent la bibliothèque Pocosim pour contrô- ler des composants matériels simulés par Gazebo. SICK contrôle le capteur- laser du robot, tandis que RFLEX supervise le mouvement des roues et l’odométrie.

• NDD, ASPECT et POM sont des modules logiciels qui utilisent SICK et RFLEX pour réaliser les fonctions de navigation et d’évitement d’obstacles. POM fusionne habituellement les données de position des différents cap- teurs afin de fournir au système une position unique gérant les incerti-

78

Chapitre 4 - Évaluation des mécanismes de tolérance aux fautes

tudes et les imprécisions des équipements matériels ; dans notre cas, seule l’odométrie est utilisée, et POM sert principalement de pont entre RFLEX et NDD. ASPECT crée une carte de l’environnement immédiat du ro- bot en tenant compte des données du capteur-laser. NDD utilise à son tour les données de POM et ASPECT pour générer des données de na- vigation, à partir d’un algorithme basé sur les diagrammes de proximité [Minguez & Montano 2004].

• Les modules PLATINE et ANTENNA sont destinés au contrôle des compo- sants matériels qui ne sont pas simulés par Gazebo (un moteur d’orienta- tion des caméras, et un matériel de communication avec un orbiteur). Les caméras du système, dont le contrôle est prévu par le module CAMERA, peuvent théoriquement être simulées par Gazebo, mais le pont logiciel cor- respondant n’est pas développé. Le code source de ces trois modules a donc été modifié afin de fournir une simulation simple de leur comportement, leurs requêtes étant supposées réussir systématiquement.

L’environnement simulé est moins complexe qu’un environnement réel : mal- gré le simulateur physique de Gazebo, les interactions entre le robot et l’environne- ment sont simplifiées, et les situations adverses moins nombreuses et diversifiées. Cependant, nous estimons que la simulation des composants et des interactions physiques de notre système reste compatible avec l’évaluation des mécanismes de tolérance aux fautes, parce que nous souhaitons évaluer les performances de la couche décisionnelle du système plutôt que la couche matérielle. En effet, une exécution plus réaliste, bien que préférable en terme de représentativité ou de di- versification des situations adverses, ne nous semble pas indispensable tant qu’il est possible d’étudier le comportement et la réaction des mécanismes décision- nels intégrés dans le système autonome complet, et de mettre en jeu de situations adverses externes au système susceptibles de stresser leurs différentes capacités.

Une restriction importante liée à notre expérimentation est l’impossibilité d’ac- célérer le temps de simulation. En effet, bien qu’il soit en théorie possible d’accé- lérer le temps dans le simulateur physique Gazebo, les ressources du planificateur IxTeT restent limitées par la puissance du processeur, et le processus de planifica- tion ne peut donc pas être accéléré. Ceci nous oblige à exécuter chaque simulation en temps réel, et restreint donc le nombre de simulations que nous pouvons faire en un temps donné.