Architecture générale

Le robot en bref

Le RatBot est un robot mobile à entraînement différentiel conçu au laboratoire. Quatre exemplaires sont prévus dans un premier temps, d’autres pourront suivre. Chaque robot est autonome : il embarque sa propre intelligence et communique avec le reste du monde par WiFi.

Le RatBot est pensé comme un robot indépendant : il ne dépend d’aucun projet hôte. Il expose son matériel sous forme de topics ROS 2 standards (cmd_vel, odom, TF), et c’est au projet qui l’utilise de construire sa propre couche au-dessus. Il peut ainsi recevoir une carte d’un système extérieur, partager la sienne, ou intégrer de nouveaux capteurs sans remettre en cause son architecture.

Les deux étages

Les deux étages et ce que chacun porte.

Répartition des rôles :

Carte STM32H750 — le temps réel. Elle pilote les deux servomoteurs, reconstruit la position de chaque roue, asservit leur vitesse et intègre l’odométrie. Elle exécute FreeRTOS et un client micro-ROS : les données remontent nativement sous forme de topics ROS 2 (voir Communication avec la carte STM32).

Le matériel y vit dans des tâches séparées et prioritaires — traction à 100 Hz, capteurs à 100 Hz, IHM à 50 Hz — qui remplissent des instantanés en mémoire. La tâche micro-ROS, la moins prioritaire, ne fait que les lire et les publier : elle ne peut donc jamais retarder l’asservissement. Le détail est dans Architecture de l’application firmware.

Important

Il n’y a pas d’encodeur. Les roues sont des servomoteurs Dynamixel AX-18A, dont le capteur de position absolue ne couvre que 300 des 360 degrés : un sixième de chaque tour est aveugle. Reconstruire une position continue à partir de ça est le travail le plus délicat du firmware, et il a sa propre page — Traction : estimateur de roue et odométrie.

C’est aussi ce qui impose de calibrer l’odométrie plutôt que de la déduire des cotes mécaniques.
Sécurité — l’arrêt d’urgence est câblé sur la carte et traité par le microcontrôleur lui-même, sans passer par le réseau, ROS, ni la Raspberry. Il coupe donc même Raspberry éteinte. Les seuils de batterie critiques sont au même endroit, et pour la même raison.
Raspberry Pi 4 — l’essentiel, et seulement lui. Elle exécute ROS 2 Humble et, par ratbot.service : l’agent micro-ROS (pont vers la carte), le lidar en USB, la chaîne de commande (twist_mux, limiteur, arrêt d’urgence), l’EKF et la description du robot, la signalisation. Tout ce qui touche au matériel et à la sécurité, et qui doit tenir si le réseau tombe.
Le PC — ce qui est lourd et change souvent : cartographie, navigation (Nav2), RViz, et plus tard la planification. Il rejoint le robot par le réseau, dans son espace de noms /ratbot_N : un seul PC peut piloter tout le parc. ratbot slam N et ratbot nav N carte.yaml les lancent.

L’EKF et la TF restent sur la Pi, au plus près des capteurs : si le Wi-Fi coupe, l’odométrie reste juste et le robot s’arrête de lui-même : plus aucun ordre n’arrive à la carte, qui coupe les moteurs 0,5 s après le dernier (cmd_vel_timeout_ms). À vérifier en vrai : le robot glisse encore environ 1,5 s après un arrêt, défaut toujours ouvert. Côté Nav2, les tolérances de TF sont portées à 0,5 s pour le retard du Wi-Fi.

Organisation du dépôt

