Polytech Projets Ge

h1. La navigation autonome

Bien que le paquet de navigation soit conçu pour être aussi polyvalent que possible, trois exigences matérielles principales limitent son utilisation:

* Il est destiné uniquement aux robots à entraînement différentiel et aux robots à roues holonomiques. Il suppose que la base mobile est contrôlée en envoyant les commandes de vitesse souhaitées sous forme de: vitesse x, vitesse y, vitesse thêta.

* Il nécessite un laser planaire monté quelque part sur la base mobile. Ce laser est utilisé pour la création de la cartographie et la localisation du robot.

* Le paquet de navigation a été développé sur un robot carré; ses performances seront donc optimales pour les robots presque carrés ou circulaires. Il fonctionne sur des robots de formes et de tailles arbitraires, mais il peut avoir des difficultés avec les gros robots rectangulaires situés dans des espaces étroits tels que les portes.

On utilisant la pose estimée de Pepper, les points Lasers, la cartographie Pepper peut se déplacer vers une position prédéfinie par l’utilisateur d’une façon autonome en évitant les obstacles. Cette position à atteindre peut être envoyée depuis l’outil RVIZ, ou indirectement à l’aide d’une commande sur le terminal.

Le nœud du paquet de la navigation permet de déterminer le chemin optimal pour aller de la position courante à la position souhaitée. Il détermine aussi la vitesse de déplacement du robot.

***

h2. 1- Le SLAM :

***

La localisation et cartographie simultanées, connue en anglais sous le nom de SLAM (simultaneous localization and mapping) ou CML (concurrent mapping and localization), consiste, pour un robot ou véhicule autonome, à simultanément construire ou améliorer une carte de son environnement et de s’y localiser.

Sous ROS, il existent plusieurs paquets qui développent cette technologie : 

h3. A- Le  paquet Gmapping : "lien":http://wiki.ros.org/gmapping

Ce paquet permet de créer la cartographie 2D d’une zone et la localisation d’un robot.

Il possède un nœud ‘slam_gmapping’ qui permet de créer la carte de grille d’occupation 2D, à partir des données du capteur Laser fournies par le topic /naoqi_driver/laser (de type sensor_msgs/LaserScan) et les données de la position du robot transmises par le topic /naoqi_driver/odom (de type ...).

Pour pouvoir utiliser ce paquet il faut que le robot soit équipé de :

- l’odométrie

- Un télémètre Laser fixé et monté horizontalement.

Le rôle de ce nœud est de transformer les données du Laser en une matrice d’occupation de l’espace qui contient que des 0 et des -1, 0 signifie la présence d’un obstacle et -1 le vide.

Ce nœud possède plusieurs topics

- /map : il renvoi la carte créé, ses données sont de type nav_msgs/occupancyGrid.

- /map_metadata : il renvoi les données relatives au robot sur la carte (la position, l’orientation, la vitesse de déplacement).

Pour créer la carte, il faut lancer le nœud slam_gmapping en choisissant la source des données de type Laser, pour ce faire il suffit de lancer la commande suiante :

<pre> rosrun gmapping slam_gmapping scan:=base_scan _odom_frame:=odom_combined </pre>

Dans notre cas base_scan est le topic /naoqi_driver/laser et la frame d’odométriè est odom, la commande devient alors :

<pre> rosrun gmapping slam_gmapping scan:= naoqi_driver/laser _odom_frame:= odom. </pre>

Voila la cartographie obtenue à l'aide de cette méthode :

!https://forge.clermont-universite.fr/attachments/download/12087/Gmapping_Pepper.png!

Remarque : pour la bonne création de la cartographie il faut éviter la rotation pure de Pepper.

h3. B- Le paquet Hector : "lien":http://wiki.ros.org/hector_slam

Ce paquet est basé sur le même principe du paquet Gmapping sauf que avec celui-ci nous arrivons pas à crée la cartographie.

Même si Pepper possède trois capteurs Lasers horizontaux, il fournissent très peu de points.

L’idée alors est de chercher une autre solution qui ne demande pas l’utilisation des capteurs Lasers ou de cher.

Nous avons deux solutions :

* remplacer les capteurs Lazers du robot Pepper par un lidar plus performant 

* reconstruire les données Lasers 

Nous avons choisit la deuxième solution car il est gratuite et elle ne demande aucune manipulation. 

h3. C- Reconstruction des données Lasers

On utilise la caméra 3D pour avoir les images de profondeur, on les converties ensuite en points Lasers 2D.

Ces points Lasers peuvent être ensuite utilisés pour la construction du la cartographie (SLAM).

Ils existent deux solutions qui permettent cette conversion sous ROS : 

* La première solution : Le paquet depthimage_to_laserscan : "lien":http://wiki.ros.org/depthimage_to_laserscan 

ce paquet permet d’effectué cette conversion Mais seulement pour les les images de profondeur acquises à partir de capteurs 3D fixes et montés horizontalement. Ce qui n’est pas notre cas, car cette caméra et montée sur la tête de Pepper, mais qui ne peux pas rester fixe car la tête de Pepper peut bouger. Cela rend ce paquet inutile. 

* La deuxième solution :

On utilisera donc deux autres paquets, le premier paquet est "depth_image_proc":http://wiki.ros.org/depth_image_proc qui permet de convertir les images de profondeur au Point cloud 3D, le deuxième est "pointcloud to laserscan":http://wiki.ros.org/pointcloud_to_laserscan , il construit  les points Lasers 2D à partir des points cloud 3D.

Voici les résultats obtenues : 

!https://forge.clermont-universite.fr/attachments/download/12096/lasers_reconstruites.png!

***

h2. 2- La localisation du robot 

***

