Méthodologie d’évaluation du degré d’autonomie d’un robot mobile terrestre

La notion d’autonomie

Tout d’abord, différencions les systèmes dit automatiques des systèmes dit autonomes. Dans [Clough, 2002], les systèmes automatiques, sont ceux qui ont été pré-programmés, qui n’ont pas le choix de leurs actions, en opposition aux systèmes autonomes qui peuvent décider. On voit très bien que la frontière entre les deux n’est pas franche. On pourrait être tenté de dire qu’un système déterministe est automatique, et que les autres sont autonomes. Mais si l’on considère par exemple, un robot purement réactif naviguant par la méthode des champs de potentiels, il peut être considéré comme déterministe (si l’on considère que les incertitudes attachées aux capteurs ne sont pas trop grandes, sachant l’environnement, les points de départ et d’arrivée, on peut prédire son chemin), pourtant nous aurons tendance à le classer dans les systèmes autonomes, car il est capable d’agir sur sa trajectoire en fonction de l’environnement. Nous considérerons qu’un système est autonome s’il est capable d’adapter son comportement à l’environnement, tandis que les systèmes automatiques sont ceux qui évoluent dans des environnements complètement prévisibles. La distinction se fera sur la variabilité des conditions extérieures, le système automatique agissant dans un environnement assez maîtrisé, son comportement ayant été conçu en fonction de cela (on pense tout de suite aux tâches répétitives de l’industrie manufacturière, gourmande en automatismes). Cette distinction faite, nous n’avons toujours pas défini l’autonomie en robotique. Concrètement il est très difficile de donner une définition à l’autonomie. La principale raison étant qu’il s’agit d’une notion très subjective et relative. Subjective, dans le sens où deux utilisateurs qui évaluent le même système, ne le verront pas de la même façon, selon les critères qu’ils privilégieront. Et relative car on ne peut évaluer et comparer l’autonomie d’un système sur deux tâches différentes. A cela s’ajoute une confusion dans la communauté IA qui est de comparer “l’intelligence” et l’autonomie des systèmes. Si l’on qualifie souvent les systèmes autonomes comme étant des systèmes intelligents, la définition de l’intelligence étant elle même très vague, cela ne rend pas le terme autonomie plus clair. L’intelligence est une notion que l’on a déjà bien du mal à définir pour l’homme (en particulier, les tests de QI sont souvent critiqués). De plus dans notre cas, l’intelligence se rapporte bien souvent aux composants décisionnels d’un robot et à ses capacités de calcul. Or comme nous l’avons précisé, un robot purement réactif ne peut être considéré comme non autonome pour la seule raison qu’il possède une “intelligence” limitée.

Les capacités des robots

Classiquement on distingue deux types d’autonomie en robotique : l’autonomie opérationnelle et l’autonomie décisionnelle. Cette distinction vient du découpage que l’on trouve dans les architectures de contrôle sur les robots. Par exemple la figure II.1 représente l’architecture développée, implémentée et utilisée au LAAS. On retrouve les capacités opérationnelles vers le bas de l’architecture, jusqu’au niveau fonctionnel. Les capacités décisionnelles se trouvent tout en haut. Par la suite nous prendrons cette architecture comme base pour illustrer la présentation des capacités des robots. Même si toutes les architectures robotique ne sont pas de type hiérarchique, les architectures les plus évoluées embarquent des composants fonctionnels et des organes décisionnels.

Le DARPA grand challenge

Le grand challenge de la DARPA est la compétition la plus ambitieuse à ce jour. Les “grand challenge” 2004 et 2005 consistent en une course à travers le désert, de véhicules entièrement autonomes. Les véhicules doivent emprunter une route pouvant comporter des passages dans l’eau, de la route pavée, des chemins de terre ou de sable, des passages obstrués naturellement ou artificiellement, . . . L’itinéraire est donné à chaque concurrent peu avant le départ, sous forme de points de passages (longitude, latitude, vitesse limite, taille du couloir de passage, temps limite). Un véhicule qui ne respecte pas les contraintes de passage est éliminé, de même s’il reste immobile trop longtemps. La première session, qui a eu lieu en mars 2004, est longue de 200 miles qui doivent être parcourus en moins de 10 heures. Le véhicule SandStorm (fig. II.7) de la Red Team (Carnegie Mellon University) est celui qui a parcouru le plus de distance avec 7,4 miles. Sandstorm est un véhicule tout terrain. Il se localise par GPS et centrale inertielle, repère les obstacles grâce à des télémètres laser, une paire de caméras en stéréo-vision et un radar. Pour faire face à la quantité de calculs et de traitements, il embarque 7 processeurs (1 pentium III pour le contrôle de la direction et la supervision, 4 Itanium II sur serveur pour la planification de trajectoire et une plate forme bi-processeur à base de Xeon pour les lasers, caméras et radar). La deuxième session du grand challenge a eu lieu en octobre 2005. Pour cette course de 10 heures, le parcours était de 132 miles dans le désert du Mojave. Stanley, le véhicule de l’université de Stanford (fig. II.8) a remporté la victoire en 6 heures et 54 minutes, suivi de près par les deux véhicules de Carnegie Mellon. En tout 6 véhicules ont réussi à terminer la course (dont 5 dans le temps imparti). Le prochain grand challenge de la DARPA devrait avoir pour cadre la navigation en milieu urbain.

