Classication des simulateurs étudiés

Pour calculer le score, nous nous plaçons dans le contexte du multi-véhicule "pur". Cela sous-entend que seul l'aspect multi-véhicule nous interesse, et que nous ne considérons pas toutes les applications rattachées à ce contexte (suivi de gradient, suivi de pipeline, évitement d'obstacles, ...). Ce choix permet de cerner le noyau des simulateurs étudiés (2.12) :

La gure 2.13 présente un tableau regroupant l'ensemble des simulateurs étudiés. On constate donc que, dans notre contexte, il n'existe que cinq simulateurs pouvant

Chapitre 2 : Synthèse et approfondissement

Fig. 2.12  Choix des groupes et classement des critères.

Fig. 2.13  Principales propriétés des simulateurs étudiés. Les simulateurs ne possédant pas de score, sortent du cadre minimal que nous avons xé.

potentiellement répondre à notre problématique. Il est à noter que ce nombre est d'autant plus petit, que la dénition de notre cadre minimal est large, car aucun critère autre que le multi-véhicule n'a été sélectionné. En eet, un très grand nombre de missions diérentes (océanographie physique, évitement d'obstacles sous contraintes de ottille, cartographie coordonnée, etc...) s'orent à nous, et les diérentes communautés rattachées à ces appli- cations pourraient sans doute mieux dénir les groupes an d'aner la classication. Cependant ces cinq simulateurs sourent de défauts que nous avons évoqués précédem- ment, qui, dans notre contexte, remettent en question la validité des résultats obtenus par leur exploitation. Nous ne pouvons pas réduire le nombre de véhicules participant à une simulation, pour le motif d'une puissance de calcul trop faible pour faire face aux contraintes temps réel. De même, la granularité et la nesse des modèles employés sont pour nous des notions clés, qui ne doivent pas être dictées par les capacités de calcul du simulateur. Tous ces simulateurs ne permettent pas de préparer une mission opération- nelle, ce qui reste quand même un des objectifs de cette thèse. Enn, aucun ne mentionne la problématique du découplage temporel.

2.5 Conclusion

2.5 Conclusion

Dans ce chapitre, nous avons proposé une synthèse des diérentes classes de simula- teurs. Nous avons ensuite examiné quatre autres critères qui semblent particulièrement importants dans le contexte de la simulation multi-véhicule : le concept de multi-véhicule lui même, la communication inter-véhicule, la distributivité du simulateur et la visuali- sation 3D. Nous avons alors constaté qu'il était nécessaire de proposer une nouvelle clas- sication, permettant de qualier plus nement les simulateurs dans un contexte donné, et pour une application précise. Nous avons ainsi déni un ensemble de groupes de cri- tères précis. Il nous a alors été possible grâce à une méthode que nous avons proposée, de dénir précisément les critères minimaux requis pour considérer un simulateur comme étant multi-véhicule. Nous avons conclu que, parmi les 19 simulateurs étudiés, seuls cinq pouvaient être qualiés de la sorte, mais qu'ils souraient de défauts de conception ou de limitations intrinsèques à leur architecture. Cette absence d'outil réellement adapté est sans doute une des raisons du faible nombre de manipulations réelles. Nous avons constaté à travers ces exemples, que beaucoup de concepts ont été développés, mais on peut armer, au vu de ces résultats qu'il manque réellement une architecture ouverte, permettant de rassembler les concepts et les acteurs.

L'objet de notre prochain chapitre est donc de présenter notre positionnement par rapport aux simulateurs existants. Nous présenterons point par point les concepts cruciaux qui seront retenus pour notre proposition pour une architecture de simulateur ouverte que nous exposerons par la suite.

Chapitre

3

Positionnement des travaux

Dans le chapitre précédent, nous avons démontré que le recours à la simulation était nécessaire pour aborder le contexte de la coordination multi-véhicule. Nous avons alors étudié les simulateurs existants et avons déduit grâce à notre classication que seuls cinq d'entre eux permettaient d'aborder une partie de la problématique. Dans ce chapitre, nous commençons par nous positionner par rapport aux travaux antérieurs et nous mon- trons qu'aucun d'entre eux ne semble réellement satisfaisant pour notre application. Nous évoquons notamment nos propres besoins actuels puis le devenir de ces besoins pour l'en- semble de la communauté. Enn nous abordons les hypothèses et spécications du système de simulation que nous proposons et qui sont nécessaires si l'on considère la validité de la simulation.

3.1 Un simulateur mais une architecture avant tout

Les chercheurs travaillant dans le domaine de la robotique sous-marine autonome, sans doute encore davantage que ceux travaillant dans les autres domaines de la robo- tique, ont massivement recours à la simulation. Du plus simple (simulateur hors-ligne), au plus perfectionné (simulateur hybride), en passant par toutes les solutions intermé- diaires, on peut estimer le nombre de combinaisons de ces simulateurs à environ 36000 (estimation faite à partir des combinaisons possibles des critères exposés au paragraphe 2.4). Parmi l'ensemble de ces simulateurs seule une petite partie ore les fonctionnalités nécessaires à la préparation "real-like" d'une véritable mission (qu'elle soit multi-véhicule ou non). Pour autant un ensemble de fonctionnalités ne constitue pas un simulateur en soi. Au-delà même de l'aspect modélisation et implémentation, se trouvent les fondements de la simulation : une architecture.

Un travail est donc nécessaire avant d'aborder la problématique de la modélisation, même si modéliser et implémenter sont souvent les premiers réexes. Par ailleurs, la simulation est souvent négligée et constitue une discipline assez peu considérée par la communauté des roboticiens : peu de chercheurs souhaitent s'investir dans ce domaine. Si cela ne porte pas à conséquences dans la plupart des situations (premières étapes de la conception des lois de commande, certains tests de convergence, ...), il en existe d'autres pour lesquelles la