Écran, boutons et LEDs

S’applique à : Simulation 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.

Avertissement

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

L’option screen:=true de la simulation ouvre l’écran de chaque robot (voir La simulation en détail) :

./scripts/ratbot up rooms 2 screen:=true

Pour une simulation déjà lancée, l’écran d’un robot s’ouvre seul :

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.

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.

_images/emulateur.png

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 :

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 :

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.

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 Arrêter et relancer le robot). 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).

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 État du robot 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.