Projet open source : un PC « chef d’orchestre », des ESP32 dans chaque robot, et un éditeur de briques pour composer des danses multi-MiP.
Le projet en une image
Imaginez trois petits robots équilibristes WowWee MiP sur une table. Pas trois téléphones, pas l’app Bluetooth d’origine : un seul navigateur sur un PC. Un robot avance pendant qu’un autre flash son torse en bleu et qu’un troisième joue « Hello ». Puis tous avancent ensemble. Puis pivot. Pause. Reprise.
C’est ROBOT MIP : hacker le bus UART du jouet, y brancher une ESP32-C3, et faire tourner sur le PC un master PHP qui orchestre files d’attente, groupes et programmes. Le logiciel phare pour la scène, c’est MiP Studio — un éditeur type Scratch dédié aux chorégraphies.
Pourquoi sortir le MiP de son app ?
Le MiP d’origine se pilote en Bluetooth depuis un smartphone. Sympa pour un robot. Inutilisable dès qu’on veut plusieurs robots sur une même partition : plusieurs téléphones, plusieurs doigts, zéro synchronisation fiable.
Ici, chaque MiP reçoit une carte ESP32-C3 branchée en UART à 115200 baud. L’ESP ne « joue » pas toute seule : elle parle au PC master en Wi-Fi, récupère la prochaine commande, et la traduit en octets que le robot comprend (avancer, pivot, LED torse, sons internes, etc.).
Référence protocole : WowWee MiP-Protocol.
Le PC master : le chef d’orchestre
Le cœur du système n’est pas « dans » le robot. C’est un serveur léger sur le PC (PHP 8.1+), qui tient le rôle de régie :
- Les interfaces web (tableau de bord + MiP Studio) envoient des ordres en JSON.
- Le master les range dans une file par robot (fichiers JSON, pas de base de données).
- Chaque ESP interroge le master toutes les ~150 ms : « y a-t-il quelque chose pour moi ? »
- Si oui, elle exécute la ligne (
fwd 20 60,snd 22,chests 0 0 255…) sur l’UART.
Navigateur (régisseur)
|
v
+------------------+
| PC — Master PHP |
| files JSON |
+------------------+
^ ^ ^
[ESP] [ESP] [ESP]
| | |
MiP1 MiP2 MiP3
Le PC ne parle pas directement au MiP. Il coordonne. Les ESP sont les musiciens : elles écoutent la partition (la file) et jouent sur le bus série.
Lancer le master en local :
cd master
php -S 0.0.0.0:8610
Puis http://<IP-du-PC>:8610/login.php. Mot de passe web et clé API dans includes/auth.php ; chaque firmware C3MINI.ino pointe vers l’URL du master et partage la même clé.
Deux logiciels web, deux métiers
Le tableau de bord — le pupitre
Page web avec l’image du MiP et des zones cliquables (tête, torse, base, système). On choisit un robot ou un groupe, on envoie un coup d’avancer, un flash RGB, un son nommé (« 22 — Hello », « 35 — Whaa? »).
Les groupes sont la clé pour « tout le monde fait la même chose maintenant » : le master duplique la commande dans chaque file avec le même horodatage at_ms (délai d’environ 450 ms côté serveur). Les ESP attendent cet instant avant d’exécuter — c’est la synchro « serrée » pour une figure commune.
Pour les curieux du protocole : une zone octets bruts accepte n’importe quelle séquence UART documentée (max 32 octets).
MiP Studio — composer la danse
MiP Studio est l’outil de chorégraphie. On empile des briques, on lance le programme depuis le navigateur. Ordre d’exécution : de haut en bas, comme une partition.
| Famille | Ce qu’on compose |
|---|---|
| Mouvements | Avancer, reculer, pivoter, stop ; durées en pas de ~7 ms |
| Torse & yeux | Couleur, flash RGB, LED de tête |
| Sons | Catalogue interne du MiP (libellés via Sound.txt, index 1–47 nommés sur 106 possibles) |
| Flux | Pauses, boucles, arrêt |
| En même temps | Le bloc parallèle — plusieurs robots à la même mesure |
Chaque brique d’action a sa propre cible (robot ou groupe). Pas de « robot courant » ambigu : si ça part, c’est qu’on a choisi où ça va. Le programme devient une partition lisible.
Les programmes restent dans le localStorage du navigateur (Sauver / Charger en local).
La danse des robots : comment ça se construit
Une danse, ici, ce n’est pas un fichier vidéo ni un MP3 téléversé. C’est une séquence d’actions : mouvement + lumière + son MiP, enchaînés et parfois parallèles.
Exemple : 30 secondes de démo
- Début du programme (bloc vert obligatoire).
- Parallèle — Robot 1 joue « Hello » (son 22), Robot 2 flash rouge sur le torse.
- Pause 800 ms (côté Studio, pour laisser finir le geste / le son).
- Groupe « Ligne » — tout le monde avance doucement (même commande, synchro
at_ms). - Stop moteurs sur les cibles concernées.
Lancer. Regarder. Ajuster vitesses et durées selon le sol (moquette ≠ parquet). Recommencer. C’est le cycle atelier.
Deux robots sur trois, au même moment
Scénario fréquent : trois MiP sur scène, seulement deux doivent agir ensemble.
- Bloc parallèle : à l’intérieur, « Avancer → Robot A » et « Torse bleu → Robot B ». Le troisième n’a aucune brique dans le bloc.
- Ou un groupe de deux sur le tableau de bord, puis une seule brique ciblant ce groupe — idéal quand c’est la même commande pour les deux.
Synchronisation : ce qu’on promet (et ce qu’on ne promet pas)
Deux mécanismes, deux usages :
| Besoin | Outil | Comment |
|---|---|---|
| Même action, même instant | Groupe / plusieurs robot_ids | Le master pose le même at_ms dans chaque file |
| Actions différentes, même « mesure » | Bloc En même temps | Le navigateur envoie plusieurs commandes quasi simultanément, chacune avec sa cible |
La latence réelle dépend du poll ESP (~150 ms) et du Wi-Fi 2,4 GHz. On vise une démo multi-robots convaincante, pas une synchro scénique à la milliseconde près sur dix machines. Pour une figure « tous identiques », préférer un groupe. Pour « A avance pendant que B joue un son », préférer le parallèle.
Sous le capot (version courte)
- API REST minimaliste :
queue-command.phpreçoit le JSON (op, paramètres, cible). - Conversion :
mip_command_line.phpproduit la ligne texte comprise par le firmware. - ESP32 : ping régulier (présence sur le dashboard), poll de la file, exécution UART.
- Sécurité : session web + clé API partagée avec les cartes (à configurer localement, jamais en clair sur un dépôt public).
- Stack : PHP 8.1, JavaScript vanilla, Arduino sur ESP32-C3.
Commandes supportées : réveil, roulement, pivot, LED tête, torse fixe/flash, sons (1–106), volume, statut, modes système, octets bruts. Les sons sont des échantillons déjà dans le MiP — on ne téléverse pas de MP3.
Ce que le projet ne fait pas (encore)
- Importer un son personnalisé sur le robot.
- Afficher la réponse UART du statut (
0x79) dans le Studio. - Synchroniser dix robots à la milliseconde près sur un Wi-Fi chargé.
Pistes naturelles : multi-sélection de robots sur une brique, export JSON des programmes, remontée capteurs / statut dans l’interface.
Pourquoi ça marche bien en démo
Parce que les couches se rejoignent sans se marcher dessus : protocole jouet 2014, UART, Wi-Fi embarqué, files JSON sur le PC, et une interface qui reste lisible pour un humain qui compose une danse.
Le bloc En même temps, c’est le moment « ah oui » en public. Les libellés de sons, c’est le moment « enfin » en atelier. Les cibles par brique, c’est le moment où le script devient une partition qu’on peut relire — et rejouer.
Si tu reproduis le montage : crée un groupe, ouvre MiP Studio, glisse un bloc Parallèle, choisis deux cibles — et lance ta première danse.
Protocole MiP : WowWee Labs — MiP-BLE-Protocol. Projet « ROBOT MIP » — hack UART + PC master + chorégraphie web.
