Installer ROS 2 sur un Raspberry Pi et créer un workspace

Introduction

Rien en ROS 2 n’est difficile jusqu’à l’installer sur un robot, moment où trois choses sans rapport tournent mal à la fois : le système d’exploitation est le mauvais, l’espace de travail ne compile pas dans la mémoire du Pi, et le portable ne voit pas les nœuds du robot. Aucune n’est exactement un problème ROS, et c’est pourquoi les tutoriels officiels ne vous préviennent pas.

Ceci vous mène d’une carte SD vierge à ros2 topic list fonctionnant depuis votre portable contre des nœuds tournant sur le robot.

Choisissez le système d’exploitation, pas juste la carte

Les binaires ROS 2 sont construits pour Ubuntu, pas Raspberry Pi OS. Raspberry Pi OS est basé sur Debian, donc les paquets apt n’y sont tout simplement pas, et chaque contournement — compiler depuis les sources, Docker, conda — vous coûte des heures avant d’avoir écrit le moindre code de robot.

Installez donc Ubuntu Server 24.04 LTS (64 bits) et appariez-le à la version ROS 2 construite contre lui. Au moment d’écrire, cet appariement est Jazzy Jalisco, supporté jusqu’en 2029 ; vérifiez la page d’installation pour ce qui est courant quand vous lisez ceci et substituez le nom partout.

Trois choses à réussir au flashage :

• 64 bits. Les paquets ROS 2 arm64 existent ; les armhf non.
• Server, pas Desktop. Un robot n’a pas d’écran, et l’environnement de bureau coûte de la RAM voulue pour la vision.
• Pi 4 avec 4 Go, ou Pi 5. Une carte 2 Go fait tourner ROS 2 bien mais ne peut pas confortablement le compiler.

Installez ROS 2 depuis apt

Ajoutez la source apt ROS 2, puis installez. La mise en place du dépôt change entre versions, donc voici la forme plutôt qu’un extrait à mémoriser :

sudo apt update && sudo apt install -y software-properties-common curl
sudo add-apt-repository universe

