Navigation autonome ==================== **S'applique à :** :bdg-info-line:`Simulation` :bdg-warning-line:`Robot réel` Déplacement autonome vers une pose de but sur une carte connue, avec évitement d'obstacles. La pile utilisée est **Nav2**. Cartographie et navigation -------------------------- .. list-table:: :header-rows: 1 :widths: 20 40 40 * - - Cartographie (SLAM) - Navigation (Nav2) * - Carte - construite en ligne - chargée depuis un fichier * - Pose - estimée conjointement à la carte - estimée par AMCL dans la carte * - Objectif - couvrir l'environnement - atteindre une pose donnée * - Commande - téléopération - autonome Une carte préalable est donc nécessaire : voir :doc:`carte`. En simulation, les exemples ci-dessous utilisent le décor ``rooms`` et sa carte, fournis avec le dépôt. Composants ---------- **Localisation (AMCL)** — filtre particulaire. Un ensemble d'hypothèses de pose est propagé par l'odométrie, puis pondéré par la vraisemblance des mesures lidar au regard de la carte ; les hypothèses improbables sont éliminées par rééchantillonnage. AMCL publie la transformation ``map → odom`` ; RViz affiche la pose qui en résulte. Les particules elles-mêmes ne sont pas affichées par la configuration fournie : pour les voir, ajouter dans RViz un affichage **ParticleCloud** (Nav2) sur le topic ``/ratbot_1/particle_cloud``. AMCL doit savoir à quel point se fier à l'odométrie. En simulation, elle est presque exacte et AMCL s'y fie beaucoup ; sur le robot réel, il reste prudent. Le choix est automatique. En simulation, la position estimée est à 1 ou 2 cm près en moyenne, 5 cm au plus. **Cartes de coûts** — la carte statique est augmentée de deux couches d'obstacles, alimentées en direct par le **lidar** et par le **capteur de distance avant** (:doc:`tof`), qui voit les obstacles trop bas pour le lidar ; puis d'une couche d'inflation qui étend le coût autour des obstacles, afin de tenir compte de l'encombrement du robot. La carte de coûts **globale** couvre la carte entière et sert à la planification ; la carte de coûts **locale**, fenêtre glissante de 3 × 3 m, permet la réaction aux obstacles non cartographiés. .. note:: Jusqu'au 2026-10-14, les cartes de coûts ne recevaient **pas** le lidar : elles écoutaient un topic que personne ne publie, et Nav2 ne connaissait que la carte statique. Une navigation antérieure à cette date n'évitait donc aucun obstacle absent de la carte. **Planification** — calcul d'un chemin dans la global costmap (NavFn). Le chemin est **recalculé toutes les 10 s**, ou plus tôt si le but change ou si un obstacle le rend invalide. Recalculé chaque seconde, il basculait d'un côté à l'autre d'un obstacle quand deux routes se valaient, et le robot faisait demi-tour à chaque bascule ; recalculé seulement quand il devenait invalide, un robot coincé dans l'encadrement d'une porte ne se voyait jamais proposer d'autre chemin. La marge autour des obstacles est de **25 cm**. Le centre du robot, pour la navigation, est sur l'axe des roues, tout près de l'avant ; la coque déborde de 8 cm sur les côtés et de 13 cm à l'arrière, et c'est cette marge qui l'éloigne des obstacles. Une porte de 0,7 m passe. **Suivi de trajectoire** — génération des consignes de vitesse suivant ce chemin (*Regulated Pure Pursuit*), à fréquence élevée et en tenant compte de la local costmap. Prérequis --------- .. tab-set:: :sync-group: env .. tab-item:: Simulation :sync: sim Le PC prêt (:doc:`installation`) et une carte du décor simulé. Le dépôt en fournit trois, dans ``ros2_ws/src/ratbot_maps/maps/`` : ``rooms.yaml``, ``hampton_signature.yaml`` et ``tables.yaml``. .. tab-item:: Robot réel :sync: reel Le PC prêt (:doc:`installation`), le robot allumé, et une **carte de la pièce faite avec ce robot** (:doc:`carte`). Reposez le robot sur le marquage de départ de la carte : c'est là que la localisation le suppose au lancement. .. note:: Essayée sur le vrai robot : le 2026-10-16 dans un enclos de planches (neuf buts atteints, contournement d'une boîte), et le 2026-10-19 dans un couloir (quatre demi-tours à 20 cm d'un mur, sans contact). Pas encore dans une pièce meublée. Étape 1 — lancer la navigation ------------------------------ .. tab-set:: :sync-group: env .. tab-item:: Simulation :sync: sim Dans un premier terminal, depuis la racine du dépôt, la simulation avec le décor ``rooms`` : .. code-block:: bash ./scripts/ratbot up rooms ground_truth_tf:=false .. important:: ``ground_truth_tf:=false`` est obligatoire : ``map → odom`` doit être publiée par la localisation seule. Voir :doc:`simulation`. Si elle manque, ``./scripts/ratbot nav`` refuse de démarrer et le rappelle. Dans un second terminal, la navigation : .. code-block:: bash ./scripts/ratbot nav 1 En simulation, la commande charge d'elle-même la carte du décor en cours, celle qui porte son nom (ici ``rooms``), et se règle sur l'heure de la simulation. Un décor sans carte est signalé, avec la liste des cartes disponibles. Pour en choisir une autre : ``./scripts/ratbot nav 1 NOM``. .. tab-item:: Robot réel :sync: reel Depuis le PC, robot allumé : .. code-block:: bash cd ~/ratbot_ws ./scripts/ratbot nav 1 salon ``salon`` est le nom donné à la carte en l'enregistrant (voir :doc:`carte`) ; ``./scripts/ratbot map list`` liste les cartes. La commande vérifie que le robot est visible, puis lance la localisation, Nav2 et RViz. Si le Wi-Fi coupe pendant un trajet, le robot **s'arrête de lui-même** : sa carte coupe les moteurs une demi-seconde après le dernier ordre reçu. Dans les deux cas, ce lancement démarre le serveur de carte, la localisation (AMCL), la pile Nav2 et RViz préconfiguré. Le robot vise **0,17 m/s** en ligne droite, passe au milieu des couloirs quand il y a la place, ne ralentit qu'à moins de 30 cm d'un obstacle, et ne tient compte des obstacles que **jusqu'à 5 m** : au-delà, les mesures du lidar sont trop rares pour être fiables. Un but est atteint quand le robot en est à **7 cm** près (15 cm jusqu'au 2026-10-16 : il s'arrêtait 12 cm avant chaque but). .. note:: **Le robot se garde toujours la place de tourner.** Il pivote sur l'axe de ses roues, près de son avant : en tournant sur place, son arrière décrit un cercle de 15 cm. La navigation le traite donc comme un **disque de 16 cm de rayon** autour de cet axe. Conséquence : un but placé à **moins de 16 cm d'un mur** (mesurés depuis l'axe des roues) n'est pas atteint exactement. Le robot s'arrête au point sûr le plus proche, parfois à 15 ou 20 cm du point cliqué, et annonce pourtant le but atteint. Pour arriver au centimètre près, placez le but à plus de 16 cm des obstacles. .. Capture d'écran à insérer : RViz au lancement (carte « rooms » + robot). Déposez _static/navigation/nav-demarrage.png puis décommentez le bloc ci-dessous (retirez le préfixe « .. » devant chaque ligne) : .. .. image:: _static/navigation/nav-demarrage.png .. :align: center .. :width: 90% Étape 2 — pose initiale ----------------------- AMCL initialise la pose à l'origine de la carte. Si le robot démarre ailleurs, les mesures lidar ne coïncident pas avec les murs de la carte. Utiliser l'outil **2D Pose Estimate** : cliquer sur la position réelle du robot et faire glisser dans la direction de son orientation. Le robot se replace sur la carte, et les mesures lidar retombent sur les murs. Une carte faite par ``ratbot slam`` a pour origine la place du robot **au lancement de la cartographie** : si on l'a déplacé depuis, la pose initiale est fausse. Dans un petit espace dont le lidar voit tout le contour (un enclos), AMCL peut se recaler de lui-même ; dans une pièce, donner la pose. Attention aux lieux symétriques (un rectangle) : vérifier que le robot regarde dans la bonne direction sur la carte. .. Capture d'écran à insérer : recalage avec l'outil « 2D Pose Estimate ». Déposez _static/navigation/nav-pose-estimate.png puis décommentez le bloc ci-dessous (retirez le préfixe « .. » devant chaque ligne) : .. .. image:: _static/navigation/nav-pose-estimate.png .. :align: center .. :width: 90% Étape 3 — envoi d'un but ------------------------ Outil **2D Goal Pose** : cliquer le point d'arrivée et faire glisser pour définir l'orientation finale. Le chemin planifié s'affiche, et le robot le suit. .. Capture d'écran à insérer : un but donné (« 2D Goal Pose ») + chemin vert + robot en route. Déposez _static/navigation/nav-goal-chemin.png puis décommentez le bloc ci-dessous (retirez le préfixe « .. » devant chaque ligne) : .. .. image:: _static/navigation/nav-goal-chemin.png .. :align: center .. :width: 90% Équivalent en ligne de commande : .. code-block:: bash ros2 topic pub -w 1 -1 /ratbot_1/goal_pose geometry_msgs/msg/PoseStamped \ "{header: {frame_id: map}, pose: {position: {x: 1.0, y: 0.0}, orientation: {w: 1.0}}}" ``-w 1`` attend que la navigation écoute avant d'envoyer le but : sans lui, le message part avant d'être entendu, et il est perdu sans erreur. .. tip:: Le but doit se situer dans une zone libre. Un but dans un obstacle ou en zone inconnue est rejeté. Une pose trop proche d'un mur peut également être inatteignable du fait du rayon d'inflation. Priorité et sécurité -------------------- La sortie de Nav2 est publiée sur ``base/cmd_vel_nav``, entrée de **priorité la plus basse** de l'arbitre (voir :doc:`interface_ros`) : .. code-block:: text téléopération (priorité haute) ─┐ navigation autonome (priorité basse) ─┴─► twist_mux ─► limiteur ─► garde-barrière La téléopération reprend donc la main sans qu'il soit nécessaire d'arrêter la navigation. L'arrêt d'urgence global s'applique également à la navigation : .. code-block:: bash ros2 topic pub --qos-reliability reliable --qos-durability transient_local \ /ratbot_fleet/emergency_stop std_msgs/msg/Bool "data: true" Diagnostic ---------- **Aucune réaction au clic sur un but** Vérifier l'outil utilisé (**2D Goal Pose**, non *2D Pose Estimate*), la validité du but (zone libre), puis la réception : ``ros2 topic echo /ratbot_1/goal_pose``. **Trajectoire aberrante, robot désorienté** Pose initiale erronée : recaler avec *2D Pose Estimate*. Sur le robot réel, vérifier qu'il est parti de son marquage de départ ; en simulation, que ``ground_truth_tf:=false`` a bien été passé. **Chemin planifié mais robot immobile** Sur le robot réel : voyant orange ou rouge, le robot est arrêté — voir :doc:`arrets`. En simulation : batterie simulée vide, ou incohérence d'horloge (voir :doc:`depannage`). **Mesures lidar décalées, affichage en retard** En simulation : accès à la carte graphique manquant dans le conteneur, voir :doc:`docker`. Sur le robot réel : montage du lidar, voir :doc:`lidar`. Voir aussi ---------- - :doc:`flotte` — la navigation de plusieurs robots dans une carte commune, et ses limites actuelles ; - :doc:`exploration` — l'exploration autonome, qui combine la navigation et la cartographie.