Changement de l’ordre du convoi

En plus de pouvoir gérer des convois très espacés, notre SLAM est entièrement décentralisé et peut donc fonctionner sans véhicule meneur. Cet aspect sera illustré sur la prochaine trajectoire. L’idée est d’inverser l’ordre d’un convoi colonne au cours de la trajectoire. Le véhicule de tête devient celui de queue et inversement. C’est aussi un moyen de montrer une trajectoire plus complexe et plus longue. Le contexte est exactement le même que pour le scénario précédent. Les véhicules sont équipés des mêmes capteurs fonctionnant aux mêmes vitesses. Les deux trajectoires mesurent approximativement 110 mètres chacune. Une vue de dessus des trajectoires effectuées est disponible en figure 6.10. Les deux véhicules sont séparés initialement par 11 mètres et démarrent en configuration classique colonne. Le véhicule vert est la tête du convoi et le bleu le suiveur. Après le premier virage, le véhicule vert fait le tour du rond-point pendant que le véhicule bleu passe devant. Le robot vert s’arrête quelques secondes dans le rond-point afin de laisser le nouveau véhicule de tête prendre quelques mètres d’avance. Les trajectoires continuent ensuite dans cette formation jusqu’à l’arrêt final.

On peut constater que les portions communes ne sont pas très longues et de- mandent donc que l’association de données fonctionne efficacement. En gardant cela à l’esprit, nous avons augmenté le nombre de points caractéristiques suivis dans les images afin d’avoir plus d’amers dans l’algorithme décentralisé. Concernant l’initia- lisation du biais, le point de départ du véhicule de devant est encore une fois utilisé comme repère commun. Le robot à l’arrière est donc initialement localisé de manière imprécise. Son biais statique a été fixé de façon à générer un cercle de 21 mètres de rayon afin de ne pas avoir un a priori trop précis sur la distance entre les véhicules.

Figure _{6.10 – Aperçu (approximatif) des trajectoires du scénario d’inversion de} convoi. Les croix correspondent à des arrêts du véhicule et les cercles aux points de départ.

La figure 6.11 montre les trajectoires calculées par le bas niveau avec les incer- titudes associées et les vérités terrain.

Les résultats sont assez proches de ceux de la simulation précédente. La trajec- toire bleue estimée est décalée de 11 mètres dans le repère commun. Les incertitudes restent, pour les deux véhicules, très faibles tout au long du scénario. L’intégrité des localisations n’est pas préservée, et ce même pour le véhicule vert dont la pose est assez bien estimée. En plus de l’écart initial, les deux véhicules sont affectés par un léger biais angulaire, écartant les trajectoires de leur vérité terrain. Les figures 6.12 et 6.13 montrent comment l’intégration du biais affecte les incertitudes. Un zoom sur les incertitudes du bas niveau est également visible pour chacune des trajectoires.

L’intégration du biais permet de maintenir la consistance de la localisation tout au long des deux trajectoires. Dans le cas de la figure 6.12, l’évolution de l’incertitude de biais est bien visible car le véhicule part parfaitement localisé puis dérive tout doucement, diminuant ainsi la précision de sa position. La vue rapprochée vers la fin de la trajectoire montre que le SLAM bas niveau est loin d’intégrer le véritable chemin suivi par le véhicule alors que le biais le permet. L’évolution de l’incertitude du biais est moins évidente sur la figure 6.13. En effet, le biais statique est important et masque l’évolution de sa partie dynamique. Le zoom en fin de trajectoire montre encore une fois l’impossibilité du SLAM classique à maintenir l’intégrité.

Figure6.11 – Trajectoires obtenues par le SLAM bas niveau pour le scénario d’in- version de convoi. En vert, la trajectoire calculée par le véhicule initialement devant. En bleu, la même chose pour l’autre véhicule (échangée via des communications réseau). En noir, les trajectoires réellement accomplies par les véhicules (vérité ter- rain).

