Dans ce chapitre nous avons abordé en profondeur la problématique des simulateurs. Nous avons commencé par présenter des arguments pour expliquer en quoi un simulateur est utile pour le domaine de la robotique sous-marine en particulier, et constitue une étape obligatoire dans le contexte du multi-véhicule. Nous avons ensuite dé ni ce qu'était un simulateur en distinguant le modèle, le système, le cadre expérimental et la simulation. Il est à noter que suivant le niveau de nesse retenu, le ux entre les modèles peut varier énormément. L'architecture de simulation doit donc minimiser le temps de communication entre les modèles, sous peine de ne pas pouvoir simuler des capteurs complexes nement (sonar à ouverture synthétique typiquement). Nous avons évoqué dans ce chapitre les diérentes technologies de simulateur et mentionné les travaux qui s'y rapportent. Nous proposons dans le chapitre suivant une synthèse de cette classi cation, puis la dé nition de critères supplémentaires nous permettant de mieux cerner les solutions existantes et donc de prendre position.
Chapitre
2
Synthèse et approfondissement
2.1 Synthèse
Comme nous l'avons évoqué précédemment, il existe de nombreux simulateurs que nous avons présentés selon la classi cation de P. Ridao [13]. Dans un exercice de synthèse, nous proposons une représentation schématique de cette classi cation ( gure 2.1). Cette représentation se fonde sur l'identi cation des composants fondamentaux (indiéremment appelés blocs dans ce chapitre), dont les interconnexions (au travers de la con guration d'interrupteurs), permettent d'exprimer les diérents types de simulateur. Plusieurs cou- leurs ont été utilisées pour représenter la nature des composants. Ainsi on retrouvera :
la couleur verte pour les blocs virtuels : ce sont des composants logiciels faisant évoluer un modèle mathématique correspondant à un véritable bloc
la couleur jaune pour les blocs réels : ce sont les composants matériels qui existent réellement
la couleur grise a été utilisée, quant à elle, pour représenter les blocs fonctionnant aussi bien avec les blocs réels, qu'avec les blocs virtuels.
Nous allons maintenant présenter les fonctions occupées par les diérents blocs :
Les blocs gris représentent le contrôleur du robot qu'il soit réel, ou émulé (on entend par là qu'il adopte au minimum le même comportement logique pour un ensemble de fonctionnalités, non nécessairement identique, à celles du contrôleur réel). Il s'agit donc du logiciel et du matériel réel ou pas, utilisé pour contrôler le robot. On retrouve quatre blocs correspondant chacun à un type de contrôleur. Ce type est dé ni selon trois critères :
le matériel (l'ordinateur de bord) utilisé : est-il identique à celui déployé sur le robot ? ce critère est noté HW (pour HardWare).
le logiciel du contrôleur : est-ce celui du robot réel ? ce critère est noté SW (pour SoftWare).
l'aspect temps-réel du contrôleur, noté TR.
La combinaison de ces critères mène à huit architectures diérentes, dont quatre seulement sont cohérentes et représentent un intérêt réel. Ces quatre arrangements sont donc représentés par les quatre blocs gris. Les quatre autres arrangements ne
2.1 Synthèse
Fig. 2.1 Architectures des Simulateurs. Un robot est considéré comme un ensemble capteurs - contrôleur - actionneurs - mécanique
Chapitre 2 : Synthèse et approfondissement présentent pas d'intérêt : par exemple la combinaison matériel du robot + logiciel du robot + pas temps réel n'est pas possible). L'entrée de ces blocs est constituée du vecteur d'état estimé (c'est-à-dire le vecteur d'état tel qu'il a été mesuré par les capteurs) et éventuellement de données provenant des capteurs extéroceptifs (vidéo, images sonar etc...). La sortie de ces blocs est le vecteur de commande transmis aux actionneurs, réels ou pas.
le bloc environnement représente le milieu dans lequel évolue le robot. Lorsqu'il s'agit d'un milieu virtuel, ce bloc comporte les modèles mathématiques de phéno- mènes physiques réels : vague, vent, courants, ... C'est également dans ce bloc qu'est modélisé le fond marin ainsi que le diérents objets composants le monde virtuel (structures, robots, bateaux...). L'environnement peut être stationnaire (c'est-à-dire que les diérents composants présents dans l'environnement n'évoluent pas avec le temps) ou dynamique.
Les blocs capteurs qui sont de natures diérentes :
extéroceptifs : ce sont les capteurs qui permettent de percevoir le monde extérieur : température, images sonar, ...
proprioceptifs : ce sont les capteurs qui permettent de percevoir les variables internes du robot...
Il est à noter qu'un capteur virtuel ne peut sonder qu'un environnement virtuel et qu'un capteur réel ne peut percevoir qu'un environnement réel. Il existe néanmoins une exception à cette règle. En eet, il est possible de développer une plate-forme de stimulation du robot, pour certains de ses capteurs. Cette plate-forme est alors reliée à un simulateur d'environnement et elle peut alors reproduire en réel, les stimuli que percevrait le robot plongé dans cet environnement virtuel. Ce genre de plate-forme est plutôt utilisé dans le domaine du spatial et sort du cadre de notre étude. Les blocs actionneurs : il s'agit des composants (mécaniques, électriques,...) (ou de
leur modèle mathématique si on se place dans le cadre d'une simulation) constituant la chaîne de l'eecteur permettant au robot de se mouvoir. Dans la réalité, la sortie du contrôleur n'est évidemment pas directement connectée aux actionneurs ; elle passe généralement par un étage de puissance délivrant le bon signal à l'actionneur. Cet étage n'est pas représenté sur la gure.
Le robot : il s'agit du robot lui-même si l'on se place dans un cadre réel, ou bien de la représentation mathématique de sa dynamique si l'on se place dans le cadre de la simulation. La sortie de ce bloc représente le vecteur d'état complet virtuel de l'engin (à ne pas confondre avec le vecteur d'état mesuré, qui peut être par ailleurs incomplet, de la sortie du bloc modèle capteurs). Dans le cas d'une simulation prenant en charge l'environnement, il existe des interactions entre le modèle du robot et les diérents phénomènes physiques modélisés dans l'environnement. Il peut s'agir de vagues, de courants, de vents..., ou bien de manipulations par le robot, d'objets appartenant à l'environnement. Dans ce cas, il faut relier le bloc "modèle environnement" à celui de "modèle robot" pour être en mesure de calculer l'évolution de la dynamique du robot en tenant compte de ses interactions avec l'environnement. Dans le cas réel, ces interactions existent toujours.
L'a chage 3D en n permet de représenter la scène dans laquelle se trouve le robot. Cet aspect souvent négligé et peu considéré par la communauté des roboticiens, revêt pourtant une certaine importance. Il est complémentaire de l'a chage sous forme
2.1 Synthèse
de courbes, plus classique, et permet de mieux se représenter les évolutions du robot dans son espace. Dans le cadre du multi-véhicule notamment, ce genre d'a chage se révèle précieux pour être en mesure d'analyser la situation. En n, la simulation des capteurs de vision (type caméra et appareil photo) nécessite obligatoirement ce genre de rendu. Il est alors possible de tester un ensemble d'algorithmes de type SLAM (Simultaneous Localisation And Mapping) [45] ou suivi de pipeline par exemple. Un type de simulateur est dé ni par la position des interrupteurs : il s'agit des trois "interrupteurs" sur la gure 2.1 appelés SWITCH1, SWITCH2 et SWITCH3. Chacun des interrupteurs sert à relier respectivement, les capteurs au contrôleur, le contrôleur aux actionneurs, et le robot à l'a chage 3D. Suivant les interconnexions des diérents blocs, nous retrouvons les diérentes classes de simulateurs évoquées précédemment :
les simulateurs hors-ligne : con guration des switchs = 2-b-4 les simulateurs en-ligne : con guration des switchs = 2-a-4
les simulateurs matériel-dans-la-boucle : con guration des switchs = 2-c-4 (environ- nement non obligatoire)
les simulateurs hybrides : con guration des switchs = (1-c & 2-c)-4, avec capteurs extéroceptifs et environnement
le mode réel : con guration des switchs = 1-c-3 sans a chage
Par ailleurs, ce schéma représente également des modes que nous n'avons pas évoqués, mais qui se rapprochent du contexte de la simulation :
la surveillance en ligne [1-c-3] avec a chage : ce mode permet de suivre et de repré- senter l'évolution du robot réel, dans un environnement réel, mais n'est pas adapté à tous les types de robot. En eet, si ce genre de surveillance peut s'envisager pour les robots aériens, il est en revanche peu concevable de pouvoir suivre un AUV de la même façon, en raison de la faible bande passante des communications sous-marines. entraînement de l'opérateur [2-d-4] : ce mode permet à un opérateur de disposer d'un robot virtuel, lui permettant de s'entraîner à sa conduite dans le cadre d'un engin télé-opéré, ou de s'entraîner à la prise de décision et au-delà au commandement dans le cadre d'une mission multi-véhicule.
Nous constatons à travers cette gure qu'il existe un ensemble de simulateurs diérents et il ne faudrait surtout pas en déduire, que certains sont meilleurs que d'autres. En revanche, cette diversité permet aux diérents acteurs (les mécaniciens, les automaticiens, les acousticiens, ...) d'utiliser un simulateur adapté à leurs besoins : un automaticien, par exemple, aura sans doute besoin d'un modèle dynamique du robot relativement précis dans un simulateur hors-ligne. En revanche, le concepteur d'une architecture de contrôle aura davantage besoin d'un simulateur matériel-dans-la-boucle. Chacun de ces simulateurs permet donc de valider une approche dans un certain domaine et dans un cadre dé ni. Par ailleurs, l'utilisation d'un simulateur en particulier est en relation directe avec la phase de développement de l'engin ; durant les premières phases, des simulateurs hors- ligne seront privilégiés, puisqu'à ce stade le contrôleur du véhicule n'est normalement pas crée. Par la suite, les simulateurs en-ligne pourront être utilisés sur tout ou partie de l'architecture de commande. A ce stade, les lois de commande et la dynamique de l'engin commencent à être correctement dé nies. Les dernières étapes de conception nécessitent souvent l'emploi d'un simulateur matériel-dans-la-boucle, grâce auquel il est possible de valider le comportement temporel du contrôleur et des lois de commande. En n la dernière étape qui précède l'essai réel du robot, peut nécessiter l'utilisation d'un simulateur hybride,
Chapitre 2 : Synthèse et approfondissement qui permettra de tester dans un espace opérationnel (piscine par exemple), et en sécurité, l'ensemble des comportements du robot face à diverses situations pouvant être liées à l'environnement.
La question qui se pose naturellement maintenant, concerne la place des missions multi-véhicules dans le cadre de la simulation. En eet, à ce stade nous n'avons pas encore abordé la relation qui lie les expérimentations faisant intervenir plusieurs robots mobiles autonomes, potentiellement hétérogènes, au monde de la simulation. Dans le paragraphe suivant, nous introduisons les raisons qui nous ont naturellement poussées à retenir une technologie en particulier : les simulateurs hybrides ou les simulateurs Hardware-In-the- Loop.