Premiers résultats

Le processus développé peut être utilisé pour détecter des fermetures de boucle (observations associées avec la carte du même véhicule) et des endroits déjà carto- graphiés par un membre de la flotte (carte du véhicule en train d’explorer associée avec celle établie par le véhicule qui a déjà traversé la zone). L’association de don- nées est déclenchée intelligemment pour éviter des traitement inutiles. Uniquement les nouveaux points sont testés avec la carte globale. Si aucune association n’est trouvée, l’amer est directement ajouté à la carte et lié au reste du vecteur d’état via le biais l’affectant. Sinon, celui-ci est conservé dans le processus d’association de données et si assez de correspondances sont déjà disponibles, la fusion de ces amers est faite. Comme cela a été énoncé auparavant, un véhicule traversant une zone déjà explorée ne cartographiera pas nécessairement les mêmes amers. Au lieu d’analyser les amers communs à un seul moment, nous avons choisi de rechercher les associations sur des portions de la carte. Cela signifie que les amers qui ont été appariés sont gardés dans le processus d’association pendant un certain temps. Si durant cette période, assez d’amers sont associés pour certifier qu’un endroit a été reconnu, alors une fusion sera réalisée. Si ce n’est pas le cas, ces amers seront ajoutés à la carte globale.

Une expérimentation a été menée afin de tester l’algorithme construit dans des conditions réelles. Un VIPALab a accompli une trajectoire de 150 mètres avant de

retourner à son point de départ et d’enchaîner avec un second tour de la même boucle. La partie de la trajectoire qui nous intéresse ici est le moment où le véhicule commence à traverser la zone qu’il a déjà cartographiée. Après 150 mètres, la dérive affectant la pose du véhicule peut être importante, il est ainsi pertinent de tester la robustesse de l’algorithme dans ces conditions. Bien évidemment, le but ici est de fermer la boucle. Néanmoins, les traitements sont identiques à une association entre deux véhicules différents. La figure 5.14 montre la portion de la trajectoire où le véhicule traverse une zone préalablement visitée.

Figure 5.14 – Associations trouvées entre deux passages. La courbe bleue est la trajectoire calculée lors du premier passage. La rouge est celle obtenue au deuxième tour. Les amers correspondant à chaque passage suivent le même code couleur. Les amers trouvés comme communs entre les cartes sont reliés par des lignes vertes.

On peut constater qu’entre les deux passages, le véhicule a dérivé. En effet, bien que le chemin soit le même la deuxième fois, la position du véhicule est éloignée de quelques mètres de celle calculée lors du premier tour. Sur la portion commune, le véhicule a cartographié un peu plus de 30 amers sur le premier passage et autour de 20 lors du second. L’algorithme d’association a permis de trouver 10 amers comme étant communs aux deux tours. On peut constater que ces amers partagent une configuration géométrique similaire.

Ces résultats sont encourageants puisqu’ils montrent qu’avec seulement quelques amers, le processus d’association trouve tout de même des correspondances entre les deux passages. D’autres expérimentations, impliquant plusieurs véhicules, doivent cependant être conduites afin de le valider définitivement et seront montrées dans le prochain chapitre.

les problématiques courantes de ces approches tout en étant suffisamment général pour pouvoir utiliser n’importe quel processus de SLAM bas niveau existant. La consanguinité des données est évitée par une stratégie d’échange couplée à une ar- chitecture dédiée. Cette dernière permet par ailleurs de gérer les échecs du réseau (désynchronisations, latences, coupures de communication). L’application conçue in- tègre également la dérive de chaque véhicule sous la forme d’un biais de localisation. Sa partie statique, liée à son initialisation, permet également de mettre dans un même repère les différents véhicules de la flotte et ainsi de résoudre le problème des positions initiales inconnues. Enfin, un algorithme d’association de données pour le multivéhicule a été exposé. Celui-ci tire parti des spécificités de l’application construite. Chaque point du SLAM décentralisé a été validé individuellement par des expérimentations. Le prochain chapitre va maintenant proposer des résultats mettant en jeu l’intégralité de l’application développée, et ce dans des conditions et configurations variées.