La localisation s’effectue à l’aide des points Lasers 2D, l’odométrie et la cartographie donné par map server. On utilise le paquet AMCL "lien": http://wiki.ros.org/amcl ( Adaptive Monte Carlo Localisation) pour estimer la position de Pepper dans la cartographie. la ligne de commande suivante permet de lancer le noeud amcl fourni par ce paquet et en lui permettant d'accéder aux données lasers fournies par le topic /scan: 

<pre> Rosrun amcl amcl scan:naoqi_driver/laser </pre>

Ce paquet a quatre subscribers : 

* scan : il accède aux données Lasers, le type de message de ce topic est sensor_msgs/LaserScan.

* tf  : il accède aux données des transformations entre repères, le type de message de ce topic est tf/tfMessage.

* initialpose : pour avoir une bonne estimation de la position du robot on fournit sa position initiale à ce subscriber, le type de message de ce topic est geometry_msgs/PoseWithCovarianceStamped.

* Map : le paquet AMCL souscrit à ce topic pour  récupérer la carte utilisée, le type de message de ce topic est nav_msgs/OccupancyGrid.

Il faut donc lancer cette carte en utilisant le nœud map_server et en utilisant la ligne de commande suivante sur un terminal de commandes (1) ou dans un fichier launch (2) : 

<pre> (1) rosrun map_server map_server  mymap.yaml </pre>

<pre> (2) <node pkg="map_server" type="map_server" name="map_server" args="$(find « l’emplacement du  fichier »/ « le nom du fichier ».yaml"> </node>  </pre>

Et trois publishers : 

* amcl_pose : ce topic publie une estimation de la position du robot sur la cartographie avec covariance, le type des messages publiées par ce topic est geometry_msgs/PoseWithCovarianceStamped.

* Particlecloud : Ce topic publie un groupe de points caractérisant le cercle de ressemblance de la position du robot, le type des messages publiées par ce topic est geometry_msgs/PoseArray.

* tf (tf/tfMessage) : ce topic publie la transformation entre les deux repères ‘odom’ et ‘map’.

Voici les résultats obtenues concernant la cartographie crée à l'aide des données lasers reconstruites et l'estimation de la position du robot : 

!https://forge.clermont-universite.fr/attachments/download/12090/localisations_pepper.png!

***

h2. 3- Le paquet navigation 

***

h3. A- La configuration du robot 

!https://forge.clermont-universite.fr/attachments/download/11922/navigation_stack.png!

La pile de navigation suppose que le robot est configuré d'une manière particulière pour pouvoir s'exécuter. Le diagramme ci-dessus montre un aperçu de cette configuration. Les composants blancs sont des composants 

requis déjà implémentés, les composants gris sont des composants facultatifs déjà implémentés et les composants bleus doivent être créés pour chaque plate-forme de robot. Les conditions préalables de la pile de 

navigation, ainsi que des instructions sur la manière de remplir chaque exigence, sont fournies dans les sections ci-dessous.

* 1- ROS

La pile de navigation suppose que le robot utilise ROS. Veuillez consulter la documentation ROS pour savoir comment installer ROS sur votre robot.

* 2-Transformer Configuration (autres transformations)

La pile de navigation nécessite que le robot publie des informations sur les relations entre les cadres de coordonnées à l'aide de tf. Un tutoriel détaillé sur la configuration de cette configuration est disponible ici: "lien":http://wiki.ros.org/navigation/Tutorials/RobotSetup/TF.

Dans notre cas, l'image suivante montre les repères lièes au solides qui appartiennent au robot Pepper : 

!https://forge.clermont-universite.fr/attachments/download/11923/frames_pepper.png!

* 3- Informations sur le capteur (sources de capteurs)

La pile de navigation utilise les informations provenant des capteurs pour éviter les obstacles dans le monde. Elle suppose que ces capteurs publient des messages sensor_msgs / LaserScan ou sensor_msgs / PointCloud sur

ROS. En outre, un certain nombre de capteurs dotés de pilotes ROS prennent déjà en charge cette étape. 

* 4-Informations sur l'odomètre (source d'odométrie)

La pile de navigation nécessite la publication des informations d'odométrie à l'aide de tf et du message nav_msgs / Odometry. Un tutoriel sur la publication des informations d'odométrie est disponible à l'adresse suivante: "lien":http://wiki.ros.org/navigation/Tutorials/RobotSetup/Odom.

* 5- Contrôleur de base :

La pile de navigation suppose qu'elle peut envoyer des commandes de vélocité à l'aide d'un message geometry_msgs / Twist supposé se trouver dans le cadre de coordonnées de base du robot dans le topic  " /cmd_vel". Cela signifie qu'un nœud doit être abonné au topic "cmd_vel" capable de prendre (vx, vy, vtheta) <==> (cmd_vel.linear.x, cmd_vel.linear.y, cmd_vel.angular.z). et les convertir en commandes de moteur à envoyer à une base mobile. 

* 6- La cartographie (serveur_map)

La pile de navigation n’a pas besoin de carte pour fonctionner, mais pour les besoins de ce tutoriel, nous supposerons que vous en avez une. 

"navigation_stack.png":https://forge.clermont-universite.fr/attachments/download/11922/navigation_stack.png 

"frames_pepper.png":https://forge.clermont-universite.fr/attachments/download/11923/frames_pepper.png 

"Gmapping_Pepper.png":https://forge.clermont-universite.fr/attachments/download/12087/Gmapping_Pepper.png 

"localisations_pepper.png":https://forge.clermont-universite.fr/attachments/download/12090/localisations_pepper.png 

"lasers_reconstruites.png":https://forge.clermont-universite.fr/attachments/download/12096/lasers_reconstruites.png