ratbot/
├── conception/          conception matérielle
│   ├── kicad/           électronique (voir chapitre dédié)
│   ├── 2d/              plans 2D : châssis, découpe laser, logo (DXF)
│   └── 3d/              modèles 3D
├── firmware/
│   ├── ratbot_bootloader/        bootloader maison, flash interne
│   └── ratbot_firmware_card/     l'application (FreeRTOS + micro-ROS)
│       ├── App/                  le code du projet
│       └── test/                 banc de test sur PC, faux matériel
├── ros2_ws/             workspace ROS 2 de la Raspberry Pi
│   └── src/
│       ├── ratbot_description/   URDF du robot
│       ├── ratbot_bringup/       fichiers de lancement
│       ├── ratbot_msgs/          messages et services propres au robot
│       ├── ratbot_status/        voyants, sons, écran, batterie
│       ├── ratbot_calibration/   calibration mesurée au sol (UMBmark)
│       ├── ratbot_mission/       enchaînement de tâches
│       ├── ratbot_sim/           simulateur cinématique léger
│       ├── ratbot_gazebo/        simulation physique Gazebo + labyrinthes
│       ├── ratbot_slam/          SLAM (slam_toolbox)
│       ├── ratbot_nav/           navigation (nav2)
│       └── ratbot_maps/          cartes sauvegardées (données)
├── cahier_de_labo/      les mesures, et le cahier qui les commente
├── scripts/             ratbot : point d'entrée unique du projet
├── docs/                cette documentation (Sphinx, user + dev)
├── Dockerfile           image de dev ROS 2 (paramétrée par ROS_DISTRO)
└── compose.yaml         orchestration du conteneur de dev

Deux principes d’organisation méritent d’être signalés.

Un seul point d’entrée. ./scripts/ratbot est identique sur la machine de développement et sur les robots : c’est la machine qui décide de ce qu’elle installe, construit et lance, d’après son nom d’hôte. Un robot fraîchement installé n’a donc rien à configurer — il suffit qu’il s’appelle ratbot-N.

Le code livrable et les données ne se mélangent pas. ratbot_calibration est un paquet ROS que n’importe qui peut installer pour calibrer son propre robot : il ne connaît aucun répertoire de données, on lui dit où écrire. cahier_de_labo/ contient les mesures de ce parc et le journal de bord des séances, et pas une ligne de code.

Le parc : une seule chaîne de conventions

Les robots sont identiques, et rien n’est à configurer à la main sur un exemplaire neuf. Tout découle du nom de la machine :

hostname  ratbot-3
   │
   ├──►  robot_id = 3          (aussi stocké en flash sur la carte)
   ├──►  namespace /ratbot_3/  et frames TF préfixées ratbot_3/
   └──►  adresse 192.168.1.173  =  192.168.1.(170 + N)

Le domaine DDS est 77 pour tout le parc, et il est figé dans le firmware — la carte ne peut pas se tromper de domaine même si l’environnement de la Raspberry est mal réglé.

Un même binaire sert donc les quatre robots. Ce qui diffère d’un exemplaire à l’autre tient dans la flash de la carte : son numéro, les identifiants de ses servomoteurs, et sa géométrie calibrée.

Note

La calibration décrit le châssis et les roues, mais elle vit dans la carte. La convention est donc qu’une carte appartient à un robot. Si une carte change de châssis, il faut recharger la configuration du châssis d’accueil — voir Les topics du robot, section Paramètres de la carte.

Par où entrer dans cette documentation

Si vous voulez…	Lisez
faire rouler un robot existant	le guide utilisateur, pas cette documentation-ci
comprendre le découpage du firmware	Architecture de l’application firmware
toucher à l’odométrie ou à l’asservissement	Traction : estimateur de roue et odométrie, puis Le banc de test sur PC
reflasher, ou repartir d’un `.ioc` neuf	Bootloader et exécution depuis la flash externe, puis Monter un projet FreeRTOS + micro-ROS
savoir ce que la carte publie et accepte	Les topics du robot
diagnostiquer une liaison qui décroche	Communication avec la carte STM32, section Robustesse de la liaison
assembler ou modifier la carte	La carte RatBot

Exemple d’intégration : un système de caméras fixes

Un système hôte peut faire évoluer des RatBots sous des caméras fixes : leur pose dérive à l’odométrie et n’est recalée que lorsqu’une caméra aperçoit le marqueur ArUco fixé sur leur sommet (dictionnaire DICT_4X4_50, 150 × 150 mm, convention ratbot_N porte l’identifiant N). Aucun paquet spécifique à un hôte ne vit dans ce dépôt : l’intégration se fait entièrement côté hôte, au-dessus des topics standards du robot.