Convoi colonne

Afin de montrer le fonctionnement de notre application, la première simulation effectuée est relativement simple. Deux véhicules, séparés par environ 20 mètres, évoluent sur PAVIN en se suivant. La trajectoire accomplie par chaque véhicule est d’une longueur d’environ 60 mètres. Celle-ci est constituée de 2 grandes lignes droites et d’un virage à 90◦_{. Bien que le contexte de cette simulation soit simple,}

les véhicules ne savent pas où ils se situent l’un par rapport à l’autre. Estimer qu’ils sont séparés par 20 mètres est loin d’être trivial et nécessite un algorithme robuste. Comme pour toutes les expérimentations qui suivront, les véhicules ne sont pourvus

d’aucun algorithme permettant de détecter les autres véhicules directement. Ainsi, l’estimation de l’écart entre eux est uniquement basée sur la mise en correspondance d’amers. Un aperçu de la trajectoire parcourue par chaque véhicule est disponible en figure 6.3.

Figure6.3 – Aperçu des trajectoires du scénario convoi colonne simulé Le repère de référence pour l’état décentralisé est fixé sur le point de départ du véhicule de tête (vert). Avec cette configuration, cela signifie que le véhicule de derrière n’est initialement pas correctement localisé dans le repère commun et doit trouver des amers communs avec le robot de tête de manière à pouvoir estimer la distance les séparant. Afin d’être le plus clair possible, les résultats présentés ici (et pour tout le chapitre) seront uniquement ceux d’un seul des véhicules. En effet, les informations partagées par la flotte sont les mêmes, rendant les cartes décentralisées calculées par chacun quasiment identiques. Ici, les résultats sont ceux provenant du véhicule de tête.

La figure 6.4 montre les trajectoires de chaque véhicule obtenues par le SLAM bas niveau, c’est-à-dire sans intégration de la dérive ou encore d’association de données haut niveau. La trajectoire affichée pour le véhicule de derrière correspond à ses poses successives communiquées au véhicule de tête via le réseau.

Cette figure montre entre autres l’écart entre la trajectoire perçue par le véhicule de derrière et la vérité. En effet, bien que les robots se suivent, la localisation calculée ne le reflète pas. Avec le repère commun fixé (point de départ de la tête), et sans trouver d’amers communs, le véhicule de queue croit commencer sa trajectoire au point de départ du véhicule vert. Ainsi, celui-ci n’est pas correctement localisé dans le repère de référence.

On peut également constater sur la figure 6.4 que la consistance n’est pas main- tenue durant ce scénario. Les incertitudes (affichées sur la figure 6.4 mais à peine visibles) sont très faibles. Même la trajectoire verte (premier véhicule), qui est proche de la vérité, n’est pas intègre. La dérive, bien que mineure sur une si courte distance,

Figure_{6.4 – Trajectoires obtenues par le SLAM bas niveau pour le scénario convoi} colonne simulé. En vert, la trajectoire calculée par le véhicule de tête. En bleu, celle du suiveur (échangée via des communications réseau). En noir, les trajectoires réellement accomplies par les véhicules (vérité terrain). Points : départ et arrivée réels de chaque véhicule.

empêche les solutions calculées par un SLAM classique d’être consistantes.

Afin de clairement montrer la taille des ellipses d’incertitude, des zooms sur les deux trajectoires sont proposés en figure 6.5 et 6.6. Les incertitudes obtenues avec l’intégration du biais (mais toujours sans fusion) sont également visibles sur ces mêmes figures.

On peut voir sur ces deux figures que les incertitudes en sortie du SLAM mo- noculaire sont particulièrement petites, confirmant de fait l’inconsistance de la lo- calisation bas niveau. L’intégration du biais dynamique sur la figure 6.5 permet de prendre en compte même les petites dérives en fournissant des incertitudes adaptées. Le cas de la figure 6.6 est un peu différent car le véhicule commence la trajectoire en étant localisé de manière très imprécise. L’initialisation du biais permet de s’assurer que, dans le repère commun à la flotte, la vraie position du véhicule est bien incluse dans son incertitude. En l’absence d’information précise, l’incertitude statique du biais a été initialisée de manière à ce que l’ellipse générée soit un cercle de 22 mètres de rayon. Cette initialisation permet d’assurer que la vraie pose du véhicule est dans un rayon de 22 mètres par rapport au (0, 0). Nous avons fixé une valeur nulle pour le biais statique afin de pouvoir tester la fiabilité de notre algorithme d’association de données et la robustesse du modèle de dérive. Il est aussi possible de constater sur la figure 6.6 que l’intégrité du filtre est également maintenue tout le long de le trajectoire du véhicule de queue.