# Fetch and install the package that registers the ROS 2 apt repository and key.
export ROS_APT_SOURCE_VERSION=$(curl -s \
  https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest \
  | grep -F "tag_name" | awk -F\" '{print $4}')
curl -L -o /tmp/ros2-apt-source.deb \
  "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo $VERSION_CODENAME)_all.deb"
sudo apt install -y /tmp/ros2-apt-source.deb

sudo apt update
sudo apt install -y ros-jazzy-ros-base ros-dev-tools

Notez ros-base, pas desktop. Le métapaquet desktop tire RViz et les démos graphiques, qu’un robot sans tête ne lancera jamais et qui prennent un temps fou à installer sur une carte SD. La visualisation appartient à votre portable, où vous installez le plein ros-jazzy-desktop.

ros-dev-tools est ce qui donne colcon et rosdep. Initialisez rosdep une fois :

sudo rosdep init      # skip if it says the file already exists
rosdep update

Sourcez la sous-couche, puis votre surcouche

ROS 2 ne fait rien tant que son environnement n’est pas sourcé, et c’est là que vit l’essentiel de la confusion initiale.

source /opt/ros/jazzy/setup.bash

C’est la sous-couche — la distribution installée. Votre propre espace de travail, une fois construit, est une surcouche par-dessus. Sourcer une surcouche amène implicitement la sous-couche contre laquelle elle a été construite.

echo "source /opt/ros/jazzy/setup.bash" >> ~/.bashrc

Mettre la sous-couche dans .bashrc est standard et sûr. Y mettre votre surcouche est un piège à éviter tôt : le jour où vous avez deux espaces de travail, ou recompilez contre une autre distribution, chaque nouveau shell démarre silencieusement avec un environnement périmé et vous déboguez un fantôme un après-midi. Sourcez la surcouche explicitement, par shell, dans le terminal qui en a besoin.

Créez un espace de travail et un paquet

Un espace de travail colcon est un répertoire avec un src/ dedans. C’est toute la spécification.

mkdir -p ~/ros2_ws/src && cd ~/ros2_ws
ros2 pkg create --build-type ament_python --license Apache-2.0 my_robot

Puis construisez et surcouchez-le :

cd ~/ros2_ws
rosdep install --from-paths src --ignore-src -y
colcon build --symlink-install
source install/setup.bash

Utilisez --symlink-install. Il lie vos fichiers Python dans l’espace d’installation au lieu de les copier, donc éditer un nœud prend effet au prochain lancement plutôt qu’après une reconstruction. Sur un Pi, où une reconstruction est lente, c’est la différence entre itérer et attendre.

Après la construction, ~/ros2_ws tient build/, install/ et log/ à côté de src/. Seul src/ appartient au contrôle de version.

Construisez sans vider la mémoire du Pi

colcon build compile les paquets en parallèle, un processus par cœur, et chaque compilation C++ peut prendre l’essentiel d’un gigaoctet. Sur un Pi quatre cœurs, cela fait quatre gros compilateurs à la fois, et la construction meurt avec un message de processus tué — ou toute la carte se fige.

MAKEFLAGS="-j1" colcon build --parallel-workers 1 --symlink-install

Plus lent, et cela finit. Les paquets pur Python n’ont pas ce problème ; cela mord dès que vous construisez quoi que ce soit avec du C++ dedans. Ajouter quelques gigaoctets de swap marche aussi, quoique sur une carte SD ce soit terriblement lent.

Parlez au robot depuis votre portable

ROS 2 n’a pas de maître. Les nœuds se trouvent par découverte DDS sur le réseau, ce qui signifie qu’un portable et un Pi sur le même LAN peuvent former un graphe sans aucune configuration — quand cela marche.

Mettez le même domaine sur les deux machines :

export ROS_DOMAIN_ID=42        # any value 0–101; the same on every machine

Le domaine partitionne le réseau. Deux robots dans la même pièce sur le domaine par défaut entendront les sujets l’un de l’autre et se les disputeront, ce qui est une façon mémorable d’apprendre ce que fait ce réglage.

Vérifiez depuis le portable, avec un parleur tournant sur le Pi :

ros2 topic list
ros2 node list
ros2 topic echo /chatter

Faites survivre la découverte au Wi-Fi

ros2 topic list qui ne montre rien pendant que le Pi publie plainement est la panne réseau ROS 2 la plus courante, et ce n’est presque jamais la faute de ROS.

La découverte utilise le multicast, et beaucoup de points d’accès ne le relayent pas. Les routeurs Wi-Fi grand public limitent ou jettent souvent le multicast, et les modes « isolation client » ou réseau invité bloquent carrément le trafic client à client. Les nœuds tournent ; les paquets qui les présenteraient n’arrivent jamais.

Traitez-le dans cet ordre :

1. Même sous-réseau ? Un portable en 5 GHz et un Pi sur un SSID invité ne sont pas sur le même réseau, si semblables que semblent les adresses.
2. Même ROS_DOMAIN_ID, dans le shell qui fait vraiment tourner le nœud ? Un export dans un terminal n’atteint pas un autre, ni un service systemd.
3. Essayez en filaire. Si l’Ethernet marche et le Wi-Fi non, vous avez prouvé que c’est le multicast, pas ROS.
4. Vérifiez le pare-feu. sudo ufw allow in proto udp from <subnet> des deux côtés, ou désactivez-le pendant les essais.
5. Repliez-vous sur un serveur de découverte. Fast DDS peut utiliser un point connu au lieu du multicast — mettez ROS_DISCOVERY_SERVER à l’adresse du robot sur les deux machines. C’est la réponse fiable sur un réseau que vous ne contrôlez pas.

Encore une, et elle est discrète : gardez les horloges synchronisées. TF2 compare les horodatages entre machines, et un Pi sans RTC démarre sur une heure fausse. Installez chrony des deux côtés, ou chaque recherche de transformée échoue avec une erreur d’extrapolation qui ressemble à un bogue ROS.

Démarrez les nœuds du robot au boot

Un robot dans lequel il faut se connecter en SSH pour démarrer est un robot éteint. Une unité systemd corrige cela :

# /etc/systemd/system/my-robot.service
[Unit]
Description=Robot bringup
After=network-online.target

[Service]
User=ubuntu
Environment=ROS_DOMAIN_ID=42
ExecStart=/bin/bash -lc 'source /opt/ros/jazzy/setup.bash && \
  source /home/ubuntu/ros2_ws/install/setup.bash && \
  ros2 launch my_robot bringup.launch.py'
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now my-robot
journalctl -u my-robot -f

La ligne Environment= compte plus qu’il n’y paraît. systemd ne lit pas votre .bashrc, donc un service n’hérite d’aucune des variables ROS de votre shell interactif — et c’est exactement pourquoi un robot qui marche en SSH devient muet quand il démarre seul.

Quand ça tourne mal

Avec l’environnement qui se comporte, la question suivante est quoi y mettre — ce qui est un problème de conception plutôt d’installation. Nœuds, sujets, services et actions couvre le choix entre motifs de communication, et les repères de coordonnées TF2 couvre la partie qui attrape les gens après.