Centralisé ou décentralisé

Avant même de commencer à étudier l’algorithme lui-même, il est important de considérer comment les véhicules vont coopérer. Cela signifie qu’il faut déterminer comment ils vont communiquer. Cela est fortement conditionné par l’environnement visé. Deux systèmes s’opposent : les approches centralisées et celles distribuées (ou décentralisées).

Dans le premier cas, toutes les communications sont faites avec une entité qui a pour charge d’agglomérer les données et de les fusionner (voir figure 5.1). Elle doit ensuite partager le résultat avec la flotte de véhicules. Cette entité peut être un des véhicules de l’équipe ou bien encore un ordinateur dédié. Cette organisation est souvent utilisée car elle facilite grandement l’extension d’un algorithme de SLAM à plusieurs véhicules puisqu’il suffit de mettre en place un système de communi- cation et un traitement spécifique pour la fusion centrale. Beaucoup d’approches se sont orientées vers un système centralisé de par sa simplicité d’utilisation. Dans [Gil et al. 2010], il s’agit d’un SLAM visuel basé sur un filtre particulaire. Cet algo- rithme est le premier à avoir proposé un SLAM visuel multivéhicule (ici une paire stéréo). Dans celui-ci toutes les mesures sont envoyées à un agent central qui a la charge de construire la carte. Les positions initiales des robots doivent être approxi- mativement connues afin de pouvoir se localiser dans cette carte commune.

Figure _{5.1 – Schéma simplifié d’un système centralisé}

Les systèmes décentralisés supposent que chaque véhicule est capable de construire sa carte décentralisée tout en communiquant avec les autres robots de la flotte (voir figure 5.2). Un tel schéma est plus compliqué à gérer car il implique que les véhicules vont communiquer et échanger directement ensemble. Il faut donc contrô-

ler le flux d’informations qui circule. Les premiers algorithmes de SLAM décentralisé sont issus de travaux sur la fusion décentralisée. Le principe est le même, il s’agit de distribuer la fusion en répartissant le calcul sur différents processeurs. Certaines approches ont ainsi pu découler naturellement de ces algorithmes. Par exemple, les travaux de localisation multivéhicule de Nettleton et al. dans [Nettleton et al. 2006] sont basés sur des avancées significatives pour la fusion décentralisée de capteurs présentées dans [Nettleton et al. 2003] et [Durrant-Whyte 2000].

Figure _{5.2 – Schéma simplifié d’un système décentralisé}

Les systèmes distribués sont souvent préférés aux approches centralisées. Bien que plus complexes, ceux-ci ne sont pas affectés par les limitations qu’induit la centralisation des données. En effet, du point de vue de la robustesse, centraliser la construction de la carte est une mauvaise idée. Si la machine ayant la charge de cette tâche vient à tomber en panne, plus aucun véhicule ne pourra accéder à cette information ou encore profiter des nouvelles cartes envoyées par les autres robots. Dans le cas d’une application décentralisée, la panne d’un des véhicules n’empêche pas les autres de continuer à échanger et améliorer la carte commune. Hormis la robustesse, une entité centralisante pose aussi le problème de la quantité de données circulant sur le réseau. Dans le cas décentralisé, seules les informations envoyées par les véhicules passent par le réseau. Pour une approche centralisée, il faut ajouter à cela le retour de l’entité principale chargée d’agglomérer les données. En fonction du nombre de véhicules dans la flotte et de la taille des cartes, ce point peut avoir des répercussions importantes sur la bande passante nécessaire. Enfin, le fait que chaque véhicule doive être à portée de communication de l’unité centralisante est une limitation qui peut devenir gênante si l’on souhaite couvrir de grandes distances. Ce problème n’affecte pas les approches distribuées dans la même mesure puisque chaque véhicule est capable de relayer l’information à ses voisins.

tiellement décentralisés mais casse la complexité habituelle de ces approches en centralisant les calculs les plus critiques. C’est le cas de [Bailey et al. 2011] où les auteurs proposent une approche de localisation majoritairement décentralisée. Dans celle-ci les véhicules sont équipés de capteurs différents et la fusion de l’état est ainsi faite localement. L’estimation des distances entre les différentes membres de la flotte est, en revanche, faite par un serveur central. De manière similaire, dans [Vidal-Calleja et al. 2011], une approche de SLAM décentralisé basée sur des sous- cartes est proposée. Bien que la méthode soit présentée pour être entièrement dé- centralisée, les expérimentations montrent qu’un ordinateur central est utilisé pour calculer et enrichir la carte topologique globale gardant la trace de toutes les sous- cartes.

L’autre possibilité est de spécialiser la flotte en lui attribuant un meneur ayant un algorithme légèrement différent des autres. Ce cas de figure est extrêmement présent dans les scénarios impliquant des véhicules évoluant en convoi colonne (l’un derrière l’autre). Féraud et al. dans [Féraud et al. 2010] propose qu’un premier véhi- cule construise une carte qui sera ensuite utilisée par un autre (ou possiblement plu- sieurs). Le but est que des véhicules suiveurs puissent tirer parti des informations re- cueillies par le premier en se localisant dans la carte précédemment construite. L’ob- jectif final est ici de faire de la conduite automatique. Dans [Avanzini et al. 2012], le contexte est similaire puisque les véhicules doivent évoluer dans un convoi colonne classique. Les véhicules suiveurs se servent de la localisation calculée par le véhicule de tête à un passage antérieur afin de pouvoir calculer les trajectoires permettant d’emprunter exactement le même chemin que le meneur.

Afin de produire la solution la plus générale possible, nous nous sommes tournés vers la construction d’un algorithme entièrement décentralisé. Cela signifie que les mêmes traitements sont faits par l’ensemble des véhicules de la flotte. Aucune entité externe n’est utilisée pour centraliser les informations. De même, aucun membre de la flotte n’a le statut de meneur : l’ordre d’un convoi peut donc être bouleversé et l’organisation de la flotte peut changer à tout moment. Ce choix implique que l’échange de données entre les véhicules doit être fait avec attention.