RobAIR/SLAM

De fablab
Aller à : navigation, rechercher

Avancement du projet

Séance du 14/02/2013

On commence par un peu de recherche documentaire. On rassemble tout dans uncarnet evernote publics.

Quelques trouvailles, intéressantes:

Séance du 16/02/2013

Rencontre au fablab avec l'équipe de pilotage. Au menu:

  • Un peu de groking: fait quelques tutos présents sur le le wiki de ROS
  • Une vaine tentative d'installer ROS sur les machines du fablab: on a demandé les droits sudo, à suivre.

Quelques objectifs pour la prochaine fois:

  • comprendre le format pgm utilisé pour la construction des cartes par Gmapping
  • voir comment gmapping gère le SLAM
  • continuer à se documenter sur le SLAM pour voir ce qu'on peut faire avec les moyens mis à notre disposition (Kinect, peut être Lidar).


Séance du 19/02/2013

On est parvenus à écrire un fichier pgm. Un simple carte carrée générée en C++. Le git du projet est sur: ensibm:/equipes/fablab_slam.git

On a échangé avec l'équipe de Polytech'Grenoble chargée de l'architecture.Pour eux, le SLAM est encore difficile à positionner, ils ne savent pas encorede quelles données on a besoin. Il ont récupéré un documentSlam for dummies qui contient la théorie.


Beaucoup de choses mises au clair par rapport au fonctionnement de ROS et la façon dont on doit procéder. Il y a encore certains flous qui persistent quant à là où s'arrête notre travail et où commence celui de l'équipe de pilotage.


Il faut suivre leur wiki ici. Pour les autres équipes: ici Compte rendu de la réunion (Merci Michel :)


03/03/2013

Bref échange avec @mentar sur #ros [irc.oftc.net], sur les possibilités qu'on a pour faire du slam avec une kinect. Conclusion: avec un kinect seule, c'est très très difficile (cf. vslam), mais si on s'aide d'odométrie, c'est possible.Il faut voir si on peut utiliser les Wheel EncodersQuelques liens

Séance du 05/03/2013

Premier temps

On a continue à exporer les possiblités qu'on a niveau SLAM.On a fabriqué un carte de test (un simple carré avec quelques obstacles dessus).


Pour prendre en compte le positionnement des individus et leur mouvement, ilfaut essayer de prédir leur trajectoire et dessiner un perimètre de sécuritéautour d'elle (périmètre que le robot doit éviter). On a créé une ensemble carte avec des obstacles représentant des personnes enmouvement continu. On a implémenté un algo qui permet de faire cetteprédiction et décrire le rayon de ce périmètre de sécurité. On voulait aussiestimer la gourmandise en ressources d'un tel algo. Bien qu'on ne connaisse pasprécisément les spécificités matérielles dont sera équipées le robot, on peutimaginer qu'un algorithme très gourmand en mémoire et en calcul n'est pas unesolution viable.

Deuxième temps

Après échange avec quelques membres de l'autre équipe, on aremis un peu les idées en ordre. On pensait devoir gérer les personnes enmouvement et fournir une carte dynamique (sous forme de flux peut-être) àl'équipe de pilotage, pour qu'elle ne se charge que du pilotage.

Cette idée abandonnée, on se concentre donc sur le placement des objets (plusou moins mobiles) sur une carte minimale du musées (constituées des murs etpeut être de quelques objets complétement amovibles, mais sans plus).


Séance du 14/03/2013

Retour sur conclusions faites lors de la dernièrerencontre. Pour la construction de la map, on utilisera

  • les données de la kinect pour les courtes distances l'odometrie, plus précise
  • sur les longues distances un système de repérage absolu, pour corriger les
  • écarts inévitables avec les méthodes odométriques
Traitement des données de la Kinect
Exploitation des données ordometriques

Voir si c'est possible en pratique.Après des pas mal de recherches et lectures, on ne peut certainement pas compter sur la Kinect seule. (cf. vslam). Mais l'odometrie pose des problèmes de précision aussi, remarquables sur les longs parcours. On peut supposer par exemple que si le sol du musée, bien que sur un seul niveau, peut ne pasêtre parfaitement plat (tapis, evacutations, etc.)

Il faut donc qu'un recalibrage puisse être fait de façon régulière, par un système de repérageabsolu.

Repérage absolu

On peut imaginer plusieurs systèmes de repérage absolu. Quel qu'il soit, il doit pouvoir renseigner le robot à un intervalles réguliersur sa position, c'est à dire ses coordonnées ponctuelles sur la map "nue" du musées (celle ne contenant que les murs, sans les objets fixes ou mouvants eventuels) son orientation sur cette carte, afin de faire une correspondance entre la scène renvoyées par la kinect et la carte construite par le robot.

La solution que nous avons retenue était d'utiliser des QR codes positionnéssur le sol du musée à intervalles réguliers. Les QR codes présentent d'abord les caractéristiques recherchées:

  • ils peuvent encoder l'information (x,y,alpha) qui renseigne le robot sur sa position. Chaque QR code serait unique et lié à sa position sur la map du musée. ils ont un "sens de lecture", ce qui permet au robot d'interpréter ladonnée angle "alpha"
  • ils ne nécessites pratiquement rien pour être lus, si ce n'est une camera. On ne sait pas encore si on peut utiliser l'image de la Kinect à la fois pour lire ce QR code. Un scanner placé sous le robot.
