Les paramètres du robot ======================= **S'applique à :** :bdg-warning-line:`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é. .. warning:: **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 :ref:`sauvegarder-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 -------- .. list-table:: :header-rows: 1 :widths: 26 12 18 44 * - 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 (:doc:`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 :doc:`flotte`). * - ``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 :ref:`les roues en XL430 `. .. warning:: **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 -------- .. code-block:: bash ./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 :doc:`commande_ratbot`). .. code-block:: text 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 -------------- .. code-block:: bash 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-restaurer: Sauvegarder et restaurer ------------------------ Sauvegarder ~~~~~~~~~~~ .. code-block:: bash ./scripts/ratbot config 1 save mes_reglages.yaml \ --origin "avant flash du nouveau firmware" Le fichier obtenu se relit tout seul : .. code-block:: yaml 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. .. tip:: ``--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 ~~~~~~~~~ .. code-block:: bash ./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.** .. code-block:: text 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 : .. code-block:: text 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 ----------------- .. list-table:: :header-rows: 1 :widths: 40 60 * - 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 : .. code-block:: bash ./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 : .. code-block:: text 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 ---------- - :doc:`calibration` — d'où viennent les rayons de roue et l'entraxe. - :doc:`depannage` — quand le robot ne répond plus.