Figure _{6.5 – Intégration du biais pour le véhicule de tête dans le scénario convoi} colonne simulé

Figure _{6.6 – Intégration du biais pour le véhicule de queue dans le scénario convoi} colonne simulé

Sur les deux figures, les petites incertitudes sont celles en sortie du SLAM monocu- laire. Les plus grosses sont celles intégrant la dérive. Le code couleur est le même que précédemment.

La figure 6.7 présente les résultats de localisation obtenus quand le processus d’association de données est actif. Pour plus de lisibilité, uniquement quelques el- lipses sont affichées. Dès lors que l’algorithme est capable de certifier une fusion de données (assez d’amers communs entre les 2 cartes), on peut voir que la localisation est correctement corrigée. L’écart entre les véhicules est alors rétabli et les incer- titudes sont en conséquence grandement réduites. Un point intéressant à noter est que peu d’amers ont été cartographiés. Le véhicule bleu en totalise 99 et de son côté, le véhicule vert en compte 116. Ces faibles nombres compliquent la tâche de l’as- sociation de données car les sous-ensembles d’amers communs sont peu nombreux. Enfin, et c’est un aspect majeur, les localisations fournies par les véhicules avant et après l’association de données sont toujours intègres.

Figure _{6.7 – Localisation avec association de données pour le convoi colonne si-} mulé. Le code couleur est le même que précédemment. Les points bleus sont les amers cartographiés par le véhicule de derrière. De manière similaire, les points verts pro- viennent du véhicule de tête. Les points rouges sont les amers trouvés communs entre les deux véhicules par le processus d’association de données.

La qualité de la localisation est mesurée en comparant l’écart entre les véhicules. Pour ce faire, la distance réelle est établie à l’aide des GPS RTK des véhicules. Celle- ci est, à chaque instant, comparée à celle estimée par notre algorithme de SLAM décentralisé. Il est important de rappeler que, pour tous les résultats de ce chapitre, l’estimation de cette distance est uniquement faite à l’aide des amers communs et sans l’aide d’une mesure directe d’interdistance. Les résultats pour ce scénario sont disponibles en figure 6.8 où l’évolution de la distance entre les deux véhicules en fonction du temps est montrée. On peut voir que la distance estimée par le SLAM

décentralisé s’approche de la vérité après que des associations entre les robots aient été trouvées (moins de 20 centimètres d’erreur). La distance mesurée en amont du point de fusion est assez éloignée de l’écart réel (environ 5 mètres d’écart). Cela est principalement dû au fait que les associations ont été faites vers la fin de la trajectoire, rendant ainsi l’impact de la rétro-action moins important au début de la trajectoire. Augmenter le nombre d’amers à suivre permettrait d’aider à trouver des associations plus tôt afin de pouvoir estimer plus précisément la distance entre les véhicules. Bien évidemment, l’écart estimé par le SLAM bas niveau n’est pas correct car celui-ci n’est pas conscient de sa distance à l’autre véhicule.

Figure _{6.8 – Distance entre les véhicules en fonction du temps pour le convoi} colonne simulé. En rouge est la distance estimée sans association de données. La courbe noire est le véritable écart séparant les véhicules. Enfin, en bleu est la distance estimée par notre algorithme décentralisé. Le F sur l’abscisse indique quand une association de données a été trouvée (au moins 5 amers communs) et donc une fusion réalisée.

Un autre aspect intéressant est la bande passante utilisée par notre SLAM dé- centralisé. La figure 6.9 expose la quantité de données envoyée par les deux véhicules durant l’ensemble de la trajectoire. On peut voir que peu de bande passante a été consommée. En effet, approximativement 10 ko sont émis par seconde et par véhi- cule, ce qui est très loin des verrous technologiques actuels. Les standards étant à plus de 5 Mo par seconde, il est possible d’augmenter le nombre de véhicule sans risquer une congestion du réseau (jusqu’à 500 robots dans notre cas ici). La nature éparse des cartes que l’on construit aide à maintenir ces chiffres bas puisque la bande passante requise est fortement liée au nombre d’amers échangés.

Ce premier scénario montre que le nombre d’amers dans la carte joue un rôle clef pour l’estimation de la distance entre les véhicules. Néanmoins, l’écart conséquent séparant les véhicules à tout de même pu être estimé assez précisément. L’algorithme doit maintenant être éprouvé sur de plus longues distances. Cela sera l’objet de la prochaine simulation

Figure _{6.9 – Quantité de données envoyées en fonction du temps pour le convoi} colonne simulé. La courbe verte représente les données envoyées par le véhicule de tête et en bleu celles émises par le véhicule arrière. La quantité de données est exprimée en octets.