Installer le Raspberry Pi

S’applique à : 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 Mettre en service un nouveau robot. Pour préparer le PC, voir Installer le PC.

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.

cp deploy/ratbot.example.yaml mon-robot.yaml
$EDITOR mon-robot.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 :

./scripts/ratbot install mon-robot.yaml --dry-run   # ce qu'il ferait
./scripts/ratbot install mon-robot.yaml

Astuce

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 :

utilisateur	`ratbot`
mot de passe par défaut	`chang3m3`

Avertissement

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 Travailler à plusieurs robots). 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é :

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

Avertissement

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 :

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 :

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 :

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 :

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 :

Avertissement

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 :

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 :

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 Travailler à plusieurs robots) ; le mot de passe du compte ratbot, à changer ; ROS 2, le dépôt et sa compilation.

Ce que le script règle

É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 L’heure du robot)
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.

Astuce

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 :

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 Mettre en service un nouveau robot, qui donne la mise en service complète d’un robot, dans l’ordre.

Avertissement

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 à 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 :

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 :

./scripts/ratbot build
ros2 node list             # /ratbot_1/ratbot_controller doit apparaître

Avertissement

É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.