• Aucun résultat trouvé

5.2 Conception d’un algorithme de SLAM décentralisé

5.2.3 Résultats préliminaires

Les résultats qui vont être présentés ont tous été obtenus grâce à un simulateur (le même que précédemment) pour des raisons de commodité. Encore une fois, l’en- vironnement de la place de Jaude a été utilisé afin de mener ces scénarios. Il est important de rappeler que le simulateur sert uniquement à générer des données cap- teur. Dans ces résultats, deux véhicules ont été employés. Les traitements SLAM de chaque robot sont faits sur des ordinateurs séparés avec de réelles communications réseau. Pour ces deux trajectoires, chaque véhicule était équipé d’une caméra fonc- tionnant à 10 Hz ainsi que d’un odomètre et d’un capteur d’angle de braquage. Les véhicules se déplaçaient encore une fois à environ 2 mètres par seconde. Côté SLAM monoculaire, 20 amers étaient suivis par image et seulement ceux ayant conver- gés ont été utilisés dans l’algorithme décentralisé. Dans ces simulations, le biais dynamique n’était pas utilisé. Le but était de tester la phase d’initialisation avec des incertitudes importantes ainsi que le bon fonctionnement de notre architecture. L’association de données en place ici est la même que celle utilisée dans le SLAM monoculaire. Le but est de tester la robustesse que peut avoir un tel algorithme dans un contexte décentralisé.

La première trajectoire, présentée en 5.2.3.1, voit deux véhicules évoluer en co- lonne. Pour la seconde trajectoire, illustrée quant à elle en 5.2.3.2, deux véhicules avancent côte à côte, dans ce que l’on appelle un convoi ligne.

5.2.3.1 Convoi colonne

Concernant le convoi colonne, l’idée est de voir si les véhicules sont capables d’es- timer la distance les séparant sans utiliser d’observations directes mais uniquement des amers communs. Sur cette trajectoire, le véhicule de queue parcourt 70 mètres et le véhicule de tête 85 mètres. Les robots sont à l’origine séparés par environ 5 mètres. Ceux-ci vont évoluer en ligne droite pendant toute la trajectoire. Le repère global est fixé sur le véhicule de tête. Cela signifie que le véhicule de queue débutera sa trajectoire en pensant qu’il est situé à la même position que le robot de tête. Pour ce véhicule de derrière, l’initialisation du biais est faite de manière à intégrer sa position réelle avec une incertitude circulaire de 7 mètres de rayon. En revanche, le véhicule de devant étant parfaitement localisé au départ, il n’est affublé d’aucun biais.

Au cours de cette trajectoire, le véhicule de queue a cartographié 61 amers alors que celui de tête en a conservé 71 dans sa carte. Ce sont ces amers qui sont échangés au fil de la trajectoire. Les trajectoires accomplies par les deux véhicules, ainsi que les amers, sont visibles sur la figure 5.9.

Figure 5.9 – Trajectoire en convoi colonne. La ligne rouge est la trajectoire du véhicule de queue et la ligne bleue celle accomplie par celui de tête. Les amers suivent le même code couleur. Les amers en vert sont ceux associés et donc communs aux deux véhicules.

Nous pouvons constater que le véhicule de queue a bien été capable d’estimer la distance le séparant du meneur. En effet, après quelques mètres, on peut voir que la position du véhicule est corrigée et ramenée derrière le véhicule de tête. En revanche, uniquement 3 amers communs ont été trouvés. Cela est dû au fait que les seuils servant à certifier une correspondance ont été durcis afin d’éviter de faux appariements. L’algorithme d’association n’est donc pas adapté à une utilisation multivéhicule.

Malgré ces difficultés, les quelques associations trouvées ont permis d’estimer correctement le biais statique. La qualité des résultats de localisation est indiquée dans la table 5.1 et ce après chaque association faite. Pour ce faire, la valeur estimée du biais statique est comparée, après chaque association, à la vraie distance séparant les véhicules au début de la trajectoire (donnée fournie par le simulateur).

x y z Ψ Φ Θ Association 1 3,1282 1,0247 0,2300 0,0369 0,0110 0,0815 Association 2 1,9790 0,3605 0,2357 0,0168 0,02033 0,0113 Association 3 0,3123 0,2599 0,2081 0,0152 0,0207 0,0074 Table5.1 – Erreur quadratique moyenne du biais pour le convoi colonne

Nous pouvons constater que chaque association a contribué à affiner l’estimation du biais. Après les 3 associations, l’erreur de position est d’environ 25 centimètres pour les 3 axes. L’erreur d’orientation quant à elle est en dessous de 0,01 radian. Il est important de rappeler que le seuil utilisé pour la convergence des amers est toujours fixé à 50 centimètres et influe donc grandement sur la qualité des mesures obtenues. Néanmoins, les résultats sont satisfaisants.

Les temps de calcul induits par la surcouche décentralisée sont très faibles. Cela est dû au fait que la réception, l’envoi et la fusion d’informations se font en parallèle. Les temps obtenus sont affichés sur la figure 5.10. Les temps sont donnés pour chaque appel fait à la fonction concernée (envoi, réception, fusion), ce qui signifie que l’algorithme décentralisé est inactif la majeure partie du temps. Le pire cas observé fait état de 100 μs de temps de traitement (moins de 1% du temps total de calcul). Il est cependant important de garder en tête que l’association de données et la gestion du biais dynamique ne sont ici pas incluses.

