Méthodologie de comparaison d`architectures

Transcription

Faculté de génie
Génie électrique et génie informatique
Méthodologie de comparaison
d’architectures décisionnelles hybrides
en robotique mobile et autonome
Définition du projet de recherche
Spécialité : génie électrique
Carle CÔTÉ
Sherbrooke (Québec) Canada
Octobre 2003
TABLE DES MATIÈRES
i
TABLE DES MATIÈRES
1 INTRODUCTION
1
2 CONSIDÉRATIONS SUR LES ARCHITECTURES DÉCISIONNELLES
HYBRIDES EN ROBOTIQUE MOBILE ET AUTONOME
3
2.1
Caractéristiques principales . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Sélection d’action . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.2
Échelle temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.3
Organisation structurelle . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2
Exigences de conception logicielle . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
Discussion des impacts sur le développement des comportements intelligents
10
3 DÉFINITION ET OBJECTIF DU PROJET
14
4 MÉTHODOLOGIE
16
4.1
Description de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
Échéancier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.3.1
Mise à niveau dans le domaine de la robotique mobile et autonome .
26
4.3.2
Environnement de développement logiciel unifié . . . . . . . . . . . .
26
4.3.3
Implémentation du système robotique basé sur l’architecture décisionnelle
EMIB, Phase I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.4
EMIB, Phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.5
3T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.6
Tests et analyse des données . . . . . . . . . . . . . . . . . . . . . . .
29
4.3.7
Rédaction du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . .
29
BIBLIOGRAPHIE
30
LISTE DES FIGURES
ii
LISTE DES FIGURES
1
Architecture décisionnelle hybride 3T . . . . . . . . . . . . . . . . . . . . . .
7
2
Architecture décisionnelle hybride TCA . . . . . . . . . . . . . . . . . . . . .
8
1 INTRODUCTION
1
1
INTRODUCTION
La robotique mobile et autonome est un des axes de recherche pour lequel l’arrivée d’une
nouvelle approche en intelligence artificielle (IA) a un impact intéressant. Le passage d’une
approche classique (mathématique et algorithmique) vers une approche comportementale
(basée sur des notions telles que la cognition, l’apprentissage, l’émergence et la corporéité)
n’est pas chose simple, car elle implique des changements radicaux de mentalité et des modifications majeures dans la façon de concevoir des systèmes robotiques [25].
Les recherches actuelles dans le domaine de la robotique mobile et autonome utilisent typiquement des architectures décisionnelles comme noyau central pour générer les comportements intelligents des systèmes robotiques lorsque soumis à des environnements complexes et
dynamiques. Citons par exemple, l’autonomie, l’apprentissage, l’adaptation, la délibération
et les intentions. Une architecture décisionnelle est un modèle conceptuel qui décrit la structure organisationnelle entre les composants logiciels d’un système robotique, ainsi que les
mécanismes décisionnels qui sont utilisés pour gérer ces composants afin de produire les
comportements intelligents de ce système robotique. Le défi principal pour ces architectures décisionnelles est d’intégrer dans un tout cohérent et fonctionnel plusieurs composants
provenant de domaines de recherches variés tels que la vision artificielle, la planification
et l’allocation de tâches, la gestion de ressources, le contrôle robotique, les interactions
personne-machine, l’intelligence artificielle, et bien d’autres. Plusieurs variantes d’architectures décisionnelles ont été proposées jusqu’à présent, chacune se basant sur des paradigmes
particuliers et incluant des mécanismes et fonctionnalités qui leurs sont propres. Les recherches actuelles montrent que grâce aux capacités développées par ces architectures, cellesci sont en mesure de réaliser des tâches plus ou moins complexes et souvent spécifiques [2].
Depuis quelques années, une tendance se fait sentir vers la conception d’architectures décisionnelles hybrides qui tentent d’exploiter plusieurs concepts des grandes familles d’architectures décisionnelles (réactives, délibératives et comportementales) [23]. La mise en œuvre de
telles architectures doit permettre la conciliation de contraintes de conception imposées par
les approches de chacune des grandes familles, tout en préservant les mécanismes décisionnels
qui favorisent la génération de comportements intelligents. Cette approche intégratrice per-
1 INTRODUCTION
2
mettrait ainsi d’aborder des problèmes exigeant l’exécution de tâches plus complexes et
variées. La tenue annuelle d’un événement comme le “American Association for Artificial
Intelligence Robot Challenge”1 , mettant au défi les chercheurs de concevoir un robot mobile
et autonome qui assiste à une conférence en se comportant comme un conférencier, montre
bien le niveau de complexité et de variété des tâches à accomplir.
Les mises en œuvre de ces architectures hybrides doivent tenir compte de plusieurs exigences logicielles qui viennent influencer grandement le développement logiciel de robots
(par exemple : la modularité, la réutilisabilité, l’extensibilité, le prototypage rapide et le
développement incrémental) [24]. Ces mises en œuvre sont donc réalisées typiquement avec
l’aide d’un environnement de développement logiciel qui sert d’outil à la fois pour répondre
aux exigences logicielles, et pour le développement des comportements intelligents. Toute
limitation à cet outil affecte ainsi les comportements intelligents manifestés par un robot. Il
devient donc important d’arriver à unifier les capacités de ces environnements, et de voir leurs
impacts sur les comportements intelligents des robots tels que structurés par les architectures
décisionnelles.
L’objectif du projet de recherche est de développer une méthodologie de comparaison d’architectures décisionnelles hybrides, en se servant d’un environnement de développement logiciel
unifié afin de créer une base de comparaison homogène entre les mises en œuvre des architectures. Pour créer cette base de comparaison homogène, ce projet propose également d’introduire la notion de capacité de systèmes robotiques car elle permet, malgré les différences
inhérentes et non-négligeables entre les mises en œuvre des architectures, d’évaluer que les
systèmes robotiques créés réalisent des aptitudes similaires pour l’exécution de mêmes tâches.
Ce document se divise en trois sections. La première section présente une revue de littérature
et une discussion entourant les principales considérations sur les architectures décisionnelles hybrides et leurs mises en œuvre. La deuxième section définit le projet de recherche et
présente les principaux objectifs. La troisième et dernière section présente la méthodologie
de comparaison d’architectures décisionnelles hybrides proposée, une courte discussion sur
cette méthodologie, ainsi que l’échéancier du projet de recherche.
1
Description de l’événement 2003 : http ://www.andrew.cmu.edu/˜astroupe/AAAI03/
2 CONSIDÉRATIONS SUR LES ARCHITECTURES DÉCISIONNELLES HYBRIDES
EN ROBOTIQUE MOBILE ET AUTONOME
3
2
CONSIDÉRATIONS SUR LES ARCHITECTURES
DÉCISIONNELLES HYBRIDES EN ROBOTIQUE
MOBILE ET AUTONOME
La création d’architectures décisionnelles hybrides est une réponse aux limitations constatées
de chacun des types d’architecture décisionnelle développés par le passé [3]. L’idée générale
derrière ce type d’architecture est de combiner les différentes approches dans une seule et
même architecture, qualifiée alors d’hybride. De cette manière, une approche réactive peut
par exemple venir compenser les longs temps de calculs requis par une approche délibérative,
tout en conservant ses capacités de raisonnement. Cette façon de combiner les architectures
décisionnelles permet donc de compenser les lacunes de chacune des approches tout en tentant
de préserver leurs avantages.
Cette stratégie a été employée pour réaliser plusieurs architectures décisionnelles hybrides, et
elle est maintenant utilisée couramment pour la recherche en robotique mobile et autonome
car elle semble bien répondre aux besoins de l’évolution des robots dans un environnement
dynamique et complexe (situated robotics). Même s’il n’y a pas consensus sur l’agencement
et l’organisation des sections entre les différentes mises en œuvre, plusieurs caractéristiques
récurrentes viennent influencer le développement logiciel des architectures décisionnelles hybrides [10]. Ces principales caractéristiques sont détaillées dans la sous-section suivante, mais
pour une couverture plus complète des concepts fondamentaux derrière les architectures
décisionnelles hybrides, une excellente présentation se trouve dans Arkin [2].
2.1
Caractéristiques principales
Cette section présente les trois caractéristiques principales sur lesquelles sont fondées typiquement le développement logiciel des architectures décisionnelles hybrides : la sélection
d’action, l’échelle temporelle et l’organisation structurelle.
4
2.1.1
Sélection d’action
Comme toutes les architectures décisionnelles robotiques, l’architecture décisionnelle hybride
fait face au problème de la sélection d’action (Action Selection Problem ou ASP ) : à chaque
instant, le système doit prendre une décision sur l’action courante à faire, au meilleur de
ses connaissances et en fonction des buts à accomplir, de son environnement et de ses états
internes. Plusieurs contraintes physiques et informatiques viennent rendre cette tâche ardue
et il devient pratiquement impossible de faire un choix optimal à chaque instant [26]. Pour
aborder ce problème, plusieurs mécanismes de sélection d’action ont été proposés, chacun
avec leurs avantages et leurs inconvénients [27] :
– Subsumption Architecture [8] ;
– Discrete Event Systems [17] ;
– Temporal Sequencing [4] ;
– Bayesian Decision Analysis [18] ;
– Hierarchical Q-learning [20] ;
– W-learning [14] ;
– Activation Networks [21] ;
– DAMN [29] ;
– SAMBA [28] ;
– Action Voting [13] ;
– Fuzzy/Multivalued Logic Approach [30] ;
– Fuzzy DAMN [36] ;
– Multiple Objective Behavior Coordination [27] ;
– Potential Fields [15] ;
– Motor Schemas [1] ;
– Dynamical system approach [31].
L’intégration de ces mécanismes de sélection d’action au niveau de l’architecture décisionnelle
est tout aussi variée. Une approche comme l’approche comportementale de Brooks [8] intègre
les mécanismes de sélection à même l’organisation des modules comportementaux au sein de
l’architecture. Alors qu’une approche comme l’architecture décisionnelles EMIB [22], en plus
5
d’intégrer des mécanismes comme le fait Brooks, ajoute également des mécanismes à d’autres
niveaux (délibération, émotion, intention) qui permettent de tenir compte de plusieurs autres
dimensions du problème. La mise en place de mécanismes de sélection d’action est donc cruciale lors de la conception d’architectures décisionnelles hybrides, car en plus d’influencer les
comportements intelligents du système, elle peut venir grandement influencer l’organisation
structurelle de l’architecture (comme l’accès à l’information sensorielle ou délibérative, les
règles de priorité et la fusion de données). De plus, les techniques utilisées pour réaliser ces
mécanismes peuvent être de nature différente (réseau de neurones, logique floue, heuristiques,
etc.) [27]. La mise en œuvre logicielle doit donc prévoir une grande flexibilité architecturale
pour répondre aux exigences de la mise en place de mécanismes de sélection d’action aussi
variés.
2.1.2
Échelle temporelle
L’aspect temporel des architectures décisionnelles hybrides est un élément important dans
l’élaboration d’un système basé sur une architecture décisionnelle hybride. En effet, le couplage entre les sections réactives et les sections délibératives entraı̂ne des problèmes de gestion
d’événements qui se situent à des échelles de temps très différentes. D’un côté, les sections
réactives sont mises en place pour réagir en temps réel aux changements qui se produisent
dans un environnement dynamique réel. De l’autre côté, les sections délibératives doivent
consolider, traiter et analyser l’information perçue, pour parvenir à raisonner et à planifier
ce que devrait faire le système afin de produire une action utile. Tous ces traitements se font
à une échelle de temps beaucoup plus longue que ceux faits par les sections réactives, et
doivent tout de même venir activer des modules comportementaux qui ne détérioreront pas
le comportement global du système [27].
Au niveau logiciel, il faut tenir compte de toutes les exigences et particularités de cette
approche qui influencent beaucoup la programmation globale d’un système. On doit notamment évaluer les aspects de la programmation temps-réel au sein du système. La robustesse
aux erreurs, le parallélisme de calcul, les fils d’exécution (threads) et le nombre de boucles de
contrôle disponibles par unité de traitement, sont parmi les aspects temps-réel qui influencent
6
grandement les capacités d’un système à interagir convenablement avec l’environnement. Il
faut également bien cerner les sections qui doivent utiliser des notions de temps réel dur
(le respect des contraintes temporelles sont critiques au fonctionnement du système) et de
temps réel mou (le respect des contraintes temporelles sont importantes, mais non critiques).
Généralement, les parties de contrôle bas niveau sont souvent associées au temps réel dur,
alors que les parties reliées à l’aspect de l’intelligence du système sont plutôt associés au
temps réel mou [23].
2.1.3
Organisation structurelle
L’organisation structurelle d’une architecture décisionnelle constitue l’équivalent fonctionnel
d’un squelette et d’un système nerveux : elle dicte comment les différents blocs de traitement de données sont interconnectés et définit également les canaux de communication et
les formats des données qui y circulent. Typiquement, les architectures décisionnelles hybrides sont constituées de trois couches : une couche réactive, une couche délibérative et
une couche médiatrice entre les deux. Bien que cette organisation hiérarchique soit courante,
il existe plusieurs autres architectures décisionnelles hybrides qui organisent ces couches
différemment [2]. Les architectures décisionnelles hybrides courantes intègrent généralement
plusieurs fonctionnalités communes, représentées sous formes de composants, qui s’organisent
différemment dans la structure de chacune des architectures [23] :
– Séquenceur : composant qui actionne et contrôle le séquencement des phases et des
ressources nécessaires à l’accomplissement de tâches.
– Gestionnaire de ressources : composant qui détermine quelles ressources peuvent être
exploitées en fonction de la situation courante.
– Cartographie : composant qui fournit une représentation spatiale de l’environnement
réel en fonction de ce qui est perçu.
– Planificateur de mission : composant qui interprète des objectifs globaux de manière
à les décomposer en sous-tâches à réaliser.
– Surveillance des performances et résolution de problème : composant qui surveille
la progression de l’exécution des tâches et qui peut intervenir en cas de problème.
7
Figure 1 – Architecture décisionnelle hybride 3T
Les interactions entre ces composants et les composants propres à chacune des architectures
constituent essentiellement ce qui supporte la création de l’intelligence d’un système robotique [10]. Plusieurs mécanismes de gestion et de transmission d’information doivent être
utilisés pour créer ces interactions.
Les architectures 3T (3 Tiered ) [5] et TCA (Task Control Architecture) [32] sont deux
exemples d’architectures décisionnelles hybrides souvent rencontrés dans la littérature. Les
figures 1 et 2 montrent respectivement ces deux architectures. L’architecture 3T montre
précisément le cas typique d’une décomposition en trois couches, tandis que l’architecture TCA présente une décomposition dont la couche médiatrice est pratiquement absente.
Dans les deux cas, on retrouve les composants présentés précédemment mais organisés
différemment. Dans le cas de l’architecture 3T, le planificateur et la cartographie constituent
les principaux composants de la couche délibérative, les autres composants sont utilisés dans
la couche médiatrice. Seuls les comportements réactifs (appelés skills) sont utilisés dans la
couche réactive. Pour ce qui est de l’architecture TCA, tous les composants sont utilisés dans
la couche délibérative. Seules les tâches qui doivent être réactives sont laissées à la couche
8
Figure 2 – Architecture décisionnelle hybride TCA
réactive. Au niveau des interactions, l’architecture TCA propose une vision conventionnelle
du traitement de l’information en prenant une approche séquentielle. Le planificateur de
mission établit d’abord quelles sont les tâches à accomplir. Et ensuite, délègue la réalisation
de ces tâches de manière hiérarchique aux différents autres composants, jusqu’à ce qu’il soit
possible de déterminer ce qui doit être appliqué aux actionneurs. L’architecture 3T propose plutôt une vision distribuée du traitement de l’information en exploitant la couche
médiatrice. Ceci permet de laisser les traitements réactifs et délibératifs se faire de manière
indépendante, et de laisser la couche médiatrice interpréter les résultats de ces traitements
pour établir le séquencement et l’organisation des tâches à accomplir. Ce qui est appliqué aux
actionneurs provient ainsi d’une médiation entre les considérations réactives et délibératives
en fonction des tâches à accomplir. Ces deux architectures montrent bien comment la structure organisationnelle peut influencer de manière différente la génération des comportements
des systèmes robotiques.
9
2.2
Exigences de conception logicielle
D’un point de vue logiciel, la conception d’un robot mobile et autonome représente un défi de
taille étant donné la grande quantité d’exigences logicielles souvent conflictuelles entre elles. À
titre d’exemples, citons les exigences suivantes : performance acceptable à l’exécution, facilité
de modification du code source, grande extensibilité et flexibilité logicielle, et rapidité du
cycle de développement logiciel. Il existe plusieurs environnements de développement logiciel,
dont plusieurs sont propriétaires, dédiés à la conception de robots mobiles et autonomes,
qui proposent chacun une solution spécifique selon les exigences considérées (par exemple,
RobotFlow2 , Saphira3 , Orocos4 , Mobility5 et MIRO6 ). Cette multiplication d’environnements
de développement logiciel robotique comporte plusieurs effets indésirables [24] :
– elle limite la portabilité des mises en œuvre faites à partir d’environnements de développement logiciel différents ;
– elle rend difficile l’évaluation des performances des architectures décisionnelles entre elles ;
– elle tend à diviser le domaine par la difficulté de communiquer et d’interpréter les résultats
obtenus.
L’idée de la mise en place d’une plate-forme de développement unifiée, standardisée et bien
documentée semble être une solution possible pour enrayer ces effets [24]. Certains travaux
ont déjà été faits en ce sens. L’intergiciel (middleware) Miro est un exemple d’environnement
de développement logiciel en robotique mobile et autonome qui vise à unifier les environnements de développement logiciel, tout en offrant suffisamment de flexibilité pour ne pas
limiter les développements [34]. Le travail proposé par Orebäck et Christensen [24], quant
à lui, fait une évaluation des environnements de développement logiciel pour la robotique
mobile en général, en regardant spécifiquement les besoins à combler pour arriver à créer
une approche unifiée. Voici une liste des principales exigences logicielles qui ressortent de ces
travaux :
2
Site
Site
4
Site
5
Site
6
Site
3
de
de
de
de
de
référence
référence
référence
référence
référence
du
du
du
du
du
projet
projet
projet
projet
projet
RobotFlow : http ://robotflow.sourceforge.net/
Saphira : http ://www.ai.sri.com/˜konolige/saphira/
Orocos : http ://www.orocos.org/
Mobility : http ://www.irobot.com/rwi/p10.asp
MIRO : http ://smart.informatik.uni-ulm.de/MIRO/content.html
10
– abstraction du matériel et du système d’exploitation ;
– portabilité et interopérabilité multiplateformes ;
– capacité d’extension et de hiérarchisation ;
– modularité et développement orienté-objet ;
– architecture de développement ouverte ;
– utilisation de langages permettant la programmation distribuée (ex. : CORBA) ;
– réutilisabilité accrue ;
– développement d’outils et d’interface-usagers facilitant le développement et l’utilisation à
différent niveaux de compétence (programmeurs, utilisateurs, testeurs, etc.) ;
– utilisation des principes de développement logiciel.
Ces exigences dressent ainsi une autre réalité de la conception robotique mobile et autonome, et viennent s’ajouter aux autres exigences provenant de l’utilisation d’une architecture décisionnelle hybride présentées précédemment. Ces travaux viennent également montrer l’intérêt d’utiliser des outils de conception logicielle pour arriver à bien évaluer et à
concilier toutes ces exigences. L’utilisation de méthodes de conception telles que Booch [6],
ATAM (Architecture Tradeoff Analysis Method ) [35] ou ABAS (Attribute-Based Architectural
Style) [16], permettent généralement de faire ressortir des points critiques dans la conception
(risques, points de sensibilité, compromis, etc.). L’utilisation de standards de programmation et de documentation tels que les patrons de conception [11] et le langage UML (Unified
Modeling Language) [7], sont également des outils pouvant faciliter la documentation architecturale et la communication de l’information. Ces points sont d’ailleurs identifiés comme
étant des points critiques pour l’acceptation à large échelle d’un éventuel environnement de
développement unifié [24].
2.3
Discussion des impacts sur le développement des comportements intelligents
On retrouve la plupart des notions énoncées dans les sections précédentes dans divers domaines de recherche (IA, contrôle de systèmes temps-réel, architecture logicielle, simulation,
11
systèmes distribués, etc.). Ce qui caractérise le domaine de la robotique mobile et autonome,
c’est l’intégration de toutes ces notions dans un tout organisé et fonctionnel, duquel résulte
des comportements intelligents d’un ou plusieurs robots évoluant dans un environnement
réel.
La validation de ces systèmes n’est pas évidente a priori puisque le comportement global du
système se crée par l’interaction simultanée des états internes d’un robot, de ses interactions
avec l’environnement et des interactions de l’environnement sur le robot. Il devient donc difficile de procéder par une approche de validation usuelle en sciences expérimentales (comme
la chimie ou la physique par exemple) qui tentent typiquement d’étudier un phénomène
spécifique en l’isolant et en contrôlant les autres facteurs qui l’influencent [9]. On retrouve
des modèles mathématiques qui arrivent à faire de bonnes prédictions au niveau des agents
informatiques qui se trouvent dans des environnements simplifiés et contrôlés, mais très peu
de modèles mathématiques tentent de prédire comment va se comporter un ou plusieurs
robots pour l’exécution de tâches particulières dans des environnements réels. Les modèles
faits par Lerman et Galstyan [19], même s’ils doivent faire des simplifications majeures, sont
un exemple de modèles mathématiques qui arrivent à faire des prédictions intéressantes
des comportements intelligents sur des groupes de robots homogènes qui exécutent une
tâche de cueillette (foraging). Pour le moment, les chercheurs s’entendent à créer des plateformes robotiques de démonstration, qui servent à évaluer les performances des architectures décisionnelles et des comportements de robots [9]. Des méthodes de mesures indirectes, comme l’observation de comportements externes ou l’observation de paramètres internes, sont couramment utilisées pour la validation et l’évaluation des performances. Un bel
exemple est fourni par Goldberg et Mataric [12], qui ont mis en place une méthodologie pour
l’évaluation des comportements collectifs d’un groupe de robots pour une tâche de cueillette.
Ces approches de validation et d’expérimentation impliquent une méthode de développement
incrémentale. L’ajout de nouveaux comportements ou de nouvelles fonctionnalités doit être
fait régulièrement pour étendre les comportements d’un robot [10]. Un environnement de
développement logiciel respectant les exigences logicielles présentées dans les sections précédentes permet de faire des modifications de façon ponctuelle, sans venir interférer avec tout
12
ce qui est jugé fonctionnel. Elle permet de créer des outils qui pourront faire les modifications
nécessaires aux bons niveaux d’abstraction seulement. Il s’ensuit que l’exécution de chaque
itération peut être faite plus rapidement et de manière plus structurée que pourrait le faire
un logiciel qui ne tiendrait pas compte de ces aspects. Tout ceci a pour conséquence que le
temps passé sur le développement d’une architecture décisonnelle hybride est utilisé plus efficacement pour la validation des concepts et à l’amélioration des comportements intelligents
plutôt que pour le développement des outils qui supportent ces concepts [34].
Une autre implication des approches de validation et d’expérimentation est l’intégration de
fonctionnalités ou de sous-systèmes qui ne sont pas nécessairement compatibles à la base.
La robotique mobile et autonome utilise une panoplie de systèmes pour arriver à ses fins :
vision artificielle, navigation, cartographie, etc. Chacun de ces systèmes sont, pour la plupart,
considérés comme étant des axes de recherche en soit. Il est donc fréquent de devoir emprunter
les travaux faits dans ces axes de recherche pour tenter de les intégrer dans une architecture
de contrôle hybride. Or, le problème d’intégration en est un de taille dans ce contexte, car
les systèmes n’ont pas été nécessairement conçus pour interagir ensemble. Le fait de venir
définir à la base les concepts logiciels qui devraient être respectés, et de spécifier au départ les
interfaces d’interconnexion utilisables entre des entités (systèmes, sous-systèmes ou autres),
vient faciliter le travail d’intégration. C’est un aspect du développement qui, à lui seul,
vient motiver l’idée d’utiliser un environnement de développement logiciel unifié entre les
différents laboratoires de recherche. L’approche de développement incrémental verrait ainsi
la possibilité d’évaluer plus facilement l’utilité des différents concepts utilisés pour résoudre
un problème (vision, navigation ou autres).
Un autre avantage en faveur d’une utilisation d’un environnement de développement logiciel commun entre les différents laboratoires de recherche est d’améliorer les capacités des
chercheurs à pouvoir comparer les résultats obtenus, et de partager les mises en œuvre.
Présentement, chacune des variations des architectures décisionnelles hybrides tentent de
démontrer qu’elles sont optimales par rapport à l’exécution d’une tâche particulière ou pour
une mise en situation donnée. Étant donné la forte variabilité entre les mises en œuvre, il
est ardu d’évaluer les avantages et inconvénients d’une architecture par rapport à une autre,
13
et de déterminer précisément les limites de chacune. L’utilisation d’une architecture unifiée
viendrait donc imposer une standardisation de la plate-forme logicielle, et par le fait même
rendre les résultats obtenus plus cohérents entre eux. Ceci permettrait notamment d’arriver à établir des bases de comparaison significatives pour l’évaluation des comportements
intelligents.
3
14
DÉFINITION ET OBJECTIF DU PROJET
Malgré le développement de plusieurs architectures décisionnelles dans le domaine de la robotique mobile et autonome depuis les années 1990, peu de travaux de recherche se sont
attardés sur le problème de la comparaison des attributs de performance et de qualité de ces
architectures. Plusieurs travaux font ressortir les avantages et inconvénients qu’ont les architectures décisionnelles les unes par rapport aux autres, mais peu de travaux proposent une
comparaison des attributs de performance et de qualité proprement dits. Une des difficultés
principales est que les mises en œuvre actuelles des systèmes robotiques sont suffisamment
différentes les unes des autres qu’elles rendent difficile l’établissement d’une base de comparaison homogène. Voici quelques facteurs principaux qui expliquent ces grandes différences
de mises en œuvre :
– la nature différente des paradigmes qui sous-tendent les trois grandes classes d’architectures
décisionnelles ;
– l’utilisation de mécanismes décisionnels propres à certaines architectures décisionnelles ;
– l’incidence majeure qu’ont les architectures décisionnelles sur la mise en œuvre globale de
systèmes robotiques ;
– l’utilisation de différents environnements de développement logiciel pour réaliser les mises
en œuvre de systèmes robotiques ;
– la grande variété de mise en œuvres utilisées pour valider les différents systèmes robotiques.
L’objectif du projet de recherche est de développer une méthodologie de comparaison d’architectures décisionnelles hybrides, en se servant d’un environnement de développement logiciel
unifié afin de créer une base de comparaison homogène entre les mises en œuvre des architectures. Pour créer cette base de comparaison homogène, ce projet propose également d’introduire la notion de capacité de systèmes robotiques car elle permet, malgré les différences
inhérentes et non-négligeables entre les mises en œuvre des architectures, d’évaluer la similarité des aptitudes par les systèmes robotiques réalisés pour l’exécution de mêmes tâches.
15
Telle qu’utilisée en psychologie, “une capacité représente la possibilité de réussite dans
l’exécution d’une tâche, ou l’exercice d’une profession.”
7
Dans le contexte de la robotique
mobile et autonome, les capacités d’un système robotique représentent les aptitudes que
possède un système robotique à accomplir certaines tâches dans des environnements réels.
En utilisant la notion de capacités de systèmes robotiques, l’hypothèse suivante est posée
pour établir une base de comparaison homogène : pour deux mises en œuvre de systèmes robotiques similaires produisant des comportements physiques reproductibles équivalents lors
de l’exécution d’une même tâche dans des conditions environnementales similaires, il est possible de considérer que chacune des mises en œuvre réalise des capacités équivalentes. Cette
hypothèse s’inspire du test de Turing [33], qui utilise une supposition similaire pour établir
une base de comparaison entre l’intelligence humaine et l’intelligence d’une machine. Les
capacités d’un système robotique étant issues principalement de l’architecture décisionnelle
utilisée, à partir de cette hypothèse, il devient possible de comparer des architectures décisionnelles pour deux systèmes robotiques qui réalisent des capacités équivalentes. En couplant
l’utilisation de la notion de capacité d’un système robotique à l’utilisation d’un environnement de développement logiciel unifié, l’incidence des facteurs limitant l’établissement d’une
base de comparaison homogène est diminuée. C’est ce qui permet de comparer des mises en
œuvre qui restent, malgré tout, différentes.
7
Référence : Office québécois de la langue française (http ://www.granddictionnaire.com)
4 MÉTHODOLOGIE
4
16
MÉTHODOLOGIE
Il est à noter que ce projet de recherche est fait en collaboration avec l’équipe du projet
“AAAI Challenge” qui réalise une mise en œuvre d’un système robotique conçu à partir de
l’architecture décisionnelle EMIB. La mise en œuvre de ce système robotique est développée
conjointement et utilisée par les deux projets. Il serait également possible de joindre l’équipe
du projet “AAAI Challenge” lors de sa participation au “AAAI Robot Challenge” en 2004.
4.1
Description de la méthodologie
Cette section décrit de manière plus détaillée la méthodologie employée pour la mise en
œuvre associée à ce projet de recherche.
1. Choisir les architectures décisionnelles à comparer.
EMIB [22] et 3T [5].
2. Choisir l’application à réaliser.
Les tâches que doivent accomplir les systèmes robotiques doivent être suffisamment complexes pour exploiter l’utilisation des mécanismes de chacune des architectures décisionnelles,
afin de faire ressortir les différences de performance entre ces architectures. Pour ce projet
de recherche, les tâches à accomplir sont celles définies par le “AAAI Robot Challenge”. Le
but global fixé par ce challenge est de concevoir un robot mobile et autonome qui assiste à
une conférence sur l’intelligence artificielle en se comportant comme un conférencier8 . Sept
sous-tâches sont identifiées pour réussir le challenge :
1. Débuter le challenge à l’entrée principale du lieu où se tient la conférence, sans assistance et sans connaissance a priori des lieux.
2. Naviguer jusqu’au bureau d’enregistrement.
3. S’enregistrer (ce qui inclut d’attendre en ligne, de s’identifier, de recevoir le matériel
d’enregistrement, de recevoir une carte du lieu où se tient la conférence, de se faire
8
Description de l’événement 2003 : http ://www.andrew.cmu.edu/˜astroupe/AAAI03/
4 MÉTHODOLOGIE
17
assigner la salle et le moment de la présentation à effectuer).
4. Interagir avec les autres participants à la conférence.
5. Se rendre à temps à la salle assignée pour la présentation, en prenant l’ascenseur au
besoin.
6. Exécuter des services sur demande si le temps le permet.
7. Faire une présentation de deux minutes sur sa propre technologie et répondre aux
questions.
Ces sous-tâches peuvent être accomplies à différents niveaux de difficultés, de très simplifiés
à très complexes. Les fonctionnalités des systèmes robotiques prévues par l’équipe du “AAAI
Challenge” qui serviront à réaliser ces sous-tâches, incluent actuellement les fonctionnalités
suivantes :
– navigation métrique ;
– lecture de mots ;
– interactions humain-robot ;
– exposé oral ;
– planification élaborée ;
– suivre une file d’attente ;
– prendre l’ascenseur ;
– détection de personnes ;
– reconnaissance de visages ;
– suivre une personne ;
– recharge autonome ;
– lecture de badges ;
– compréhension d’une carte.
Dans le contexte du présent projet, plusieurs de ces fonctionnalités peuvent potentiellement
servir à évaluer les architectures décisionnelles, sans devoir réaliser directement les soustâches en tant que telles. Les fonctionnalités suivantes seraient suffisamment complexes pour
exploiter les mécanismes des architectures décisionnelles :
4 MÉTHODOLOGIE
18
– navigation métrique ;
– interactions humain-robot ;
– prendre l’ascenseur ;
– suivre une file d’attente ;
– suivre une personne ;
– recharge autonome.
Les descriptions et le niveau de difficulté des tâches et/ou des fonctionnalités sélectionnées
pour ce projet de recherche dépendront des contraintes de développement établies par l’équipe
du projet “AAAI Challenge”. Le nombre de tâches et/ou fonctionnalités sélectionnées variera aussi en fonction de ce que le système robotique réalisé sera en mesure d’accomplir au
moment où la sélection des tâches pour ce projet de recherche devra être faite.
3. Choisir les attributs de performance et de qualité d’architectures décisionnelles
à mesurer et à tester.
Étant donné que les tâches spécifiques ne sont pas encore déterminées à ce moment-ci (voir
l’étape 2), les listes suivantes constituent une suggestion réaliste des attributs qui pourraient
être sélectionnés.
Les attributs de qualité logiciels choisis sont :
– la modularité ;
– la portabilité ;
– la quantité de ligne de codes ;
– la complexité du code ;
– le nombre d’éléments requis en terme de composants et de classes ;
– la réutilisabilité ;
– l’extensibilité.
Les attributs de performance d’exécution internes choisis sont :
– la charge de calculs de l’unité de calcul principale ;
– la densité de flux de données aux entrées/sorties des composants ;
4 MÉTHODOLOGIE
19
– la quantité de données transférées entre les composants ;
– la quantité de mémoire requise à l’initialisation et lors de l’exécution.
Les attributs de performance d’exécution externes choisis sont :
– le temps pris pour exécuter une tâche ;
– l’évaluation qualitative de la réussite globale de l’accomplissement d’une tâche.
4. Implémenter les systèmes robotiques en respectant la notion de “systèmes
robotiques similaires”.
Afin de créer des systèmes robotiques similaires, les mises en œuvre doivent tenter d’uniformiser au maximum les éléments suivants :
Architecture matérielle. Une même architecture matérielle est exploitée pour les deux
mises en œuvre des systèmes robotiques en utilisant la même plate-forme robotique.
De cette manière, les mêmes capacités sensorielles et les mêmes capacités de calculs
seront disponibles pour chacune des mises en œuvre. Dans le cas présent, un seul robot
servira pour chacune des mises en œuvre ce qui limitera les différences matérielles qui
peuvent subsister entre deux plate-formes robotiques identiques. À noter que le choix
de la plate-forme robotique utilisée se fera par l’équipe du projet ”AAAI Challenge”.
Actuellement, deux plate-formes robotiques sont envisagées : Pioneer ou U2S.
Architectures logicielles. L’architecture logicielle est nécessairement différente pour chacune des mises en œuvre puisqu’elle dépend directement de l’architecture décisionnelle
utilisée. Toutefois, une uniformisation est tout de même possible en utilisant un même
environnement de développement logiciel et les mêmes outils logiciels dans les deux
mises en œuvre. Dans le cadre de ce projet de recherche, MARIE9 (pour Mobile and Autonomous Robotics Integration Environnement), un environnement de développement
logiciel, est développé afin d’être utilisé pour chacune des mises en œuvre. Cet environnement de développement logiciel vise essentiellement à répondre aux difficultés
rencontrées lors de l’intégration des différents composants logiciels requis par les mises
9
Site de référence du projet MARIE : http ://sourceforge.net/projects/marie/
4 MÉTHODOLOGIE
20
en œuvre des architectures décisionnelles hybrides. Étant donné que plusieurs des composants à intégrer sont des applications développées par des entités externes au présent
projet (universités, compagnies, communautés open-source, etc.), MARIE propose une
approche de programmation distribuée basée sur CORBA (en utilisant entre autres
les projets ACE10 et TAO11 ). De cette façon, un système robotique développé à l’aide
de MARIE intégrera les différents composants en créant un système de gestion et
de communication entre ces composants indépendants, plutôt qu’en tentant de créer
une seule application qui “fusionne” ces composants entre eux (ce qui n’est pas toujours possible puisqu’ils ne sont pas nécessairement compatibles). De plus, MARIE vise
également de permettre le support d’exigences logicielles identifiées dans la section 2
(par exemple, abstraction du matériel et du système d’exploitation, extensibilité, modularité et hiérarchisation) par la réalisation d’outils et de documentations qui favorisent
le développement en ce sens. Afin d’éviter tout biais possible, MARIE n’est pas dédié
à la mise en œuvre d’architectures décisionnelles en particulier. Seuls des mécanismes
généraux de gestion de flux de données, de gestion de processus et d’intégration d’outils
logiciels sont offerts.
Tel que mentionné auparavant, le système robotique réalisé à partir de l’architecture décisionnelle EMIB est réalisé par l’équipe du projet “AAAI Challenge”. Toutes les tâches et
les fonctionnalités qui seront développées pour ce système robotique seront portées sur le
système robotique réalisé à partir de l’architecture décisionnelle 3T.
La validation du bon fonctionnement des mises en œuvre des systèmes robotiques se fait en
environnement simulé, à l’aide des logiciels Player/Stage, et en environnement réel sur la
plate-forme robotique sélectionnée.
5. Créer les environnements de test qui respectent la notion de “conditions environnementales similaires”.
Les conditions environnementales sont considérées comme étant tous les éléments qui interagissent et modifient les conditions dans lesquelles évolue un système robotique, que ce
10
11
Site de référence du projet ACE : http ://www.cs.wustl.edu/˜schmidt/ACE.html
Site de référence du projet TAO : http ://www.cs.wustl.edu/˜schmidt/TAO.html
4 MÉTHODOLOGIE
21
soit externe (par exemple, l’éclairage, les obstacles fixes ou mobiles et les conditions climatiques) ou interne au système robotique (par exemple, l’état des composants mécaniques et
électroniques, l’état initial de la charge des batteries et l’état initial de la mémoire). Les
critères qui déterminent si les conditions environnementales sont similaires durant l’accomplissement d’une même tâche par deux systèmes robotiques différents sont à déterminer en
fonction du contexte et de la nature de la tâche.
Typiquement, une expérience devrait avoir lieu dans des conditions environnementales identiques (par exemple, reproduire le passage d’un individu à un endroit précis à un moment
donné, position initiale identique, états internes identiques, etc.). Le contexte global de la
robotique mobile et autonome exige par contre une robustesse minimale aux changements
qui surviennent dans l’environnement. Pour éviter une trop grande fluctuation des comportements lors de l’accomplissement d’une même tâche décalée dans le temps (et de potentiellement ne plus être en mesure de respecter la notion de “comportements physiques reproductibles équivalents”), les éléments qui interagissent et modifient les conditions dans lequel
évolue un système robotique doivent être minimisés sans nécessairement être complètement
éliminés. Chaque tâche devra donc être analysée afin de déterminer le degré et le type de
variation de l’environnement acceptable afin de ne pas trop influencer l’exécution d’une tâche.
Par exemple, si la tâche à accomplir est de naviguer d’un point A à un point B dans un
endroit qui est potentiellement fréquenté par plusieurs personnes lors de l’exécution, il serait
acceptable de produire des passages aléatoires pour démontrer une certaine robustesse aux
variations dans un environnement réel. Par contre, si les passages aléatoires provoquent des
différences notables dans l’exécution de la tâche (par exemple, échecs ou réussites variables)
ou des comportements erratiques entre chacune des exécutions (par exemple, le robot prend
beaucoup plus de temps à réaliser la tâche), il serait tout aussi acceptable de choisir de
reproduire des passages fixes (à des temps et à des endroits fixes), ou à la limite de choisir de
ne pas admettre ce type de variation lors des expérimentations. Ce qui importe dans le présent
contexte est plutôt de s’assurer que la nature de la tâche exploite suffisamment tous les
mécanismes de l’architecture décisionnelle à évaluer et que les résultats des expérimentations
soient suffisamment significatifs pour être comparés entre eux.
4 MÉTHODOLOGIE
22
Les environnements de tests qui serviront dans le cadre de ce projet de recherche sont les
espaces de test du laboratoire de recherche Laborius, ainsi que les corridors et les locaux
avoisinants le laboratoire.
Note : Une description précise de ce qui est entendu par “conditions environnementales similaires” devra être fournie pour chacune des tâches à accomplir lorsqu’elles seront déterminées.
6. Valider que les systèmes respectent la notion de “comportements physiques
reproductibles équivalents” pour l’exécution de chacune des tâches à accomplir.
Les comportements physiques sont considérés comme étant tous les comportements observables par un expérimentateur lors de l’exécution d’une tâche par un système robotique. Pour
que les comportements physiques soient considérés reproductibles, un expérimentateur doit
évaluer par observations si un système robotique produit sensiblement toujours les mêmes
comportements pour l’exécution d’une tâche dans les mêmes conditions environnementales.
Si les comportements physiques produits par un système robotique sont trop erratiques selon
les observations d’un expérimentateur, ils ne peuvent être considérés comme étant reproductibles. De même, pour que des comportements physiques de deux systèmes différents soient
considérés équivalents, un expérimentateur doit évaluer par observations si les deux systèmes
accomplissent une tâche sensiblement de la même manière. Les critères qui déterminent si
l’accomplissement d’une tâche est fait sensiblement de la même manière sont à déterminer en
fonction du contexte et de la nature de la tâche (par exemple, le temps pris pour accomplir
la tâche et le nombre de mauvaises décisions prises par un système robotique pour accomplir
une tâche).
Dans le cadre de ce projet de recherche, plusieurs tâches sont candidates (voir la description des tâches à l’étape 2). La sélection de seulement quelques tâches est nécessaire pour
réaliser la comparaison entre les architectures décisionnelles. Les tâches accomplies par les
systèmes robotiques qui rencontrent le mieux la notion de “comportements physiques reproductibles équivalents” seront vraisemblablement les tâches sélectionnées. Des optimisations
et des ajustements pourront être faits sur la mise en œuvre de chacun des systèmes robotiques
afin de rencontrer au mieux les critères de sélection. Des changements peuvent également
être apportés sur la nature des tâches à accomplir.
4 MÉTHODOLOGIE
23
Par exemple, si la tâche à accomplir est de naviguer d’un point A à un point B dans un
endroit qui est potentiellement fréquenté par plusieurs personnes lors de l’exécution, les
deux systèmes robotiques devraient être en mesure de réussir la plupart du temps la tâche
de manière équivalente (par exemple, réussir dans plus de 90% des cas). L’équivalence des
comportements dans ce cas pourrait être évaluée par les éléments suivants : l’exécution de
la tâche dans un laps de temps similaire et le suivis d’une trajectoire relativement optimale
en fonction des obstacles rencontrés. Dans le cas où ces critères ne seraient pas respectés, il
serait possible d’envisager de diminuer le coefficient de difficulté de la tâche, pour autant que
la nature de la tâche résultante exploite suffisamment tous les mécanismes de l’architecture
décisionnelle à évaluer, et que les capacités observées pour réaliser la tâche soient de même
nature. Dans le cas présent, les obstacles aléatoires pourraient être remplacés par des obstacles fixes, certains obstacles fixes pourraient être déplacés pour faciliter le trajet à suivre,
des optimisation logicielles pourraient être faites pour gérer des cas particuliers qui posent
problème, etc.
Note. Une description précise de ce qui est entendu par “comportements physiques reproductibles équivalents” devra être fournie pour chacune des tâches à accomplir lorsqu’elles
seront déterminées.
7. Mesurer et tester les attributs de performance d’architectures décisionnelles
choisies pour chacun des systèmes robotiques à comparer et pour chacune des
tâches qu’ils doivent accomplir.
Les mesures d’attributs de qualité logiciels sont faits à une seule reprise, au moment où la mise
en œuvre de chacun des systèmes robotiques est considérée finale. Les mesures d’attributs
de performances internes et externes doivent être répétés un nombre de fois “statistiquement significatif” en fonction de la tâche à accomplir. Malheureusement, les références sur
les méthodologies de mesures de performance en robotique mobile et autonome sont peu
nombreuses. Les travaux présentés par le groupe de travail Performance Metrics for Intelligent Systems (PerMIS)
12
12
montrent bien les difficultés que posent la mise en œuvre de
Site de référence du groupe de travail PerMIS :
http ://www.isd.mel.nist.gov/research areas/research engineering/Performance Metrics/
4 MÉTHODOLOGIE
24
méthodologie de mesures de performance pour des systèmes intelligents.
Étant donné que l’étude de ce sujet précis dépasse le cadre de ce projet de recherche, la
méthodologie de mesure de performance utilisée se basera uniquement sur l’aspect de reproductibilité des expériences. Pour que les résultats soit “statistiquement significatifs”, il suffit
de répondre au critère de reproductibilité énoncés au point 6 de la présente méthodologie. Si
une expérience produit des “comportements physiques reproductibles équivalents” lorsque
répétée une dizaine de fois consécutives, elle sera admissible pour être utilisée pour les mesures de performances. Le nombre de répétition des expériences pour chacune des tâches à
accomplir pourra varier d’une tâche à l’autre. Certaines tâches sont “délicates” à reproduire
un grand nombre de fois tout en respectant soit les “conditions environnementales similaires”, soit les “comportements physiques équivalents”. Les causes peuvent être multiples :
difficulté de conserver les conditions environnementales stables pour une longue période de
temps, difficulté de remettre le robot dans un état initial identique d’une expérience à l’autre,
trop grande variation entre les expérimentations faites avec chacun des systèmes robotiques,
etc. Dans de telles situations, le nombre de répétition des tests pourrait être revu à la baisse.
Ce qui importe c’est la stabilité d’exécution d’une tâche pour que les mesures soient comparables.
Note. Une description précise de ce qui est entendu par ”statistiquement significatif” devra
être fournie pour chacune des tâches à accomplir lorsqu’elles seront déterminées.
8. Analyser les données recueillies.
L’analyse des données se fera principalement à l’aide des outils statistiques du logiciel Matlab.
La présentation des résultats se fera principalement sous forme de tableaux et de figures. Les
vidéos des expérimentations serviront également comme support d’analyse et de présentation
des résultats pour les observations et les évaluations qualitatives.
4.2
Discussion
La méthodologie proposée laisse soin à l’expérimentateur de définir au mieux les notions
qui établissent le contexte d’expérimentation. C’est ce qui permet de contrôler et d’intégrer
4 MÉTHODOLOGIE
25
les principaux facteurs qui limitent la création d’une base de comparaison homogène entre
les différentes mises en œuvre de systèmes robotiques. Cette approche permet d’envisager
l’utilisation de cette méthodologie pour réaliser des études de cas qui décrivent différents
contextes d’expérimentation. Ces études de cas peuvent ainsi servir de références pour réaliser
d’autres expérimentations basées sur cette méthodologie.
Dans le contexte d’expérimentation présenté dans ce projet de recherche, l’utilisation d’un
environnement de développement logiciel unifié joue deux rôles importants. Un premier rôle
est celui de limiter l’impact des facteurs créant les différences entre les mises en œuvre (voir la
section 3). En exploitant les mêmes outils et les mêmes procédés d’intégration pour chacune
de ces mises en œuvre, celles-ci présentent potentiellement moins de différences que pour des
mises en œuvre développées à l’aide d’environnements de développement différents. L’environnement de développement ayant un impact sur le développement des comportements
intelligents d’un système robotique (voir la section 2.3), il devient un élément important à
contrôler entre différentes mises en œuvre. Au même titre que la validation des capacités des
systèmes robotiques pour une même application, ceci a pour but de faciliter la création d’une
base de comparaison significative au niveau des architectures décisionnelles qui sous-tendent
chacun de ces systèmes robotiques.
Le deuxième rôle joué par l’utilisation d’un environnement de développement logiciel unifié
est celui de pouvoir répondre au problème que pose la grande quantité d’exigences logicielles
présentes lors du développement logiciel d’un système robotique (voir la section 2.2). Le
projet MARIE est encore à un stade préliminaire ce qui permet difficilement d’identifier
spécifiquement quels sont les éléments qui permettent de répondre à l’une ou l’autre des
exigences comme telles. Par contre, ce projet est développé principalement pour supporter
le présent projet de recherche, et a donc comme objectif de proposer une structure et des
outils qui favorisent la conciliation de ces exigences.
En somme, deux facettes de la mise en œuvre de systèmes robotiques sont visées dans le
cadre de ce projet de recherche : la création d’une base de comparaison homogène entre
différentes mises en œuvre de systèmes robotiques basés sur des architectures décisionnelles
hybrides différentes et le développement unifié de ces systèmes robotiques. Les deux facettes
4 MÉTHODOLOGIE
26
sont traitées conjointement étant donné l’influence directe qu’a l’une sur l’autre, c’est-àdire l’influence directe qu’a le développement unifié sur la possibilité d’établir une base de
comparaison homogène entre des systèmes robotiques qui restent essentiellement différents.
4.3
Échéancier
Cette section présente les différentes étapes à franchir et les sous-projets à réaliser pour la
complétion du projet. Un estimé du temps accordé pour chacune des étapes est également
inclus.
4.3.1
Mise à niveau dans le domaine de la robotique mobile et autonome
Familiarisation avec l’état de l’art du domaine de la robotique mobile et autonome (9 mois,
de janvier 2003 à septembre 2003 inclusivement) :
– Familiarisation générale avec l’état de l’art du domaine (8 mois, de janvier à août 2003
inclusivement) ;
– Familiarisation avec les architectures décisionnelles existantes (8 mois, de janvier 2003 à
août 2003 inclusivement) ;
– Familiarisation avec les environnements de développement logiciel existants et celui utilisé
à Laborius (6 mois, de janvier 2003 à juin 2003 inclusivement) ;
– Étude des architectures décisionnelles EMIB et 3T (1 mois, septembre 2003).
4.3.2
Environnement de développement logiciel unifié
Développement de l’environnement de développement logiciel unifié qui servira à la mise en
œuvre des systèmes robotiques de ce projet. À noter que ce travail est fait en collaboration
avec l’équipe du projet “MARIE” (8 mois, de juin 2003 à janvier 2004 inclusivement) :
– Exploration de différentes solutions potentielles (3 mois, de juin à août 2003) ;
– Conception des mécanismes de communication, de gestion du système et d’intégration
d’outils logiciels (1 mois, septembre 2003) ;
– Implémentation des mécanismes de communication, de gestion du système et d’intégration
d’outils logiciels (1 mois, octobre 2003) ;
4 MÉTHODOLOGIE
27
– Conception des outils servant au déploiement d’architectures décisionnelles (1 mois, octobre 2003) ;
– Implémentation des outils logiciels servant au déploiement d’architectures décisionnelles
(2 mois, novembre et décembre 2003) ;
– Validation de l’environnement de développement logiciel en environnement simulé et en
environnement réel (3 mois, novembre 2003 à janvier 2004 inclusivement).
4.3.3
EMIB, Phase I
L’objectif de ce sous-projet est d’implémenter une version préliminaire fonctionnelle du
système robotique basé sur l’architecture décisionnelle EMIB. Cette version comprend les
mécanismes principaux de l’architecture décisionnelle ainsi que quelques fonctionnalités du
système robotique complet. À noter que ce travail est fait en collaboration avec l’équipe
du projet “AAAI Challenge” et que c’est cette dernière qui détermine les mécanismes
décisionnels et les fonctionnalités implémentées pour cette portion du projet (18 semaines,
de septembre 2003 à la mi-janvier 2004) :
– Conception du système robotique préliminaire (2 mois, septembre et octobre 2003) ;
– Implémentation de quelques fonctionnalités du système complet (4 mois, de septembre à
décembre 2003 inclusivement) ;
– Implémentation des mécanismes décisionnels associés à EMIB pour le système préliminaire
(2 mois, de novembre à décembre 2003) ;
– Intégration des fonctionnalités avec les mécanismes décisionnels d’EMIB (6 semaines, du
début décembre 2003 à la mi-janvier 2004).
4.3.4
EMIB, Phase II
L’objectif de ce sous-projet est d’implémenter une version complète du système robotique
basé sur l’architecture EMIB. Cette version comprend tous les mécanismes de l’architecture
décisionnelle ainsi que les fonctionnalités du système complet (6 mois, de janvier à juillet
4 MÉTHODOLOGIE
28
2004 inclusivement) :
– Conception du système robotique complet (1 mois, janvier 2004) ;
– Implémentations des fonctionnalités du système complet (15 semaines, de mi-janvier à la
fin avril 2004 inclusivement) ;
– Implémentation des mécanismes décisionnels associés à EMIB pour le système complet (2
mois, février et mars 2004) ;
– Intégration des fonctionnalités avec les mécanismes d’EMIB (6 semaines, de mi-avril à la
fin mai 2004 inclusivement) ;
– Optimisations et ajustements (2 mois, mai et juin 2004) ;
– Validation du système robotique complet en environnement simulé et en environnement
réel (6 semaines, début juin jusqu’au “AAAI Robot Challenge 2004” tenu à la fin juillet
2004).
4.3.5
3T
L’objectif de ce sous-projet est d’implémenter une version complète du système robotique
basé sur l’architecture décisionnelle 3T. Cette version comprend tous les mécanismes de
l’architecture décisionnelle ainsi que les fonctionnalités du système complet. À noter que
plusieurs fonctionnalités implémentées dans ce projet sont les mêmes fonctionnalités que
celles retrouvées dans l’implémentation basée sur EMIB, mais adaptées aux mécanismes de
3T. (6 mois, de janvier à juillet 2004 inclusivement) :
– Conception du système robotique complet (6 semaines, de début janvier à la mi-février
2004) ;
– Implémentation des fonctionnalités du système complet et porter les fonctionnalités implémentées dans EMIB phase II pour 3T (2 mois, de la mi-février à la mi-avril 2004) ;
– Implémentation des mécanismes de décisionnels associés à 3T pour le système complet (2
mois, de la mi-février à la mi-avril 2004) ;
– Intégration des fonctionnalités avec les mécanismes de 3T (6 semaines, de mi-avril à la fin
mai 2004) ;
4 MÉTHODOLOGIE
29
– Optimisations et ajustements (2 mois, mai et juin 2004) ;
– Validation du système robotique complet en environnement simulé et en environnement
réel (6 semaines, de début juin à la mi-juillet 2004).
4.3.6
Tests et analyse des données
Cette section présente les étapes nécessaires pour exécuter les tests présentés précédemment,
faire l’analyse des résultats et conclure sur les résultats de ces tests :
– Développement des outils de tests et d’analyses (10 semaines, de début mai à la mi-juillet
2004) ;
– Sélection des tâches et fonctionnalités qui serviront aux tests (1 mois, juin 2004) ;
– Optimisations et ajustements (2 mois, juin et juillet 2004) ;
– Exécution des tests et cueillette des données (2 mois, juillet et août 2004) ;
– Analyse des résultats et conclusions (2 mois, août et septembre 2004).
4.3.7
Rédaction du mémoire
Rédaction et correction du mémoire (4 mois, de septembre à décembre 2004).
BIBLIOGRAPHIE
30
BIBLIOGRAPHIE
[1] R.C. Arkin. Motor schema-based mobile robot navigation. International Journal of Robotics Research, 8(4) :92–112, 1989.
[2] R.C. Arkin. Behavior-Based Robotics. Intelligent Robots and Autonomous Agents. MIT
Press, Cambridge, Mass., 1998.
[3] R.C. Arkin et D. MacKenzie. Planning to behave : A hybrid deliberative/reactive control
architecture for mobile manipulation. Dans Proceedings of International Symposium
on Robotics and Manufacturing, pages 5–12, Maui, Hawaii, 1994.
[4] R.C. Arkin et D. MacKenzie. Temporal coordination of perceptual algorithms for mobile
robot navigation. IEEE Transactions on Robotics and Automation, 3(10) :276–286,
1994.
[5] R.P. Bonasso, R. J. Firby, E. Gat, D. Kortenkamp, D. Miller, et M. Slack. Experiences
with an architecture for intelligent, reactive agents. J. Expt. Theor. Artif. Intell.,
9(2-3) :237–256, 1997.
[6] G. Booch. Object Oriented Analysis and Design with Applications. Benjamin /Cummings Publishing Company, Inc., 1994.
[7] G. Booch, J. Rumbaugh, et I. Jackobson. UML : A Unified Modeling Language. 1997.
[8] R.A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of
Robotics and Automation, 2(1) :14–23, 1986.
[9] R.A. Brooks. New approches to robotics. Science, (253) :1227–1232, 1991.
[10] E. Coste-Maniere et R. Simmons. Architecture, the backbone of robotic systems. Dans
Proceedings of the IEEE Conference on Robotics and Automation, San Franciso CA,
2000.
[11] E. Gamma, R. Helm, R. Johnson, et J. Vlissides. Design Patterns : Elements of Reusable
Object-Oriented Software. Addison-Wesley, 1994.
[12] D. Goldberg et M.J. Mataric. Design and Evaluation of Robust Behavior-Based Controllers for Distributed Multi-Robot Collection Tasks. T. Balch and L. E. Parker, editors,
2002.
[13] J. Hoff et G. Bekey. An architecture for behavior coordination learning. Dans IEEE
International Conference on Neural Networks, Perth, Australia, 1995.
[14] M. Humphrys. Action selection methods using Reinforcement Learning. PhD thesis,
Computer Laboratory, Cambridge University, Cambridge, UK, 1996.
[15] O. Khatib. Real-time obstacle avoidance for manipulators and mobile robots. Journal
of Robotic Research, 5 :90–98, 1986.
[16] M. Klein, R. Kazman, L. Bass, J. Carriere, M. Barbacci, et H. Lipson. Attribute-based
architecture styles. Dans Software Architecture, Proceedings of the First Working
IFIP Conference on Software Architecture (WICSA1), pages 225–243. Kluwer Academic Publishers, 1999.
[17] J. Kosecka et R. Bajcsy. Discrete event systems for autonomous mobile agents. Dans
Proceedings Intelligent Robotic Systems ’93, pages 21–31, Zakopane, Poland, 1993.
[18] S. Kristensen. Sensor Planning with Beyesian Decision Analysis. PhD thesis, Department of Medical Informatics and Image Analysis, Aalborg University, Aalborg, Denmark, 1996.
BIBLIOGRAPHIE
31
[19] K. Lerman et A. Galstyan. Mathematical model of foraging in a group of robots : Effect
of interference. Autonomous Robots, 13(2) :127–141, 2002.
[20] L.-J. Lin. Scaling-up reinforcement learning for robot control. Dans Proceedings of the
Tenth International Conference on Machine Learning, pages 182–189, Amherst, MA,
1993.
[21] P. Maes. Situated agents can have goals. Dans Patti Maes, editeur, Designing Autonomous Agents, Cambridge, Massachusetts, London, England, 1990. MIT Press.
[22] F. Michaud. EMIB - Computational architecture based on emotion and motivation
for intentional selection and configuration of behavior-producing modules. Cognitive
Science Quartely, 2(3-4) :340–361, 2002.
[23] R.R. Murphy. An Introduction to AI Robotics. Intelligent Robotics and Autonomous
Agents Series. MIT Press, 1ière edition, 2000.
[24] A Orebäck et H.I. Christensen. Evaluation of architectures for mobile robotics. Autonomous Robots, 14(1) :33–49, 2003.
[25] R. Pfeifer et C. Scheier. Understanding Intelligence. MIT Press, Cambridge, MA, 1999.
[26] P. Pirjanian. Multiple objective action selection in behavior-based control. Dans Proceedings of the 6th Symposium for Intelligent Robotic Systems, pages 83–92, Edinburgh,
Scotland, 1998.
[27] P. Pirjanian. Behavior coordination mechanisms – state-of-the-art. Technical Report
IRIS-99-375, Institute for Robotics and Intelligent Systems, University of Southern
California, 1999.
[28] J. Riekki et J. Röning. Reactive task execution by combining action maps. Dans
IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS’97),
pages 224–230, Grenoble, France, 1997.
[29] J.K. Rosenblatt. DAMN : A distributed architecture for mobile navigation. Dans Proc.
of the AAAI Spring Symp. on Lessons Learned from Implememted Software Architectures for Physical Agents, Stanford, CA, 1995.
[30] A. Saffiotti, K. Konolige, et E. H. Ruspini. A multivalued-logic approach to integrating
planning and control. Artificial Intelligence, 76(1-2) :481–526, 1995.
[31] G. Schoner et M. Dose. A dynamics systems approach to task level systems integration
used to plan and control autonomous vehicle motion. Robotics and Autonomous
Systems, 10 :253–267, 1992.
[32] R. Simmons. Structured control for autonomous robots. IEEE Transactions on Robotics
and Automation, 10(1) :34–43, 1994.
[33] A.M. Turing. Computing machinery and intelligence. Mind, 59(236) :433–460, 1950.
[34] H. Utz, S. Sablatnog, S. Enderle, et G. Kraetzschmar. Miro - middleware for mobile
robot applications. IEEE Transactions on Robotics and Automation, 18(4) :493–497,
2002.
[35] S. Woods et M. Barbacci. Architectural evaluation of collaborative agent-based systems.
Technical Report CMU/SEI-99-TR-025, Software Engineering Institute, Carnegie
Mellon University, 1999.
[36] J. Yen et N. Pfluger. A fuzzy logic based extension to Payton and Rosenblatt’s command
fusion method for mobile robot navigation. IEEE Trans. on Systems, Man, and
Cybernetics, 25(6) :971–978, 1995.

Méthodologie de comparaison d`architectures

Transcription

Documents pareils

Devoir de vacances

Qu`est-ce que programmer une interface adaptative ? Le cas du

Docteur en informatique Ingénieur Télécom ParisTech

MVA101 - Corrigé du devoir n 6

Dr. Hassan Chaib c/o Librairie Al-Imam Malik, Hay Rabha

Systèmes à deux équations et trois inconnues

Voir mon CV au format PDF.

Gestion de configuration

Fiche syst`eme d`assainissement 2014 St

exercice 1 exercice 2