Installer le Raspberry Pi ========================= **S'applique à :** :bdg-warning-line:`Robot réel` Cette page installe le logiciel embarqué sur le **Raspberry Pi d'un robot**. Elle fait partie de la mise en service d'un robot neuf : suivez-la dans l'ordre donné par :doc:`nouveau_robot`. Pour préparer le PC, voir :doc:`installation`. Mettre en service un Raspberry Pi --------------------------------- Tout passe par une **fiche d'identité**, un petit fichier YAML qui décrit *ce* robot, et une seule commande. .. code-block:: bash cp deploy/ratbot.example.yaml mon-robot.yaml $EDITOR mon-robot.yaml .. code-block:: yaml robot_id: 2 # -> ratbot-2, /ratbot_2/, 192.168.1.172 version: 1 network: gateway: 192.168.1.254 # la box du réseau time_server: 192.168.1.190 lidar: true ros_distro: humble L'adresse du robot ne se donne pas : elle découle de son numéro, ``192.168.1.(170 + N)``. Une fiche qui en indique une autre est refusée. Puis, **sur la Raspberry** : .. code-block:: bash ./scripts/ratbot install mon-robot.yaml --dry-run # ce qu'il ferait ./scripts/ratbot install mon-robot.yaml .. tip:: Le script est **idempotent** : relancez-le autant de fois que vous voulez, il ne refait que ce qui manque. C'est aussi la façon de vérifier qu'une installation a bien pris. Il ne redémarre **jamais** la machine. Il vous dit ce qui reste à faire. Les deux façons d'installer --------------------------- **Carte neuve**, écrite par Raspberry Pi Imager. Renseignez le WiFi *dans l'imageur* — le script ne s'en occupe pas et aucun mot de passe n'entre dans la fiche d'identité. Le compte du robot, à créer dans l'imageur, est le même sur tous les robots du parc : .. list-table:: :widths: 30 70 * - utilisateur - ``ratbot`` * - mot de passe par défaut - ``chang3m3`` .. warning:: **Ce mot de passe est public** : il est écrit ici. Changez-le dès la mise en service (``passwd`` sur le robot), surtout si le réseau du robot n'est pas isolé. Les outils du parc n'en ont pas besoin : ils passent par une **clé SSH** (``ssh-copy-id ratbot@192.168.1.17N``, voir :doc:`flotte`). Il ne sert qu'à la première connexion et aux commandes ``sudo``. **Clone d'une carte existante**, la méthode rapide pour équiper un parc. Le script détecte que la machine porte encore l'identité de l'ancien robot et **efface ce qui ne doit surtout pas être partagé** : .. list-table:: :header-rows: 1 :widths: 34 66 * - Ce qui est régénéré - Sinon * - ``/etc/machine-id`` - deux machines identiques obtiennent le **même bail DHCP** et se coupent l'une l'autre * - clés d'hôte SSH - deux robots avec la même empreinte ; les clients refusent la connexion en criant à l'attaque * - nom de machine - il décide de tout le reste : espace de noms ROS, adresse fixe * - adresse fixe netplan - celle de l'ancien robot .. warning:: Après un clonage, vos clients SSH signaleront un **changement de clé** pour cette adresse. C'est normal et voulu. Retirez l'ancienne entrée : .. code-block:: bash ssh-keygen -R 192.168.1.172 Cloner une carte, pas à pas ~~~~~~~~~~~~~~~~~~~~~~~~~~~ C'est la méthode conseillée pour un nouveau robot : ROS 2 et l'agent micro-ROS sont déjà installés et compilés sur la carte d'origine, ce qui évite une longue compilation sur la Raspberry. Les exemples clonent ratbot-1 pour faire ratbot-2. **1. L'image de la carte d'origine**, une fois. Mettre son dépôt à jour, puis l'éteindre proprement : .. code-block:: bash ssh ratbot@192.168.1.171 'cd ~/ratbot_ws && git pull --ff-only' ssh -t ratbot@192.168.1.171 'sudo shutdown now' Retirer la carte SD, la mettre dans le lecteur du PC, et en faire une image : .. code-block:: bash lsblk # repérer la carte, par exemple /dev/sdb sudo dd if=/dev/sdX of=ratbot1.img bs=4M status=progress .. danger:: **Vérifier trois fois le nom du périphérique** (``/dev/sdX``) avec ``lsblk`` : la carte se reconnaît à sa taille. ``dd`` écrit sans rien demander, et une erreur de nom efface un disque du PC. **2. L'écrire sur chaque nouvelle carte**, au moins aussi grande que l'originale : .. code-block:: bash sudo dd if=ratbot1.img of=/dev/sdY bs=4M status=progress conv=fsync Raspberry Pi Imager sait aussi écrire ce fichier (« Use custom »). **3. Donner son identité au nouveau robot.** Au premier démarrage, le clone se croit encore ratbot-1, à la même adresse : .. warning:: **Le robot d'origine reste éteint** tant que le clone n'a pas reçu son identité : deux machines à la même adresse et sous le même nom se coupent l'une l'autre. Brancher le lidar du nouveau robot (sa règle udev dépend du matériel réellement branché), y mettre la carte, l'allumer, puis depuis le PC : .. code-block:: bash ssh ratbot@192.168.1.171 # le clone, encore sous l'identité de ratbot-1 cd ~/ratbot_ws cp deploy/ratbot.example.yaml ratbot2.yaml # robot_id: 2 ./scripts/ratbot install ratbot2.yaml --dry-run ./scripts/ratbot install ratbot2.yaml sudo reboot Après le redémarrage, le robot répond à sa propre adresse, ``192.168.1.172``. Sur le PC, retirer les empreintes devenues fausses : .. code-block:: bash ssh-keygen -R 192.168.1.171 ssh-keygen -R 192.168.1.172 Le robot d'origine peut alors être rallumé. Recommencer l'étape 2 et 3 pour chaque robot, avec son numéro. **Ce que le clone garde, et c'est voulu** : la clé SSH du PC, donc ``ratbot fleet`` fonctionne aussitôt (voir :doc:`flotte`) ; le mot de passe du compte ``ratbot``, à changer ; ROS 2, le dépôt et sa compilation. Ce que le script règle ---------------------- .. list-table:: :header-rows: 1 :widths: 26 74 * - Étape - Détail * - vérifications - modèle de carte, et surtout **la distribution ROS** : si ce n'est pas celle de la fiche, il s'arrête * - identité - nom de machine, ``/etc/hosts``, et l'effacement décrit ci-dessus * - liaison série - ``enable_uart=1`` et ``dtoverlay=disable-bt`` dans ``config.txt``, console série retirée de ``cmdline.txt``, ``serial-getty`` désactivé * - source de temps - le serveur déclaré dans la fiche (voir :doc:`heure`) * - lidar - règle udev qui lui donne le nom stable ``/dev/ratbot_lidar``, écrite avec l'identifiant USB du matériel **réellement branché**, et appliquée aussitôt. Lidar oublié à l'installation : le brancher, puis ``ratbot install fiche.yaml --only lidar`` * - sources - les sources de l'agent micro-ROS, qui n'existe pas en paquet (``vcs import`` de ``ros2_ws/ratbot.repos``, Internet requis). Avant la première compilation, il vérifie aussi qu'il y a du **swap** : sur une Raspberry de 4 Go, la compilation de l'agent ne passe pas sans * - le reste - il passe la main à ``ratbot deps``, ``network``, ``build`` et ``services``. Avant de fixer l'adresse, il compare la passerelle de la fiche à celle que la Raspberry utilise : si elles diffèrent, il s'arrête, plutôt que de couper le robot du réseau. Si une étape a échoué, il **ne compile pas** et ne pose pas les services : un robot sans agent démarrerait une pile muette .. important:: **Pourquoi la liaison série demande ces réglages.** Sur une Raspberry neuve, ``/dev/ttyAMA0`` est pris par la console de connexion et par le Bluetooth. Tant que les deux ne sont pas écartés, la carte est **injoignable** — et rien ne le dit clairement : le robot démarre, mais reste muet. .. tip:: **Branchez le lidar avant de lancer le script.** Il lit l'identifiant USB de l'adaptateur présent ; s'il n'en trouve aucun, il prévient et ne pose aucune règle — plutôt que d'en écrire une au hasard, qui ne nommerait rien et vous ferait croire le lidar configuré. Si le lidar n'est pas encore là, renseignez ``lidar_usb_id`` dans la fiche (format ``vendeur:produit``, tel que le rend ``lsusb``). .. note:: Le script est écrit et éprouvé pour une **Raspberry Pi 4**. Sur un autre modèle il prévient mais continue : le découpage des ports série diffère, et la partie liaison sera à vérifier à la main. Et ensuite ---------- Le nom de machine et la liaison série ne prennent effet qu'après un redémarrage. Le script le dit, puis : .. code-block:: bash sudo reboot ./scripts/ratbot install mon-robot.yaml # vérifie que tout a pris ./scripts/ratbot role ros2 node list # /ratbot_N/ratbot_controller Le ``ratbot_controller`` apparaît sous le numéro **enregistré dans la carte**, pas sous celui de la Raspberry : une carte neuve se présente en ``ratbot_1`` tant qu'on ne l'a pas renumérotée. Voir :doc:`nouveau_robot`, qui donne la mise en service complète d'un robot, dans l'ordre. .. warning:: ``micro_ros_agent`` **n'existe pas en paquet apt**. Ses sources sont déclarées dans ``ros2_ws/ratbot.repos`` ; l'installation les récupère (étape ``sources``), ce qui demande un accès à Internet. Sans elles, la Raspberry ne peut pas parler à la carte. .. _mises-a-jour-robot: Mises à jour du robot --------------------- Le Raspberry Pi d'un robot ne se met **jamais à jour tout seul** : les minuteries automatiques d'Ubuntu y sont désactivées. C'est délibéré — une bibliothèque qui change entre deux séances, sans que personne ne l'ait décidé, rend un problème impossible à reproduire, et la mise à jour se déclenchait justement au moment où l'on allume le robot. L'installation (``ratbot install``, ``ratbot deps``) n'en fait pas non plus : elle installe les paquets qui manquent, sans toucher à ceux qui sont déjà là. Un robot cloné garde ainsi exactement les versions de la carte d'origine. La mise à jour se fait donc quand vous le décidez, robot au repos, sur un réseau qui a accès à Internet, et **sur tous les robots du parc à la fois**, pour qu'ils gardent les mêmes versions : .. code-block:: bash sudo apt update # rafraîchit les listes, n'installe rien apt list --upgradable # à lire avant : ce qui va changer sudo apt upgrade # installe, sans retirer de paquet sudo reboot # si le noyau a changé Si la mise à jour touche à ROS, reconstruisez ensuite l'espace de travail, puis vérifiez que la carte répond toujours : .. code-block:: bash ./scripts/ratbot build ros2 node list # /ratbot_1/ratbot_controller doit apparaître .. warning:: Évitez ``apt full-upgrade`` sur un robot : il peut **retirer** des paquets pour résoudre un conflit, y compris une brique ROS dont le robot dépend.