Figure5.10 – Temps de calcul requis par le processus décentralisé. La courbe rouge est le temps nécessaire à l’envoi des amers. La bleue est celle indiquant le temps consacré à la réception de ceux-ci. Enfin, la courbe verte est le coût calculatoire de l’étape de fusion décentralisée.

Enfin, la bande passante requise pour cette simulation était relativement faible (voir figure 5.11). Chaque véhicule envoyait moins de 2 ko de données par seconde. Encore une fois, il est important de garder en tête que le biais n’est ici pas commu- niqué et que le nombre d’amers cartographiés est peu conséquent. Néanmoins, ces résultats démontrent la faisabilité de notre approche.

Figure 5.11 – Bande passante utilisée lors de la trajectoire. La courbe rouge est la bande passante utilisée par le véhicule de queue. La courbe bleue représente celle consommée par le véhicule de tête.

5.2.3.2 Convoi ligne

Le dernier scénario testé dans cette section présente deux véhicules se déplaçant côte à côte. Cette simulation est intéressante car il est impossible pour les véhicules de s’observer directement et l’estimation de l’état de la flotte ne peut être faite qu’en trouvant des points de l’environnement en commun. Par rapport à l’approche colonne précédente, les amers communs vont ici être situés dans le champ recouvrant des caméras des deux véhicules plutôt que partout dans l’image. La difficulté est donc de trouver des points communs en bordure de l’image.

Concernant les trajectoires, les deux véhicules ont approximativement parcourus 90 mètres chacun en ligne droite. Encore une fois, le véhicule rouge (de gauche) est celui qui démarre avec un biais statique puisqu’il se localise en fonction du repère initial du véhicule bleu (de droite) dont la position est inconnue. Le robot de droite est quant à lui bien localisé et n’est donc pas affecté par un biais statique. Les deux robots sont séparés par environ 2,5 mètres au début de la simulation. L’incertitude du biais statique a été fixé en fonction de cela afin de former un cercle d’environ 6 mètres de diamètre pour le véhicule rouge.

n’en a que 34 dans sa carte. Cela est dû au fait que le véhicule bleu n’a quasiment aucun objet proche contrairement au rouge qui a des façades de bâtiments sur sa gauche (voir figure 3.20(d)). Ainsi, il est plus difficile de faire converger des amers pour le véhicule bleu. Les trajectoires suivies sont disponibles en figure 5.12.

Figure 5.12 – Trajectoire en convoi ligne. La ligne rouge est la trajectoire du véhicule de gauche et la ligne bleue celle accomplie par celui de droite. Les amers suivent le même code couleur. Les amers en vert sont ceux associés et donc communs aux deux véhicules.

Encore une fois, uniquement 3 amers communs ont pu être identifiés pour les mêmes raisons que le scénario précédent. Néanmoins, ceux-ci ont permis d’estimer la distance séparant les véhicules correctement. On peut en effet constater qu’après quelques mètres, la position du véhicule rouge est corrigée et traduit bien la confi- guration initiale des véhicules.

L’estimation du biais obtenue est néanmoins de bonne qualité comme en té- moigne la table 5.2. L’erreur concernant la distance initiale séparant les véhicules est très faible. Elle est sous la barre des 5 centimètres pour les axes liés à la position. L’erreur d’orientation est elle inférieure à 0,002 radian.

x y z Ψ Φ Θ

Association 1 0,1679 0,0571 0,0025 0,0002 0,0006 0,0026 Association 2 0,0519 0,0970 0,0007 0,0017 0,0002 0,0052 Association 3 0,0435 0,1215 0,0255 0,0077 0,0011 0,0019 Table5.2 – Erreur quadratique moyenne du biais pour le convoi ligne

La qualité des amers cartographiés a permis d’atteindre une bonne précision pour le biais statique. Les résultats en termes de temps de calcul et de bande passante utilisée sont eux aussi similaires à ceux de la trajectoire précédente et ne seront donc pas exposés ici.

Ces scénarios ont montré que la notion de biais statique permet d’assurer la consistance du filtre à son initialisation. La distance entre les véhicules peut ainsi être retrouvée avec une précision satisfaisante. Les coûts en temps de calcul et en bande passante montrent également que notre approche décentralisée est tout à fait

viable. Elle peut facilement être étendue à plus de véhicules sans aucun problème. Ces premiers résultats illustrent bien à quel point l’utilisation du biais sous sa forme dynamique est nécessaire dans un algorithme multivéhicule, que cela soit pour assu- rer l’intégrité du filtre ou faciliter l’association de données. Ces résultats indiquent d’ailleurs qu’il est nécessaire de construire un processus d’association de données plus robuste que celui mis en place dans le SLAM monoculaire. En effet, avec plu- sieurs véhicules et des incertitudes importantes, cet algorithme représente un point crucial de l’approche décentralisée.