Ce projet à été réalisé dans le cadre du cours de robotique autonome de l'ENSTA. Pour allier l'utile à l'agréable, nous avons choisi de réaliser, dans le cadre de ce cours, un projet qui fournisse également un des composants logiciels du robot d'enstaR.
La localisation jouant un rôle crucial à la Coupe de France de robotique, et étant un des point majeurs du cours, nous nous proposons de réaliser le module de localisation du robot, par des méthodes de filtrage Bayésien. Après une présentation de notre plateforme, de son environnement à la Coupe et des contraintes associées, nous décrirons la solution que nous nous proposons de réaliser, ainsi que l'architecture envisagée de cette réalistion.
Par manque de temps nous vous invitons à vous reporter à notre dossier d'avant projet pour tout ce qui concerne la spécification du problèmes.
Dans la mesure où ce code doit survivre au projet, et être utilisé au sein de l'équipe d'enstaR, une certaine attention à été portée sur des aspects de génie logiciel, au détriment de la rapidité de prototypage. Une bonne séparation entre le coeur de l'algorithme, son paramétrage et l'inetrfaçage avec Player/Stage était notamment impératif.
Nous nous sommes par ailleurs effrocés de séparer l'algorithme du modèle d'observation et du modèle d'évolution, tout en repoussant de nombreux petit utilitaires dans des classe séparées (manipulation des nombres aléatoires, des angles, des repères orientés du plan, ...), en ayant en esprit de restructurer le code pour réellement tiliser de la programmation générique à moyen terme. Enfin nous avons utilisé un design pattern Adaptateur afin de connecter notre algorithme à Player/Stage ; il est à noter que c'est également cet Adaptateur qui gère tout l'affichage.
Le filtre particulaire réalisé répond à une modélisation assez simple qui se traduit par :
Chose assez étonnante pour un développement en C++ qui fait appel à du logiciel tiers, la développement n'a pas posé de problèmes majeurs de bugs (sauf en ce qui concerne une sombre affaire de datamode non élucidée) mais cette fiabilité à été obtenue au prix d'un cycle de développement incrémental particulièrement lent, et qui explique en partie les délais du prpojets...
Le code s'appuie sur la Gnu Scientific Library pour ce qui est des nombres aléatoires, fait appel à pkg-config pour l'utilisation de Player/Stage, mais ne fait pas appel à des bibliothèques extérieures comme Bayes++ comme celà avait temporairement été envisagé.
En outre le code de l'Adaptateur devait simuler les données renvoyées par les balises, dans le mesure ou ce système est propre au robot d'enstaR et n'est pas pris en charge par Player/Stage. Ceci demandait donc d'obtenir de PLayer/Stage la position exacte du robot, et par conséquent il nous a fallu simuler également à la mainle bruit sur les capteurs odométriques.
Que ce soit pour les capteurs odométrique ou pour les balises, nous avaons retenu un bruit gaussien de variance paramétrable, qui s'applique sur les valeur renvoyées par les capteurs odométriques (ie rotation de chacun des roues) ou sur les valeurs des angles renvoyés par le système de balises.
On présentera d'abord quelques vidéo du comportement observé du filtre, avant de proposer quelques améliorations..
| Vidéo 1 et Vidéo 2 | ||
| Bruit sur les codeurs odométriques | 0.02 | tour de roue (écart type) |
| Bruit sur la détection de balises | 2 | degré (écart type) |
| Modèle des codeurs odométriques | 0.50 | tour de roue (écart type) |
| Modèle de la détection de balises | 10 | degré (écart type) |
| Nombre total de particules | 600 | |
| Nombre de particules aléatoires | 100 | |
| Vidéo 3 | ||
| Bruit sur les codeurs odométriques | 0.1 | tour de roue (écart type) |
| Bruit sur la détection de balises | 5 | degré (écart type) |
| Modèle des codeurs odométriques | 0.50 | tour de roue (écart type) |
| Modèle de la détection de balises | 10 | degré (écart type) |
| Nombre total de particules | 600 | |
| Nombre de particules aléatoires | 100 | |
| Vidéo 4 | ||
| Bruit sur les codeurs odométriques | 0.1 | tour de roue (écart type) |
| Bruit sur la détection de balises | 5 | degré (écart type) |
| Modèle des codeurs odométriques | 0.50 | tour de roue (écart type) |
| Modèle de la détection de balises | 10 | degré (écart type) |
| Nombre total de particules | 600 | |
| Nombre de particules aléatoires | 0 | |
La récupération sur colision (ici simulé par un déplacement brutal à la souris du robot dans le monde simulé) ne se passait pas très bien car les particules étaient trop concentrées par le ré-échantillonage d'une part et le fait que même avec une variance importante le modèle d'évolution n'autorisait pas de déplacement latéral. Nous avons donc ajouté un certain taux de particules qui sont régénérées au hasard dans tout le terrain. On peut voir sur la vidéo 4 se qui se passait avant cette modification.
Une autre possibilité plus pertinante serait d'utiliser un modèle d'évoltion entièrement découplé du modèle de simulation de l'odométrie. Plus spécidifquement au lieu d'appliquer un bruit gaussien sur chacun des capteurs odométriques, on appliquerait trois bruit gaussiens différentes selon la direction tangente à la trajectoire, la direction normale et l'orientation.