Raspberry Pi

Présentation

Le Raspberry Pi est un ordinateur complet de la taille d’une carte de crédit. Là où un Arduino Uno est un microcontrôleur qui exécute un programme pour toujours, un Pi fait tourner Linux — il peut donc piloter une caméra, parler au réseau, exécuter ROS 2 et votre code robot en même temps. C’est le cerveau à prendre quand un robot doit penser, pas juste réagir.

Cette puissance est aussi son compromis : le multitâche Linux rend le Pi moins bon dans la temporisation précise à la microseconde qu’un microcontrôleur fait sans effort. Les deux sont partenaires, pas rivaux.

Fonctionnement

Le Pi démarre un système d’exploitation (généralement Raspberry Pi OS) depuis une carte microSD, puis se comporte comme toute machine Linux. Pour la robotique, l’important est le connecteur GPIO 40 broches : entrées et sorties numériques, plus bus I²C, SPI et UART, qui permettent au Pi de lire des capteurs et commander du matériel. Au-dessus se trouvent les parties ordinateur — USB, Ethernet, Wi-Fi et interface caméra — qu’un microcontrôleur n’a tout simplement pas.

Une architecture fréquente est un robot à deux cerveaux : le Pi gère perception et planification (vision, SLAM, nœuds ROS) et transmet les consignes moteur à un Arduino qui fait la commande temps réel.

Quand l’utiliser

Prenez un Pi quand le robot a besoin des capacités d’un ordinateur :

• Vision par ordinateur — une caméra plus OpenCV pour détecter des marqueurs, objets ou lignes.
• ROS 2 — faire tourner nœuds, topics et la pile de navigation.
• Cartographie / SLAM — construire une carte et s’y localiser.
• Réseau — tableau de bord web, télécommande ou télémétrie.

Restez avec un Arduino ou un ESP32 pour les purs travaux de commande temps réel — moins chers, plus simples et meilleurs en temporisation précise.

Câblage et pièges

• Logique 3,3 V, non tolérante au 5 V. Mettre du 5 V sur une broche GPIO peut endommager le Pi. Adaptez les niveaux depuis les pièces 5 V (par ex. la ligne TX d’un HC-05).
• Il ne peut toujours pas alimenter des moteurs. Les GPIO pilotent des signaux ; le courant moteur passe par un contrôleur comme le L298N.
• L’alimentation est exigeante. Donnez-lui un 5 V stable à courant suffisant ; les baisses corrompent la carte SD et provoquent des redémarrages aléatoires.
• Éteignez-le proprement. Arracher l’alimentation d’un système Linux en marche peut corrompre la carte — prévoyez une extinction sûre ou un système de fichiers en lecture seule.

Le connecteur 40 broches, et quelles broches utiliser

Le connecteur fait 40 broches et seules 26 sont des GPIO utilisables. Le reste est alimentation et masse.

Deux de ces lignes coûtent régulièrement une soirée.

L’UART est la console. D’origine, GPIO 14/15 portent une invite de connexion Linux. Câblez-y un module GPS ou un Arduino et vous obtenez du bruit de connexion au lieu de données. Libérez-les avec sudo raspi-config → Interface Options → Serial Port → login shell : no, hardware serial : yes. Sur Pi 3 et suivants, subtilité supplémentaire : le bon UART sert au Bluetooth par défaut, et celui du connecteur est un « mini UART » moindre dont le débit dérive avec l’ horloge CPU. Ajoutez dtoverlay=disable-bt à /boot/config.txt pour les permuter.

Le PWM logiciel tremble. Seules quatre broches ont du PWM matériel. Tout le reste est généré par le noyau, et l’ordonnanceur Linux l’interrompra — ce qui sur un servomoteur se voit en tressautements. C’est l’illustration la plus claire de ce qu’un Pi fait mal.

Le problème de temporisation, dit plainement

C’est la chose la plus importante à comprendre sur un Pi dans un robot, et ce n’est pas un défaut — c’est ce qu’est un système d’exploitation.

Un microcontrôleur exécutant loop() exécute votre code et rien d’autre, donc un intervalle de 1 ms fait 1 ms. Linux partage le temps : le noyau peut préempter votre processus pour servir un paquet réseau, vider une écriture disque, ou faire tourner une centaine de tâches de fond.

La conséquence est l’architecture à deux cerveaux, et ce n’est pas un compromis mais la conception normale d’un robot sérieux :

Raspberry Pi                        Microcontroller
- camera, vision                    - encoder counting
- SLAM, path planning       <-->    - PID motor control
- ROS 2 nodes                       - servo timing
- networking, dashboard             - emergency stop
        high-level goals                  hard real time

Ils parlent en série USB, UART ou I²C, et chacun fait ce qu’il fait bien. Un Pi essayant de compter des fronts de codeur les manquera ; un Arduino essayant de faire tourner OpenCV ne le peut pas.

L’alimenter, et le problème de la carte SD

L’alimentation est là où les robots Pi échouent, et le mode de panne est inhabituellement cher : une baisse pendant une écriture corrompt la carte SD, et vous perdez toute l’image système.

Règles qui en découlent :

• N’alimentez jamais moteurs et Pi depuis le même rail. L’appel de courant des moteurs est exactement le transitoire qui corrompt une carte.
• Utilisez un régulateur à découpage, pas linéaire, si vous partez d’une batterie. Un régulateur linéaire passant de 11,1 V à 5 V à 1 A brûle 6 W.
• Guettez l’éclair. Le Pi affiche une icône de sous-tension et la journalise aussi ; vcgencmd get_throttled la rapporte. Toute valeur non nulle signifie une alimentation insuffisante, et elle corrompra une carte tôt ou tard.
• Éteignez proprement. sudo shutdown -h now avant de couper l’alimentation. Un robot qu’on éteint avec un interrupteur veut soit un bouton d’arrêt câblé à un GPIO, soit un système de fichiers racine en lecture seule.

Le système de fichiers en lecture seule vaut sérieuse considération pour un robot déployé : avec overlayfs actif, rien n’est jamais écrit sur la carte en fonctionnement, et on peut couper l’alimentation à tout moment sans conséquence. On perd la sauvegarde locale de données, ce qui est généralement un bon échange.

Quel modèle pour un robot

Pour ROS 2 avec caméra, 4 Go est le point où cela cesse d’être frustrant. RViz, un nœud vision et une pile de navigation prendront ensemble plus d’1 Go, et un Pi qui commence à swapper sur la carte SD devient inutilisable lent — et use la carte.

Deux accessoires non optionnels en pratique : un dissipateur ou ventilateur (un Pi 4 en charge soutenue s’étrangle à 80 °C, et un Pi étranglé perd des trames), et une carte microSD de bonne qualité classe A2, ou mieux, un démarrage sur SSD USB. La vitesse de carte est le goulot bien plus souvent que le CPU.

Dépannage

Pi ou microcontrôleur ?

Le cadrage honnête : ce ne sont pas des concurrents. Un Pi ne peut pas compter un codeur sûrement et un microcontrôleur ne peut pas faire tourner OpenCV. Presque tout robot amateur capable finit avec les deux, et le reconnaître tôt épargne beaucoup d’efforts à vouloir faire faire à l’un le travail de l’autre.

Si tout le comportement de votre robot tient dans une boucle de commande — un suiveur de ligne, un éviteur d’obstacles, un solveur de labyrinthe — vous n’avez pas besoin de Pi du tout, et en ajouter un rend le robot plus lent à démarrer, plus fragile et plus dur à déboguer.