Les trajectoires calculées lorsque des associations sont cherchées sont exposées en figure 6.14. Pour des raisons de clarté, les amers ne sont pas visibles, uniquement les trajectoires et les incertitudes le sont. À l’inverse, les trajectoires avec les amers cartographiés, mais sans les incertitudes, sont montrées dans la figure 6.15.

La localisation obtenue est proche de la vérité terrain, et ce pour les deux véhi- cules. Les incertitudes du biais ont été grandement réduites, surtout pour le véhicule bleu qui démarrait la trajectoire avec une covariance initiale importante. Les poses des véhicules sont consistantes, même avec ces incertitudes réduites.

Le fait de trouver des portions communes de cartes est facilité par un nombre d’amers cartographiés plus important. La première association est essentielle car c’est celle qui va donner la première estimation de la distance réelle entre les véhi- cules et donc réduire drastiquement l’incertitude de biais initiale. Celle-ci intervient ici rapidement après le début de la trajectoire. Avec une idée précise de cette dis- tance, identifier les amers communs est plus facile car les incertitudes sont plus petites et donc plus discriminantes. Cela a permis à l’algorithme de trouver des as- sociations dans la deuxième grande ligne droite après le rond-point. Il est tout de même important de mentionner que peu d’amers sont communs entre les deux vé-

Figure_{6.12 – Intégration du biais dans le scénario d’inversion de convoi (1/2)}

Figure6.13 – Intégration du biais dans le scénario d’inversion de convoi (2/2) 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.

Figure _{6.14 – Localisation avec association de données pour l’inversion de convoi}

Figure _{6.15 – Amers cartographiés pour le scénario d’inversion de convoi. Le code} couleur est le même que précédemment.

hicules. En effet, avec une orientation du véhicule légèrement différente, la sélection de points caractéristiques peut totalement changer. C’est par exemple le cas après le rond-point où le véhicule vert tend à cartographier des points sur le bord droit de la route alors que le véhicule bleu n’a pour ainsi dire que des points sur le bord gauche.

La justesse de la distance estimée est présentée en figure 6.16. Elle est comparée à la vérité terrain ainsi qu’à l’écart calculé par le SLAM sans l’intégration de la dérive. La qualité de la localisation de chaque véhicule n’est pas donnée car peu pertinente. En effet, sans fermeture de boucle ou information absolue, il n’est pas possible de corriger complètement la dérive du SLAM. La distance entre les véhicules évoluant beaucoup durant ce scénario, c’est un bon indicateur de la qualité du modèle de biais.

Figure _{6.16 – Distance entre les véhicules en fonction du temps pour le scénario} d’inversion de convoi. 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é. Les F sur l’abscisse indiquent quand une association de données a été trouvée (au moins 5 amers communs) et donc une fusion réalisée.

On peut constater que l’estimation de la distance suit de très près le véritable écart (moins de 20 centimètres d’erreur sur la première moitié de la trajectoire et 80 centimètres sur la deuxième partie). Aucun pic majeur n’est à noter. La rétro-action appliquée aux distances passées donne de meilleurs résultats que pour le scénario précédent. Cela est principalement dû au fait que plus d’amers ont été associés et ce dès le début de la trajectoire. Le plus gros écart dans l’estimation (autour de 1,5 mètres) intervient au moment où aucune association n’est trouvée.

similaires à ceux observés précédemment. Ils sont renseignés en figure 6.17.

Figure 6.17 – Quantité de données envoyées en fonction du temps pour l’inversion de convoi. 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.

Moins de 10 ko par seconde sont consommés bien que plus d’amers aient été cartographiés. Comme ils sont envoyés régulièrement, ils ne s’accumulent pas évitant ainsi des gros pics ponctuels.

Les résultats de cette section confirment que notre approche décentralisée est viable. En termes de temps de calcul, un ordinateur portable avec un processeur Intel Core i5 à 2,4 GHz a suffit à le faire fonctionner en temps réel. Les débits réseau sont aussi très faibles et s’accommodent donc bien au nombre de véhicules de la flotte. L’utilisation de capteurs bas coûts n’a pas empêché l’algorithme de donner de bons résultats. Ceux-ci doivent maintenant être validés avec des expérimentations réelles.