SMART

Pour le projet SMART (Spacecraft Mission Assessment and Re-planning Tool), la Nasa a besoin d’outils pour spécifier le niveau d’autonomie de ses logiciels [Proud et al., 2003]. Ici les niveaux d’autonomie reflètent le partage des responsabilités entre la machine (ici l’ordinateur et non un robot) et l’homme : lorsqu’il est ici question de niveau d’autonomie il faut bien le voir comme un niveau de responsabilité. Plus le niveau est faible et plus l’homme est impliqué. Le tableau II.2 donne l’échelle d’autonomie dans ce projet. L’utilisation de ce tableau tranche sur le niveau de confiance que l’on a en l’homme ou en la machine. Si l’on considère que pour une tâche donnée l’ordinateur est plus sûr que l’homme, alors on lui donnera un grand niveau d’autonomie. A l’inverse, dans des tâches critiques pour lesquelles la machine n’est pas fiable, on lui confiera un petit niveau d’autonomie. La classification des systèmes se fait selon l’expertise des utilisateurs et concepteurs, c’est à dire qu’il n’existe pas de méthode d’évaluation quantitative pour de tels systèmes.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

I Introduction
I.1 Généralités
I.2 La notion d’autonomie
I.3 Ce qui se cache dans les pages suivantes
II Etat de l’art
II.1 Les capacités des robots
II.1.1 Capacités fonctionnelles
II.1.2 Capacités décisionnelles
II.2 Les niveaux d’autonomie
II.2.1 Le système de classification ALFUS
II.2.2 FCS
II.2.3 Difficultés – Limitations
II.3 Benchmarking
II.3.1 Sur des algorithmes
II.3.2 Compétitions robotiques
II.4 Autonomie partagée
II.4.1 Interaction homme/robot
II.4.2 La coopération multi-robots
II.5 Conclusion
III Méthodologie
III.1 Démarche générale
III.1.1 Spécification d’une mission
III.1.2 Paramètres influents sur le déroulement de la mission
III.1.3 Une analogie : le système de l’éducation nationale
III.2 Métriques liées aux performances
III.3 Métriques liées à l’environnement
III.3.1 Complexité de l’environnement
III.3.2 Information possédée sur l’environnement
III.3.3 Mise en œuvre : les calculs en pratique
III.4 Une nouvelle méthode d’analyse : les “system maps”
III.4.1 Les réseaux bayésiens dynamiques
III.4.2 Les system maps
III.4.3 A quoi cela peut-il nous servir ?
III.5 Conclusion
IV Mise en œuvre et expérimentation
IV.1 Simulation et benchmark
IV.1.1 Maîtrise de l’environnement
IV.1.2 Le choix de la simulation
IV.2 Intégration dans une architecture robotique
IV.3 Scénarios étudiés
IV.3.1 Corridor
IV.3.2 Exploration du laboratoire
V Analyse des données
V.1 Premier scénario : le corridor
V.1.1 Mesures globales
V.1.2 Mesures locales
V.1.3 Confrontation des deux analyses
V.2 Second scénario : exploration du laboratoire
V.2.1 Les System Maps
V.2.2 Analyse des données
V.2.3 Extensions
V.2.4 Remarque sur la réactivité
V.3 Conclusion
VI Conclusion – Perspectives
VI.1 Bilan – Contribution
VI.1.1 La méthode
VI.1.2 L’expérimentation
VI.1.3 L’analyse
VI.2 Perspectives
VI.2.1 Extension
VI.2.2 Faire du benchmarking
VI.2.3 Et l’autonomie dans tout ça ?
Références bibliographiques