Les paramètres du robot

S’applique à : Robot réel

Le robot garde une poignée de réglages dans sa propre mémoire : la taille de ses roues, l’écartement entre elles, les identifiants de ses moteurs, ses vitesses maximales. Cette page explique ce qu’ils sont, comment les lire, les modifier, et surtout comment les sauvegarder — parce que la carte en détient la seule copie.

Où ils vivent

Dans la mémoire flash de la carte, pas sur le Raspberry Pi. C’est un choix : l’odométrie est calculée par la carte, et elle doit rester juste même si le Raspberry est éteint, défaillant ou remplacé.

Avertissement

C’est la seule copie. Rien n’est dupliqué ailleurs. Une carte remplacée, un secteur effacé, une mise à jour qui change le format de configuration, et des réglages qui ont coûté une heure de mesures disparaissent sans recours.

D’où la section Sauvegarder et restaurer plus bas, qu’il vaut mieux lire avant d’en avoir besoin.

Les fichiers YAML que vous trouverez dans ros2_ws/src/*/config/ sont ceux des nœuds du Raspberry — navigation, cartographie, voyants. Ils ne contiennent pas la géométrie du robot et n’ont rien à voir avec cette page.

La liste

Paramètre

Unité

Valeurs admises

Rôle

wheel_radius_left

m

0 à 1

Rayon effectif de la roue gauche. Réglé par la calibration.

wheel_radius_right

m

0 à 1

Idem à droite. Les deux diffèrent après calibration.

wheel_separation

m

0 à 2

Entraxe effectif, celui qui fait tomber les rotations juste — pas la cote du plan.

gyro_scale

—

0,9 à 1,1

Échelle du gyroscope : combien de tours il compte pour un tour réel. 1,0 = aucune correction. Propre à chaque robot, mesurée par le test des dix tours (Calibrer le gyroscope).

max_linear

m/s

0 à 1

Vitesse maximale en ligne droite. Bornée dans la carte : aucun nœud, aucun plan de navigation ne peut la dépasser.

max_angular

rad/s

0 à 20

Vitesse de rotation maximale, même principe.

cmd_vel_timeout_ms

ms

50 à 5000

Délai sans consigne au bout duquel le robot s’arrête de lui-même.

robot_id

—

1 à 99

Numéro du robot. Donne l’espace de noms /ratbot_N/. Prend effet au redémarrage. La carte accepte 1 à 99, mais le parc n’utilise que 1 à 19, la limite du plan d’adresses (voir Travailler à plusieurs robots).

dxl_id_left

—

0 à 253

Identifiant du servomoteur de gauche sur le bus Dynamixel.

dxl_id_right

—

0 à 253

Celui de droite. Il doit différer du gauche : deux servos de même identifiant sur un même fil se répondent dessus.

fan1_pct

%

0 à 100

Vitesse du ventilateur 1. 0 l’arrête.

fan2_pct

%

0 à 100

Vitesse du ventilateur 2.

wheel_servo_model

—

18 ou 1060

Les servomoteurs des roues, par leur numéro de modèle ROBOTIS : 18 pour l’AX-18A (le parc actuel), 1060 pour le XL430-W250. Prend effet au redémarrage. Voir les roues en XL430.

Avertissement

Un ventilateur à 2 fils ne se ralentit pas. Son électronique de commutation est alimentée par les deux mêmes fils que le moteur : dès qu’on hache l’alimentation, même de 15 % du temps, elle décroche et le moteur cale.

Mesuré le 2026-09-26 sur un 30 mm : il tourne à 100 %, cale à 95 %, et même six secondes à plein régime avant de redescendre à 70 % ne suffisent pas à le maintenir. Ce n’est pas un seuil à affiner, c’est une limite du composant.

Le réglage n’est donc utile, sur un 2 fils, que pour choisir quelle sortie souffle et éteindre celle qui ne sert pas. Pour une vraie variation de vitesse il faut un ventilateur 4 fils, qui a une entrée PWM dédiée et garde son électronique alimentée en permanence.

La carte pousse la sortie à fond pendant une seconde à chaque fois que la consigne augmente : sans ce coup de fouet, un ventilateur à l’arrêt n’aurait pas le couple de décoller.

Note

La carte valide elle-même ces bornes et refuse ce qui n’y entre pas. C’est le dernier rempart : un réglage aberrant venu du réseau ou d’une faute de frappe n’atteint jamais les moteurs.

Les lire

./scripts/ratbot config 1 show

Le 1 est le numéro du robot : obligatoire depuis le PC, facultatif sur le Raspberry Pi du robot (voir La commande ratbot).

cmd_vel_timeout_ms   500
dxl_id_left          14
dxl_id_right         10
fan1_pct             0
fan2_pct             100
gyro_scale           1.0
max_angular          1.5
max_linear           0.18
robot_id             1  (identity, never restored)
wheel_radius_left    0.02597
wheel_radius_right   0.02597
wheel_separation     0.14
wheel_servo_model    18

En modifier un

ros2 param set /ratbot_1/ratbot_controller fan2_pct 100

Le changement prend effet immédiatement, sans redémarrage — sauf robot_id, qui fige l’espace de noms à la création du nœud, et wheel_servo_model, car la carte ne change pas de protocole sous un robot qui roule.

Important

L’écriture en flash est temporisée de 3 secondes. C’est délibéré : quand on règle dix paramètres à la suite, une mémoire flash ne doit pas encaisser dix cycles d’effacement.

Conséquence : si vous coupez le robot dans la seconde qui suit un param set, la valeur est perdue. Laissez-lui trois secondes.

Sauvegarder et restaurer

Sauvegarder

./scripts/ratbot config 1 save mes_reglages.yaml \
    --origin "avant flash du nouveau firmware"

Le fichier obtenu se relit tout seul :

robot_id: 1
date: '2026-09-26T10:51:25'
firmware: cb83d48
origin: avant flash du nouveau firmware
parameters:
  wheel_radius_left: 0.02597
  wheel_radius_right: 0.02597
  wheel_separation: 0.14
  dxl_id_left: 14
  ...

Les quatre premières lignes ne servent pas à la restauration : elles servent à comprendre le fichier dans six mois. Une liste de nombres nue ne dit rien.

Astuce

--firmware complète le champ correspondant. La carte n’annonce pas sa version, donc l’outil ne peut pas la deviner — et il préfère laisser le champ vide qu’inscrire une valeur fausse d’apparence sûre.

Restaurer

./scripts/ratbot config 1 load mes_reglages.yaml

L’outil affiche ce qu’il change, puis relit la carte pour vérifier que tout a bien été appliqué — la carte peut refuser une valeur hors bornes, et un succès annoncé sur une carte inchangée serait le pire des cas.

Trois comportements valent d’être connus :

Il refuse un fichier venant d’un autre robot.

this file comes from ratbot-2, target is ratbot-1. REFUSED.
  Add --force if this is intended.

Avec quatre robots et quatre fichiers qui se ressemblent, l’erreur arrivera. Et elle ne casse rien de visible : le robot roule, son odométrie est simplement fausse, et on le découvre une semaine plus tard.

Il ne restaure jamais ``robot_id``. Ce paramètre est l’identité du robot, pas un réglage : le restaurer ferait disparaître /ratbot_1/ du réseau.

Il ignore les paramètres que le firmware ne connaît plus, en les nommant :

skipped, unknown to this firmware: wheel_radius

C’est exactement le cas d’une sauvegarde faite avant une mise à jour qui a renommé un champ. Échouer en bloc laisserait la carte à moitié restaurée.

Quand sauvegarder

Moment

Pourquoi

Avant chaque flash

Un changement de format de configuration efface tout, identifiants des moteurs compris. Voir l’avertissement ci-dessous.

Avant une calibration

Pour pouvoir revenir en arrière si le résultat déçoit.

Après une calibration

C’est le résultat d’une heure de mesures.

Avant de démonter une roue

Le rayon effectif change au remontage.

Danger

Un changement de version de configuration efface les réglages en silence. Quand le firmware évolue et ajoute ou renomme un champ, la carte ne sait plus lire ce qui est stocké et repart des valeurs d’usine. Aucun message, aucun voyant — et si les valeurs d’usine ressemblent aux vôtres, vous ne verrez rien.

La parade tient en trois lignes :

./scripts/ratbot config 1 save avant_flash.yaml
# ... flash du firmware ...
./scripts/ratbot config 1 load avant_flash.yaml

Note

Exception : le passage de la version 4 à la version 5 (octobre 2026, ajout de wheel_servo_model) garde les réglages. La carte relit l’ancien format et le convertit ; elle ne l’efface plus. La sauvegarde avant flash reste la règle pour les changements à venir.

Les garder avec le robot

Rangez vos sauvegardes dans le dépôt, une par robot, et versionnez-les :

cahier_de_labo/config/
    ratbot1.yaml
    ratbot2.yaml

Vous aurez ainsi l’historique de chaque réglage, avec sa date et son origine. Le jour où une carte meurt, vous en montez une neuve et vous rechargez le fichier.

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 vous déplacez une carte d’un châssis à l’autre, rechargez le fichier du châssis d’accueil.

Voir aussi