Bloom, une interface opérateur pour robots d’assistance

• 140fiches de décision, une par choix d’architecture
• 960+tests automatisés, 620 côté frontend et 342 côté backend
• 17contrats d’applications vérifiés à chaque release
• 2robots pilotés de bout en bout en simulation par la CI

Problème

Les interfaces précédentes liaient la mise en page, les périphériques, le transport ROS et un seul robot. Chaque étude, nouveau périphérique ou second robot demandait du nouveau code, et la sécurité était dispersée entre écran et robot.

Objectif

Un seul système d’interface que les chercheurs reconfigurent sans développeur, auquel les opérateurs font confiance, et que les cliniciens peuvent mettre devant un participant.

Mon rôle

Cadrage produit, UX, architecture et livraison, puis l’accompagnement de l’équipe.

Sept décisions produit, et pourquoi

1. 01
   Un modèle de commande, deux surfacesUn Builder visuel et un Runtime kiosque affichent le même modèle : l’opérateur reçoit exactement ce qui a été revu.
2. 02
   La sécurité vit dans le backendListes autorisées, limites de débit, validation, journal d’audit et un seul détenteur de commande par session : aucun écran ne peut les contourner.
3. 03
   Un STOP verrouillé accessible à tousRéservé sur chaque écran, il refuse toute source de commande jusqu’à sa libération, même pour un superviseur en lecture seule.
4. 04
   Une revue avant qu’un écran n’arrive devant un utilisateurUne checklist repère les cibles inatteignables, les commandes trop petites et un STOP manquant. Les constats bloquent au lieu d’avertir.
5. 05
   ROS reste à la frontière des adaptateursLe frontend n’importe jamais ROS : Bloom a survécu à la réécriture de la commande et peut servir d’autres robots.
6. 06
   Simulation d’abord, la CI pilote les robotsChaque release tourne de bout en bout sur les deux simulations, le temps matériel sert donc à la validation.
7. 07
   Livrer les applications, pas seulement l’outilDes applications prêtes à ouvrir en dix minutes ont rendu le produit concret pour l’équipe avant même qu’il soit fini.

Utilisateurs et contraintesPour qui est Bloom, et avec quoi il a dû composer

Opérateurs

Des personnes à mobilité réduite des membres supérieurs, qui pilotent le bras depuis une tablette, un joystick, une manette ou un simple contacteur.

Chercheurs & cliniciens

Ils mènent des études et doivent composer un écran, le revoir et le confier à un participant en sécurité.

Contexte médical

Sécurité guidée par le risque, comportement traçable et journal d’audit, pas seulement une démo qui marche.

Deux robots

Orthopus Explorer et Kinova Gen3, aux limites différentes : Explorer n’a pas de collecteur tournant et a des butées articulaires strictes.

Matériel & équipe

Tablettes de labo en 1024 × 600, trois langues, et une commande réécrite en parallèle.

Ce qui a été livréBloom 0.2.0, licence MIT, septembre 2026

Entrées

Tactile, clavier et manette combinés en une commande 6 DoF, plus des profils de balayage à contacteur unique.

Applications

Explorer Manager et Kinova Manager : Drive, Positions, retour robot, sources de commande, Joystick Lab et un miroir superviseur.

Accès

Interfaces en anglais, espagnol et français, entraînement guidé de l’opérateur, et une vue debug avec les états articulaires en direct.

ROS 2

Adaptateurs pour le gestionnaire de commande, les topics, services, la découverte et le flux caméra de la pince.

Ouvert

Release 0.2.0 sous MIT, avec tutoriels, guide de sécurité opérateur et fiches de décision.

Ce que je ferais ensuiteRecette matérielle, petits écrans, zones de sécurité

• La recette matérielle sur les tablettes cibles et les deux bras, avec les contacteurs pour lesquels les profils de balayage ont été conçus.
• Les mises en page 1024 × 600 issues de la passation design, puis une relecture native de l’espagnol et du français.
• Des zones de sécurité dans l’interface, dès que le contrôleur exposera les contraintes cartésiennes déjà gérées par la bibliothèque QP.
• Une courte explication du mode de commande hybride, pour que chercheurs, cliniciens et opérateurs le décrivent de la même façon.

Le reste du travail sur ExtenderPlateforme, commande, recherche et coordination

Plateforme

Migration de l’espace de travail vers Ubuntu 24.04 et ROS 2 Jazzy ; maintenance du point d’entrée, du guide de build et de l’environnement Python partagé.

Première interface

Construction puis retrait de la première téléopération tablette, une fois couverte par Bloom.

Commande

Connexion de Bloom à la nouvelle architecture de commande en trois couches, avec l’asservissement visuel et la détection AprilTag.

Démonstrateur

Portage du démonstrateur d’assistance Pétanque (PEPR Robotique) sur la nouvelle stack.

Onboarding

Rédaction du profil de l’organisation, des tutoriels et des règles de contribution.

Recherche

Contrôle partagé et manipulation d’assistance, soumissions d’articles (ICRA), coordination avec cliniciens et partenaires.