Noms et réseau
==============

**S'applique à :** :bdg-info-line:`Simulation` :bdg-warning-line:`Robot réel`

Plusieurs robots partagent le même réseau sans se confondre. Trois idées
suffisent pour s'y retrouver : le **numéro** du robot, le **domaine ROS** et
les **repères** de position.

Le numéro du robot
------------------

Chaque robot porte un numéro ``N``, de 1 à 19. Tout ce qui le concerne en
découle :

.. list-table::
   :header-rows: 1
   :widths: 40 60

   * - Quoi
     - Pour le robot 2
   * - le nom de son Raspberry Pi
     - ``ratbot-2``
   * - son adresse réseau
     - ``192.168.1.172`` — toujours ``192.168.1.(170 + N)``
   * - ses topics
     - ``/ratbot_2/scan``, ``/ratbot_2/base/cmd_vel``…
   * - ses repères de position
     - ``ratbot_2/base_link``, ``ratbot_2/odom``…
   * - dans les commandes
     - ``./scripts/ratbot slam 2``, ``nav 2``…

Ce qui est commun à tous les robots, comme l'arrêt de tout le parc depuis la
manette, vit sous ``/ratbot_fleet/``. En simulation, les robots sont numérotés
à partir de 1, comme les vrais (voir :doc:`flotte`).

.. note::

   Le **nom de la machine** décide de son rôle : ``ratbot-2`` est le robot 2,
   toute autre machine est un PC. ``./scripts/ratbot role`` affiche ce que la
   machine croit être.

Le domaine ROS
--------------

Les machines ROS 2 ne se voient que si elles partagent le même **domaine**, un
numéro fixé par la variable ``ROS_DOMAIN_ID``. Tous les robots, le PC et le
conteneur Docker utilisent le domaine **77**.

Conséquence : une simulation lancée dans le domaine 77 se mélangerait aux vrais
robots allumés, puisqu'elle utilise les mêmes noms. ``./scripts/ratbot up``
refuse donc de démarrer si un robot réel répond. Pour simuler à côté, changez
de domaine dans chaque terminal de la simulation (voir :doc:`simulation`) :

.. code-block:: bash

   export ROS_DOMAIN_ID=0

Les repères de position
-----------------------

La position du robot s'exprime dans une chaîne de **repères** :

.. tikz:: La chaîne des repères : la carte, l'odométrie, le robot.
   :libs: arrows.meta, positioning

   \tikzset{
     repere/.style={draw, rounded corners, thick, minimum width=30mm,
                    minimum height=10mm, font=\ttfamily},
     lien/.style={-{Stealth[length=3mm]}, thick},
     note/.style={font=\small, align=center}
   }
   \node[repere, fill=blue!8]                     (map)  {map};
   \node[repere, fill=green!8,  right=24mm of map]  (odom) {odom};
   \node[repere, fill=orange!12, right=24mm of odom] (base) {base\_footprint};

   \node[note, below=2mm of map]  {la carte};
   \node[note, below=2mm of odom] {l'odométrie};
   \node[note, below=2mm of base] {le robot};

   \draw[lien] (map) -- node[note, above=1mm] {correction\\du lidar} (odom);
   \draw[lien] (odom) -- node[note, above=1mm] {roues\\+ gyroscope} (base);

- ``odom`` → ``base_footprint`` : ce que le robot compte avec ses roues et son
  gyroscope. Précis sur quelques mètres, mais il dérive peu à peu ;
- ``map`` → ``odom`` : la correction apportée par le lidar, publiée par la
  cartographie ou la navigation.

RViz affiche le robot dans l'un de ces repères (le *Fixed Frame*). Un
« No transform » dans RViz veut presque toujours dire que le repère choisi
n'existe pas encore (voir :doc:`rviz`). En simulation, un repère de plus, la
**vérité terrain**, donne la position exacte du robot (voir :doc:`simulation`).