Écran, boutons et LEDs ====================== **S'applique à :** :bdg-info-line:`Simulation` :bdg-warning-line:`Robot réel` Le RatBot dispose d'un écran OLED monochrome 128 × 64 affichant une tête de souris expressive et des messages, de six boutons de navigation, de quatre boutons utilisateur (SW1 à SW4) et de quatre LEDs utilisateur. L'ensemble permet de connaître l'état du robot et de déclencher des missions sans poste de travail connecté. Deux niveaux se partagent l'écran : - **la carte du robot** affiche seule son animation de repos, et toute expression qu'on lui demande sur ``screen/expression`` ; - **un orchestrateur**, ``screen_manager``, choisit l'expression selon l'état du robot et gère le **menu**. .. warning:: **Sur le robot réel, l'orchestrateur ne fonctionne pas encore.** Il n'est pas lancé par le robot, et il publie ses ordres sur ``screen/command``, alors que la carte écoute ``screen/expression`` : les deux ne se parlent pas. Le robot réel affiche donc son animation de repos et les expressions demandées à la main ; les expressions selon l'état et le menu n'existent pour l'instant qu'en **simulation**, avec l'émulateur d'écran. Lancement --------- .. tab-set:: :sync-group: env .. tab-item:: Simulation :sync: sim L'option ``screen:=true`` de la simulation ouvre l'écran de chaque robot (voir :doc:`simulation`) : .. code-block:: bash ./scripts/ratbot up rooms 2 screen:=true Pour une simulation déjà lancée, l'écran d'un robot s'ouvre seul : .. code-block:: bash ros2 launch ratbot_status screen.launch.py robot_id:=1 Lancer également ``status.launch.py`` pour que l'écran reflète l'état du robot. Une fenêtre émule l'écran, ses boutons et ses LED. .. tab-item:: Robot réel :sync: reel Rien à lancer : l'écran est piloté par la carte du robot dès la mise sous tension. Voir l'avertissement ci-dessus pour l'orchestrateur. .. image:: _static/ecran/emulateur.png :align: center :width: 60% Affichage --------- En l'absence de commande, l'écran joue une **animation de repos** — clignements, regards, clins d'œil — exécutée localement par la carte STM32. Elle ne dépend pas de ROS et se poursuit si la couche haut niveau est indisponible ; un écran figé signale donc un dysfonctionnement de la carte elle-même. Avec l'orchestrateur — en simulation, pour l'instant —, l'écran reflète ``status/state`` : expression associée à l'activité en cours, ou message pour les états d'alerte (« Batterie faible », « ARRET URGENCE »). L'association état → expression ou message est définie dans ``ratbot_status/config/faces.yaml`` ; les images sont dans ``ratbot_sim/faces/``. Piloter l'écran à la main ------------------------- Sans lancer quoi que ce soit d'autre, on peut choisir une expression et lire les boutons de navigation : .. code-block:: bash ros2 topic pub --once /ratbot_1/screen/expression std_msgs/msg/String "data: fache" ros2 topic echo /ratbot_1/screen/button Les expressions disponibles sur le robot réel sont celles embarquées dans la carte : .. list-table:: :header-rows: 1 :widths: 40 60 * - Nom - Ce qu'elle montre * - ``ratbot_logo`` - le visage au repos * - ``clin_doeil_droit`` - clin d'œil à droite * - ``clin_doeil_gauche`` - clin d'œil à gauche * - ``clin_doeil_gauche_droite`` - les deux yeux fermés * - ``fache`` - fâché * - ``triste`` - triste Un nom inconnu **ne change rien** : l'écran garde ce qu'il affiche. Effacer l'écran sur une faute de frappe serait pire que d'ignorer la demande. Le compteur ``noms_inconnus`` de ``/diagnostics`` le signale. Les boutons de navigation sortent sur ``screen/button`` sous forme d'un numéro, publié **à l'appui** : ``1`` haut, ``2`` bas, ``3`` gauche, ``4`` droite, ``5`` OK, ``6`` ESC. .. important:: **Quand la carte reprend-elle la main ?** Un orchestrateur ROS confirme sa présence en publiant ``screen/heartbeat`` à 2 Hz. S'il se tait plus de deux secondes, la carte repart sur son animation de repos — un écran figé aurait l'air en panne. Mais cette reprise n'a lieu que si un *heartbeat* est **déjà arrivé une fois**. Autrement dit, tant que vous pilotez l'écran à la main depuis un terminal, votre image reste affichée aussi longtemps que vous voulez. Dès qu'un orchestrateur s'est manifesté, son silence redevient un signal. Au démarrage ------------ À la mise sous tension, la carte fait défiler toutes ses images puis s'arrête sur le visage au repos, en jouant un arpège. Cela se produit **avant** toute connexion à ROS : c'est le signe que la carte fonctionne, indépendamment de la Raspberry, du réseau et de l'agent micro-ROS. Si rien ne s'affiche à la mise sous tension, le problème est sur la carte ou son câblage — inutile de chercher du côté de ROS. Menu embarqué ------------- .. note:: Le menu est servi par l'orchestrateur : il ne fonctionne pour l'instant qu'en simulation (voir l'avertissement en tête de page). Au repos, **OK** ouvre le menu. Navigation par **Haut** / **Bas**, validation par **OK**, retour par **ESC**. Deux types d'entrées : - **informations** — batterie, adresse IP, identifiant du robot, état de ROS ; - **commandes** — publient une intention sur ``mission/command`` : .. list-table:: :header-rows: 1 :widths: 26 74 * - Commande - Effet * - *Explorer* - Lance ou reprend l'exploration autonome. * - *Sauver carte* - Enregistre la carte courante. * - *Retour base* - Envoie un but de navigation vers le point de départ. * - *Pause* - Suspend la mission et annule le but en cours. Les commandes marquées ``confirm`` dans la configuration affichent une question **Oui / Non**, tranchée par **Gauche** / **Droite** puis **OK**. L'exécution est assurée par ``ratbot_mission``, à lancer séparément : .. code-block:: bash ros2 launch ratbot_mission mission.launch.py robot_id:=1 .. note:: Chaque commande dépend de la couche correspondante : *Sauver carte* et *Explorer* supposent le SLAM actif, *Retour base* la navigation. En son absence, la commande est ignorée et journalisée. L'état de la mission est publié sur ``mission/state`` et reflété sur le voyant et l'écran. Le contenu du menu est défini dans ``ratbot_status/config/menu.yaml``. Boutons et LEDs utilisateur --------------------------- Les quatre LED et les boutons **SW3** et **SW4** sont laissés à la disposition de l'utilisateur. **SW1 et SW2 ont une fonction réservée**, gérée par la carte du robot : 5 appuis sur SW1 **réarment** le robot après un arrêt, et SW2 tenu 3 secondes active le **mode banc** (voir :doc:`arrets`). Un programme qui utilise ces deux boutons doit en tenir compte. - **Boutons** — publiés sur ``ui/buttons`` (``sensor_msgs/Joy``), tableau ``buttons[0..3]``, valeur ``1`` lorsque le bouton est maintenu ; - **LEDs** — commandées par ``ui/leds`` (``std_msgs/UInt8``), interprété comme un masque binaire (bit 0 → LED1, … bit 3 → LED4). .. code-block:: bash ros2 topic pub --once /ratbot_1/ui/leds std_msgs/msg/UInt8 "{data: 5}" # LED1 + LED3 ros2 topic pub --once /ratbot_1/ui/leds std_msgs/msg/UInt8 "{data: 15}" # les quatre ros2 topic echo /ratbot_1/ui/buttons .. note:: ``--once`` évite que ``ros2 topic pub`` republie indéfiniment à 1 Hz, ce qui figerait les LED. Voir :doc:`statut` pour les pièges de syntaxe YAML. Un nœud souscrivant à ``ui/buttons`` et publiant sur ``ui/leds`` fonctionne à l'identique en simulation et sur le robot réel. .. note:: Sur le **robot réel**, ces deux topics sont servis directement par le firmware de la carte depuis le 2026-09-06 : publier sur ``ui/leds`` allume physiquement les LED de façade, et un appui sur SW1 à SW4 remonte dans ``ui/buttons``. Les boutons sont publiés **à chaque changement d'état**, plus un rafraîchissement à 1 Hz — de sorte qu'un nœud démarré en retard connaisse l'état courant en une seconde au lieu d'attendre le prochain appui. Configuration ------------- - expressions et messages par état : ``ratbot_status/config/faces.yaml`` ; - images de l'écran : ``ratbot_sim/faces/`` (voir le README du dossier) ; - contenu du menu : ``ratbot_status/config/menu.yaml``. Recompiler (``colcon build``) après modification.