Expérimentations et résultats

pour le multivéhicule

Sommaire

6.1 Résultats avec simulateur . . . 158 6.1.1 Convoi colonne . . . 159 6.1.2 Changement de l’ordre du convoi . . . 165 6.2 Résultats avec données réelles . . . 173 6.2.1 Convoi colonne à deux véhicules . . . 173 6.2.2 Convoi ligne à deux véhicules . . . 176 6.2.3 Convoi à trois véhicules . . . 182 6.3 Analyse des résultats . . . 190

Au cours de ce chapitre, les différentes expérimentations et simulations me- nées vont être exposées. Celles-ci vont à chaque fois utiliser l’application complète de SLAM décentralisé. Afin de pleinement valider notre algorithme, celui-ci sera confronté à diverses situations. Le contexte multivéhicule rend néanmoins la mise en place d’expérimentations avec plusieurs véhicules difficile. En effet, cela nécessite d’avoir tous les véhicules de la flotte opérationnels à un moment donné. De même, la communication sans fil doit être fonctionnelle et les conditions météorologiques propices à la mise en route des robots. Le support technique doit donc être impor- tant. Ainsi, dans un premier temps, et afin d’éviter ces contraintes, notre solution a été testée grâce au simulateur présenté plus tôt dans ce manuscrit. Ces simulations feront l’objet de la section 6.1. Après cette première validation, l’algorithme sera alors utilisé dans des expérimentations avec des données réelles. Des configurations différentes et des résultats à 2 et 3 véhicules seront présentés dans la section 6.2. Dans toutes ces expérimentations, le modèle de biais utilisé n’intègre pas la trans- lation à l’origine puisque les différentes fusions ont lieu a proximité de l’origine et n’ont donc pas d’impact significatif sur les résultats. Enfin, la section 6.3 discutera les résultats obtenus en dressant un bilan rapide de notre approche.

6.1

Résultats avec simulateur

Deux scénarios ont été réalisés avec l’aide du simulateur. Comme pour ses uti- lisations précédentes, le simulateur sert uniquement à générer des données capteur et ne fait aucun traitement supplémentaire sur celles-ci. Chaque véhicule simulé est géré par une instance de l’algorithme décentralisé de SLAM et doit donc gérer le partage des données au travers d’un vrai réseau. Ici, plutôt que l’environnement de la place de Jaude, nous nous sommes orientés vers celui de PAVIN simulé. Ce dernier est identique à la plate-forme utilisée pour les expérimentations réelles et est plus représentatif de l’environnement urbain que ne peut l’être la place de Jaude qui est très ouverte. Quelques vues de PAVIN simulé sont disponibles en figure 6.1 et quelques images caméra prises en cours de trajectoire sont visibles en figure 6.2. Dans les deux scénarios simulés, chaque véhicule est équipé d’une caméra (située à 1,20 mètres dans l’habitacle) fournissant des images en niveaux de gris à 10 Hz et d’un odomètre. Un GPS RTK simulé est également présent afin de servir de vérité terrain. Les véhicules se déplacent à approximativement 2 mètres par seconde. Ces véhicules sont les équivalents simulés de l’Aroco. Ce dernier est un engin tout-terrain habituellement utilisé dans le domaine agricole. Ici, son comportement simulé est très proche du VIPALab présenté précédemment. Tous les résultats présentés ici, et dans la prochaine section, sont ceux obtenus après application de la rétro-action naturelle sur l’ensemble du vecteur d’état décentralisé lorsque des associations sont trouvées.

(a) (b)

Figure 6.1 – Environnement PAVIN sous le simulateur

(a) (b)

Figure _{6.2 – Quelques exemples d’images issues de la caméra virtuelle sur PAVIN}

Dans la sous-section 6.1.1, un convoi colonne classique à deux véhicules sera présenté. Le but est ici de valider l’application et d’en comprendre clairement les tenants et aboutissants. Le deuxième scénario qui sera décrit en sous-section 6.1.2 est lui plus complexe. Il s’agit d’une longue trajectoire au cours de laquelle le véhicule de tête sera interverti avec celui de queue.