On partage le projet en deux grandes parties
  1. Simulation du repérage absolu + odométrique sur turtle
  2. Traitement de l'information Kinect pour construire une carte d'un point de vue fixe (dans un premier temps)


Séance du 23/03/2013

On a un horaire fixe hebdomadaire: Mardi 15:30. Venez nous voir!

Debriefing commun sur l'avancement de chacun

On cherche encore à simuler l'odometrie sur turtle sim. On peut récupérer l'image de la kinect et la colorer en fonction de la distance des objets.

Plus à propos de l'algorithme d'analyse de l'image de la kinect

Pour alléger l'analyse, on ne va pas analyser tous les pixels de l'image. Une première approche a été de découper la scène en lignes tous les 10px (par exemple). Si on diminue considérablement le nombre de lignes à analyser, on peut aussi "oublier" certains objets de la scène.

Contre-exemple auquel on peut penser : table dont on capturera les pieds sans la surface (car aucune ligne n'est passée dessus). Il faut donc envisager de combiner ça avec des lignes verticales. => A voir où les positionner.

L'estimation des distances est une autre partie de l'algorithme gourmande en ressources (notamment le calcul de arctan). On a pensé utiliser une table de hachage qui pré-calcule les valeurs et les réutilise pour chaque ligne.

Petit knowledge transfer sur :
  1. Utilisation des informations de nodes stockées dans des fichiers .bag
  2. Utilisation des branches dans git


Séance du 02/04/2013

Le lidar

Visualisation du signal du lidar dans rviz


Récéptionné le 26/03

Pour le reste

  • voir comment on peu étendre l'algo de detection d'objets pour l'utiliser sur des images plus "compliquées" (et de moins bonne qualité)
  • voir avec l'équipe de polytech sous quel format on peut récupérer des données d'odométrie.

Séance du 10/04/2013

Le parser yaml, utilisé pourcontourner l'erreur à l'exectution qu'on a en récupérant les message depuis lakinect, s'avère trop long. Il est inutile maintenant.

On récupère les données sur/camera/depth/image_raw mettre les maps retournée sous le formatchar* map, structure complète et à définir plutard, avec toutes lesinformations nécessaires.


Séance du 17/04/2013

Changement de direction

On a trouvé mieux que notre algo pour analyser l'image de la kinect. L'astuce est de transformer le signalde la kinect en signal laser pour pouvoir le faire fonctionner avec les algos de slam qui existent déjà et fonctionnenentbien avec un lidar (comme Hector Slam ou Gmapping).

Il y a un noeud qui peut faire ça: pointcloud to laserscan. Ce noeud récupère directement le signal sur le topic Modèle:FIXME de la kinect et publie le signal converti sur le topic laser_scan On peut le visualiser avec Rviz.

Utilisation

Il faut commencer par créer un [launch file] qui relies les topics entre eux. Download this file, name it openni_laser.launch and put it in

/opt/ros/fuerte/stacks/turtlebot/pointcloud_to_laserscan/launch

the simplest way to do this is

roscd pointcloud_to_laserscan
mkdir launch
wget http://goo.gl/qlf7V

Now you're all set ready to launch it

$ roslaunch pointcloud_to_laserscan openni_laser.launch & 
$ rosrun rviz rviz &

Download this configuation file put it inside ~/.rviz and load it from rviz.

Les limites de cette approche

  • on ne peut pas la tester en vrai cargmapping nécessite des données d'odométrie.
  • si on choisit de partir sur HectorSlam, on n'aura pas besoin des données odométriques. Il fautvoir parcontre si les caractéristiques du signal de la kinect (densité,étendue...) sont suffisantes pour l'algorithme de slam. (cf. [Utilisation de pointcloud_to_laser] pour les détails sur les différences observées entre lessignaux du lidar et de la kinect)
  • voir comment on peut fairefonctionner Hector Slam avec une carte préexistante

Séance du 17/04/2013

Repérer le robot dans le musée

  • On a besoin de pouvoir reprérer le robot sur une carte initiale (carte simplifiée du musée).

Ce problème peut être résolu à l'aide d'un autre paquet, amcl. Ce paquet doit être initialisé avec des conditions initiales.

Séance du 19/04/2013

Le launch file pour démarrer Hector_slam avec la Kinect fonctionne (à peu près)... Une version fonctionnelle sera uploadé. Il a été découpé en deux pour prendre en compte le temps de lancement des pilotes de la kinect. Ca reprends dans les grandes lignes le launch file du pointcloud_to_lasercan avec quelques adaptations.

Pas avancé avec AMCL.

Séance du 07/05/2013

Un peu de digging dans le node AMCL:

  • il y a un fonctionnalité "safe zone" qui en gros permet de repérer les obstacles et décrire une marge de sûreté autour, ça peut peut-être suffire pour le pilotage automatique.
  • on a commencé à écrire un node initializer qui permet de réinitialiser AMCL avec des coordonnées (passées par une source de positionnement abolu, anciennement les QR code, mais qu'importe). Ca ne marche pas encore parce qu'en pratique, il ne faut pas juste lui passer, (x, y, alpha), mais aussi une matrice de covariance.

Références

Modèle:Reflist

Quelques liens