Travailler à plusieurs robots
S’applique à : Simulation Robot réel
Le RatBot est conçu pour le travail en flotte : plusieurs robots partagent le même réseau, sont pilotés depuis le même PC, et s’arrêtent ensemble. Un robot seul n’en est pas affecté : tout ce qui suit est sans effet tant qu’il n’y en a qu’un.
Un numéro par robot
Chaque robot porte un numéro, de 1 à 19. Ce numéro préfixe tout ce qui le concerne :
robot 1 |
robot 2 |
|
|---|---|---|
topics |
|
|
repères de position |
|
|
nom du Raspberry Pi |
|
|
adresse réseau |
|
|
Les topics de deux robots ne se mélangent donc jamais. Ce qui est commun à tout
le parc vit sous /ratbot_fleet/.
La limite de 19 vient des adresses réseau : le robot N reçoit
l’adresse 192.168.1.(170 + N), soit .171 à .189. Au-delà, le
robot 20 prendrait l’adresse du serveur de temps du labo (.190).
Le nombre de robots se donne au lancement, jusqu’à 4 ; chaque décor déclare où les poser :
./scripts/ratbot up hampton_simple 4
Pour en ajouter un pendant que la simulation tourne, lui donner un
numéro encore libre et une position dans le décor. Par exemple, après
./scripts/ratbot up rooms 1, le robot 2 à sa place de départ :
ros2 launch ratbot_gazebo spawn_robot.launch.py robot_id:=2 x:=0.6 y:=0.0
Voir La simulation en détail pour les décors et leurs places de départ.
Le numéro est attribué à la mise en service : au Raspberry Pi par sa fiche d’identité, à la carte du robot par un réglage (voir Mettre en service un nouveau robot).
Danger
Une carte neuve se présente comme le robot 1. Tant qu’elle n’a pas reçu son numéro, elle se confond avec le vrai robot 1 : renumérotez-la, robot 1 éteint, avant de les allumer ensemble.
Le parc et son état
Le parc est décrit dans un seul fichier, deploy/fleet.yaml. On y trouve :
les robots qui existent ;
leur état : en service, en montage, en réparation ou retiré ;
leur matériel : lidar et son montage, capteur de distance, batterie, bras ;
les machines qui ne sont pas des robots, le PC de navigation par exemple.
Le fichier ne contient pas ce qui découle du numéro (nom, adresse, topics) ni
les réglages de la carte, qui restent dans la carte. La date des calibrations
n’y est pas non plus : elle est lue dans le cahier de labo, là où
ratbot-calibrate l’écrit.
Les commandes, lancées sur le PC :
./scripts/ratbot fleet show # le parc, après vérification du fichier
./scripts/ratbot fleet status # l'état de chaque robot en service
./scripts/ratbot fleet # la même chose que fleet status
./scripts/ratbot fleet battery # la batterie de chaque robot
./scripts/ratbot fleet time # les horloges : PC, Raspberry Pi, cartes
./scripts/ratbot fleet diag # les diagnostics qui ne sont pas OK
./scripts/ratbot fleet who # qui roule, qui navigue, depuis où
./scripts/ratbot fleet identify 2 # le robot 2 clignote en blanc et bipe
Toutes ne font que lire : elles ne redémarrent rien et ne modifient rien,
ni sur le PC ni sur les robots. Seule identify agit, sur le voyant et le
buzzer, et jamais sur les roues.
Ce qu’il faut avant
fleet status se connecte à chaque robot par SSH sans mot de passe. La
clé du PC doit donc être installée une fois sur chaque Raspberry Pi :
ssh-copy-id ratbot@192.168.1.171 # une fois par robot
ssh ratbot@192.168.1.171 true # une connexion à la main, pour
# accepter l'empreinte du robot
Lire le résultat
Par exemple :
parc : domaine 77, ROS humble, heure 192.168.1.190
robot etat reseau service depot horloge batterie calibration
ratbot-1 in_service oui active daad056 +3 ms 11.82 V 64 % umbmark 2026-10-04, gyro 2026-10-04, lidar 2026-10-16
ratbot-2 assembly - - - - - umbmark -, gyro -, lidar -
Une ligne par robot :
colonne |
signification |
|---|---|
reseau |
le robot répond-il sur son adresse ? |
service |
l’état du service du robot ; |
depot |
la version du logiciel sur le robot (les 7 premiers caractères du commit) |
horloge |
l’écart de son horloge à celle de ce PC, mesuré directement ; |
batterie |
tension et charge, lues sur le topic |
calibration |
la date de la dernière calibration appliquée de l’odométrie
( |
Le programme rend le code 1 dès qu’un robot en service a une alerte, et 0 sinon. Un script peut donc s’en servir pour refuser de continuer.
Les alertes
Sous un robot, une ligne marquée /!\ signale un problème. Une ligne
marquée . est une simple information.
message |
que faire |
|---|---|
|
le robot est éteint, n’a pas fini de démarrer (une minute environ), ou n’est pas sur le réseau du labo |
|
se connecter une fois à la main ( |
|
le Raspberry Pi a été réinstallé : |
|
installer la clé du PC : |
|
le logiciel du robot ne tourne pas : voir Dépannage |
|
le robot n’a pas joint le serveur de temps : voir L’heure du robot |
|
le robot répond, mais pas sa carte : carte éteinte, liaison avec le Raspberry Pi coupée, ou robot sur un autre domaine ROS |
|
la calibration n’a jamais été écrite dans la carte : voir Calibrer l’odométrie et Calibrer le gyroscope |
|
le montage du lidar n’a jamais été vérifié : voir Le lidar |
|
une intervention notée dans le fichier est postérieure à la calibration : la refaire |
|
corriger la date dans le |
|
le robot n’a pas la même version que le PC. Ce n’est pas forcément une erreur, mais à vérifier avant un essai |
|
une mesure plus récente que la calibration n’a pas été écrite dans la carte. C’est normal pour une mesure de vérification. |
Les robots en montage, en réparation ou retirés sont listés sans être interrogés : aucune alerte n’est donnée pour eux.
Batterie, heure, diagnostics, activité
Ces commandes interrogent tous les robots en service en même temps, en trois
secondes environ. Comme status, elles rendent le code 1 dès qu’un robot
a une alerte.
fleet battery donne, pour chaque robot, la tension, la charge et la tension par élément, avec la batterie déclarée dans le fichier :
robot tension charge par elem. batterie
ratbot-1 11.82 V 64 % 3.94 V lipo_3s 5200 mAh
Elle alerte sous 20 % de charge, comme le voyant, et sous 3,5 V par élément : en dessous, une LiPo s’abîme. Il faut alors la recharger.
fleet time compare les horloges. L’écart de chaque Raspberry Pi est mesuré directement depuis le PC, avec son incertitude. On ne lit pas seulement chrony, car un robot qui ne joint plus le serveur peut se dire encore synchronisé. La dernière colonne donne l’écart de la RTC de la carte à son Raspberry Pi :
serveur de temps 192.168.1.190 ; ecarts a cette machine (lea)
machine ecart ici au serveur RTC carte / Pi
lea (reference) +1 ms ok -
ratbot-1 +4 ms ±3 ms -1 ms ok +0.3 s
Un écart de plus de 0,1 s entre le PC et un robot est signalé : la
navigation en souffre, car les positions et les mesures ne sont plus datées de
la même façon. L’écart de la RTC n’est signalé qu’au-delà de 2 s, car elle ne
sert qu’à dater le journal. La colonne au serveur vaut NON quand la
machine n’est pas synchronisée. Le plus souvent, le serveur de temps n’est pas
démarré : voir L’heure du robot.
fleet diag écoute /diagnostics et ne montre que les blocs qui ne sont
pas OK (avertissement, erreur, périmé), rangés par robot :
ratbot-1 22 blocs, 1 pas OK
WARN ratbot_1: clock : RTC never set
sans robot : 3 blocs, tous OK
La signification de chaque bloc est dans Diagnostics. Les blocs « sans robot » viennent de programmes qui ne disent pas de quel robot ils sont (le multiplexeur de commandes, le filtre de localisation).
fleet who dit ce qui tourne pour chaque robot, et sur quelle machine : avant une mise à jour ou un essai, on sait ainsi si quelqu’un d’autre s’en sert.
ratbot-1 ROULE
Nav2 bt_navigator ici (lea)
localisation (AMCL) amcl ici (lea)
commande (cmd_vel_nav) /ratbot_1/controller_server ici (lea)
commande (cmd_vel_teleop) /ratbot_fleet/teleop_ratbot_1 une autre machine
Les commandes listées sont les programmes qui envoient des vitesses au robot. « Une autre machine » veut dire que le programme est vu sur le réseau, mais ni sur ce PC ni sur le Raspberry Pi du robot.
Reconnaître un robot
Quand plusieurs robots identiques sont sur la table :
./scripts/ratbot fleet identify 2 # 10 secondes
./scripts/ratbot fleet identify 2 --seconds 30
Le voyant du robot 2 clignote en blanc et il bipe chaque seconde
(Ctrl-C arrête plus tôt). Un état plus grave reste affiché : un robot en
arrêt d’urgence garde son rouge. Si rien ne se passe, la commande dit que
personne n’écoute : le robot est éteint, ou son logiciel ne tourne pas.
En simulation
Ces commandes écoutent par défaut le domaine des robots (77). Pour une simulation lancée dans un autre domaine, il faut le donner :
./scripts/ratbot fleet diag --domain 0
Le robot réel ne répondant pas, time et la colonne reseau le disent ;
battery, diag, who et identify fonctionnent sur les robots
simulés.
Modifier le parc
Le fichier est vérifié à chaque commande. Une faute (numéro en double, état inconnu, date mal écrite…) est refusée avec l’endroit où elle se trouve, et rien n’est interrogé.
Ajouter un robot. On l’ajoute avec son numéro, d’abord en montage. On le passe en service quand il est mis en service (voir Mettre en service un nouveau robot) :
- id: 2
state: assembly # in_service, assembly, repair, retired
label: "autocollant bleu" # pour le reconnaître sur la table
lidar: {model: rplidar_a1, mount_yaw_deg: 180}
tof: {mounted: false}
wheels: {servo: ax18a} # ou xl430 : voir « Mettre en service un nouveau robot »
battery: {type: lipo_3s, capacity_mah: 5200}
Noter une intervention. Une intervention sur un robot (une roue changée,
un moteur remplacé, le lidar démonté) se note avec sa date. La calibration faite
avant cette date est alors signalée à refaire. affects dit ce que
l’intervention touche : umbmark pour les roues et l’entraxe, gyro,
lidar. Sans affects, l’intervention touche umbmark et gyro.
interventions:
- {date: 2026-10-20, what: "roue gauche changee"} # umbmark et gyro
- {date: 2026-10-22, what: "lidar demonte", affects: [lidar]}
- {date: 2026-10-23, what: "cable refait", affects: []} # rien a refaire
Les interventions s’écrivent dans l’ordre des dates. Une intervention et une calibration du même jour ne donnent pas d’alerte : on suppose que la calibration a été faite après la réparation.
Piloter plusieurs robots
Une seule manette pilote jusqu’à quatre robots : la gâchette tenue désigne le robot qui bouge — L1 pour le robot 1, L2 pour le 2, R1 pour le 3, R2 pour le 4. Voir Piloter le robot, qui décrit aussi la variante à une manette par robot.
Au clavier ou par programme, il suffit de viser le bon numéro :
/ratbot_2/base/cmd_vel pour le robot 2.
Voir plusieurs robots
Deux façons, dans RViz (voir Visualiser dans RViz) :
tous ensemble, en simulation :
./scripts/ratbot up … rviz:=trueouvre une vue du décor avec tous les robots ;un par fenêtre :
./scripts/ratbot rviz Npour regarder le robotN; la cartographie, la navigation et l’exploration ouvrent aussi le RViz de leur robot, et son outil de but ne commande que lui.
Arrêter tout le parc
Le bouton PS de la manette, ou le topic /ratbot_fleet/emergency_stop,
arrêtent tous les robots d’un coup. Ce n’est pas un arrêt d’urgence : il
passe par le réseau. Chaque robot garde son propre bouton d’arrêt. Voir
Arrêter et relancer le robot.