Apprendre le pliage bimanuel de serviettes par démonstration

Linique était un projet de fin d’études réalisé par six personnes à l’UBC sur le pliage bimanuel de serviettes à partir d’images et de l’état articulaire.

Le résultat central était que la taille du modèle ne suffisait pas à résoudre la tâche. Le pliage du tissu est temporellement ambigu : deux observations peuvent sembler presque identiques tout en exigeant des actions différentes, car l’une appartient à la saisie, une autre à l’alignement et une autre au relâchement. Nos résultats suggèrent deux approches pratiques : recueillir assez de démonstrations pour couvrir ces transitions, ou représenter explicitement l’étape et la progression pendant l’entraînement.

Pourquoi la répétition d’une trajectoire échoue avec du tissu

Une serviette en lin n’a pas de modèle cinématique fixe. Son prochain état dépend du frottement sur la table, de la rigidité en flexion, de l’auto-contact, des plis, du point de préhension et de la tension entre les bras. Une erreur de quelques millimètres à la saisie peut transformer la même trajectoire articulaire en un pli différent.

La simulation constituait donc un mauvais raccourci. Un simulateur de tissu utile aurait nécessité un modèle déformable finement discrétisé, par éléments finis, particules ou méthode équivalente; l’identification de la rigidité selon la chaîne et la trame, de la flexion, de l’amortissement et du frottement; ainsi qu’une gestion stable de l’auto-collision et des contacts avec la table et les pinces. Ces paramètres sont difficiles à mesurer, coûteux à simuler et déterminants : un léger écart change l’endroit où la serviette flambe ou accroche et produit une autre séquence de contacts. L’écart entre simulation et réalité dépassait la variation que nous cherchions à apprendre. Nous avons donc recueilli les démonstrations et testé le mécanisme sur le système physique plutôt que d’entraîner la politique en simulation.

Notre système comprenait :

• deux bras suiveurs SO-101 et deux bras maîtres pour la téléopération;
• trois observations RVB : vue du dessus, gauche et droite;
• 12 positions articulaires en entrée et 12 positions cibles en sortie;
• une boucle de commande et d’enregistrement à 30 Hz; et
• une zone de travail d’environ 914 × 607 mm sous un portique d’éclairage et de caméras.

Les archives du projet ne définissent pas de seuil numérique de qualité du pli. Nous jugions la saisie et le pli pendant les essais physiques. Cela suffit pour un prototype, mais pas pour comparer rigoureusement des taux de réussite. Une prochaine évaluation devrait définir à l’avance la saisie, la géométrie finale, le temps de cycle et le nombre de réussites autonomes consécutives.

Un premier prototype de collecte. Les opérateurs déplaçaient les deux bras maîtres; les bras suiveurs reproduisaient le mouvement pendant que le système enregistrait les observations synchronisées. Le banc ultérieur a amélioré les caméras, l'éclairage et l'intégration mécanique.

Concevoir l’interaction avant d’entraîner la politique

Le tissu faisait de l’effecteur une partie du problème d’apprentissage. Une saisie rapide qui entraînait ou froissait la serviette créait une condition initiale différente pour la politique. Nous avons donc réalisé une matrice d’essais manuels sur quatre effecteurs, deux états de la serviette, plusieurs opérateurs et des approches par le bord avant et latéral. Chaque observation mesurait le temps nécessaire pour saisir et soulever la serviette d’un pouce, ainsi que la présence d’un froissement.

Le tableau reprend les étiquettes d’origine de la feuille d’essais. « À plat » et « pliée » sont deux conditions de saisie distinctes, pas des essais de politique autonome.

EES était plus lente que la géométrie la plus rapide, mais c’était la seule conception sans froissement enregistré. Tester ce critère directement sur la serviette était plus utile pour la conception que d’essayer d’identifier un modèle complet du tissu et des contacts.

Ce que contient une démonstration

Pendant la téléopération, le système synchronisait trois flux vidéo avec les positions articulaires et les actions commandées des deux bras. Les épisodes étaient stockés au format LeRobot afin que la collecte, l’inspection, l’entraînement et l’inférence utilisent le même schéma.

Le jeu de données publié contient 499 épisodes : 400 démonstrations de la tâche complète et 99 consacrées à la saisie. Son fichier meta/info.json indique 544 906 trames enregistrées. Le visualiseur LeRobot ci-dessous ouvre l’épisode 0 avec les vidéos synchronisées, l’état du robot, les actions et les statistiques de l’épisode; le sélecteur permet d’explorer le reste du jeu de données.

Le logiciel de collecte devait aussi résister aux pannes ordinaires de la robotique : caméras reconnectées sous de nouveaux chemins, exposition qui dérive, trames MJPEG tronquées, bus USB saturé, épisodes interrompus et visualisation en concurrence avec la cadence de commande. Des chemins de périphériques stables, la séparation physique du trafic USB, l’exposition fixe, les contrôles d’état et les écritures reprenables étaient aussi importants que le code du modèle.

L’« effort » des moteurs n’était pas un couple

Les moteurs Feetech du SO-101 ne fournissent pas un couple articulaire étalonné. Ils exposent une valeur brute Present_Load, appelée « effort » dans certaines parties de la pile logicielle. C’est une estimation interne et grossière du contrôleur, pas un capteur de force ou de couple.

LeRobot n’incluait pas initialement cette valeur dans le chemin d’observation et de données que nous utilisions. Nous avons créé notre propre fork de LeRobot, modifié le code des moteurs et du robot pour lire et enregistrer l’effort avec la position, puis collecté des données afin de vérifier si une politique pouvait en déduire le contact ou la tension de la serviette. L’enregistrement de Present_Load a confirmé que le signal était trop grossier pour estimer l’un ou l’autre de façon fiable.

Le dépôt de production conserve un outil de diagnostic des moteurs qui lit la charge signée, la tension, la température et les drapeaux d’erreur. Dans une prochaine version, une véritable mesure de force au bout des doigts serait beaucoup plus utile que cette approximation.

Une erreur d’étalonnage différente sur chaque bras

Le roulis du poignet peut tourner en continu; il ne peut donc pas être étalonné contre des butées mécaniques comme les autres articulations. Nous avons constaté que le chemin d’étalonnage et de traitement des positions pouvait attribuer des zéros et des transformations différents à des bras SO-101 pourtant identiques. Un bras maître et un bras suiveur pouvaient donc afficher les mêmes valeurs alors que leurs poignets étaient physiquement décalés, ou afficher des valeurs différentes dans la même pose.

Nous avons passé plusieurs semaines à reproduire le problème et à travailler avec l’équipe LeRobot sur Discord. Nous avons fourni des observations matérielles et des cas d’essai pendant que la cause était recherchée dans la configuration du STS3215 et la gestion des positions multi-tours. Le problème a ensuite été documenté publiquement dans l’incident d’étalonnage du roulis du poignet SO-101, et le correctif moteur amont a forcé le servomoteur à revenir en lecture mono-tour afin que les positions bouclent de façon cohérente entre 0 et 4095. Le changement amont a corrigé le même comportement pour les autres utilisateurs du SO-101.

Entre-temps, conserver l’étalonnage comme état local de chaque périphérique était trop fragile. Nous avons placé les quatre fichiers JSON propres aux bras dans robo-ops et transmis explicitement le répertoire d’étalonnage du dépôt à chaque constructeur de robot et de téléopérateur. Le dépôt garantissait ainsi que chaque ordinateur chargeait l’étalonnage associé au code et au jeu de données. L’implémentation actuelle se trouve dans lib/robots.py.

La famine du processeur ressemblait à un défaut de commande

La boucle à 30 Hz ne dispose que de 33,3 ms pour lire jusqu’à quatre bus de moteurs et trois caméras, préparer les observations, exécuter la politique, envoyer les actions, éventuellement enregistrer et mettre à jour la visualisation. Si ce travail prend plus longtemps, sleep(max(period - elapsed, 0)) devient silencieusement un sommeil nul. Rien ne plante; le robot fonctionne simplement plus lentement et de façon moins régulière. Au début, ce comportement ressemblait davantage à une instabilité de la politique ou à un problème USB qu’à une famine du processeur.

Nous avons isolé le problème en chronométrant séparément chaque partie de la boucle de commande. La boucle d’inférence mesure maintenant la latence d’observation, de politique et d’action; elle affiche la fréquence réelle par rapport à la cible ainsi que la latence p95, et avertit lorsque la cadence descend sous 95 % de 30 Hz. Ces mesures permettent de distinguer une machine surchargée d’un modèle ou d’un bus moteur lent. L’architecture de production ultérieure a déplacé la commande synchrone du robot vers un fil d’exécution dédié et exposé les images JPEG des caméras dans un tampon partagé plutôt que de laisser la diffusion Web imposer la cadence de commande.

ACT a révélé le problème de transition entre les étapes

Notre première référence était ACT, un transformeur qui prédit des blocs d’actions. Il prédisait 100 actions à partir des caméras et de l’état du robot; un moyennage temporel lissait les prédictions qui se chevauchaient pendant l’exécution.

Le chemin d’entraînement ACT révélait aussi une lacune d’outillage. Il acceptait une valeur fixe optimizer_lr, mais ne proposait ni ordonnanceur de taux d’apprentissage ni recherche automatique. Nous avons donc rendu le taux d’apprentissage propre à chaque environnement, effectué des balayages manuels dans Weights & Biases et sauvegardé l’état de l’optimiseur pour reprendre les tâches. L’entraîneur SARM ultérieur a ajouté la création, l’avancement et la sauvegarde de l’ordonnanceur, ainsi que la journalisation du taux d’apprentissage. Sans ordonnanceur ni balayage manuel, une tâche de 100 000 étapes pouvait consacrer l’essentiel de son calcul à un taux inadapté.

La perte d’optimisation a diminué puis atteint un plateau :

La baisse de la perte confirmait qu’ACT ajustait les démonstrations, mais seuls les essais physiques permettaient d’évaluer le pliage.

Les essais physiques ont révélé une distinction plus nette :

1. Une politique de saisie seule réussissait généralement à établir une prise lors de nos essais informels.
2. À partir d’une prise initiale assistée par une personne, une politique de pliage seule pouvait répéter le mouvement ultérieur.
3. Une politique unifiée de saisie et de pliage était beaucoup moins fiable.

Ces observations sur ACT n’ont pas été consignées avec un nombre constant d’essais; leur attribuer un pourcentage serait donc trompeur. Nous les avons utilisées pour situer l’échec à la transition entre la saisie et le pliage. Isoler les deux étapes supprimait la frontière temporelle la plus ambiguë. Dans la tâche combinée, une géométrie de tissu similaire pouvait demander d’approcher, de maintenir la tension, de former un pli ou de relâcher, selon les secondes précédentes. Une faible perte d’imitation moyenne pouvait masquer précisément cette transition multimodale.

Une machine à états reliant deux politiques constituerait une référence utile, mais elle encoderait manuellement la frontière entre les étapes. Une politique de bout en bout doit plutôt déduire la phase et la progression à partir des démonstrations. Avec 499 épisodes, il était plus pratique de fournir cette structure temporelle explicitement que d’attendre de la politique qu’elle la découvre seule.

SmolVLA et modélisation de récompense sensible aux étapes

Nous avons ensuite entraîné des points de contrôle SmolVLA et X-VLA sur la même famille de tâches. Les représentations visuelles préentraînées ont aidé SmolVLA à lever partiellement l’ambiguïté de la séquence, mais il n’a terminé qu’environ 40 % des essais physiques. Comme les modèles n’ont pas été évalués selon un protocole d’essais commun, leurs résultats ne sont pas directement comparables.

Nous avons ensuite implémenté SARM comme modèle distinct d’étape et de progression. Il ne commande pas le robot. Le modèle observe une fenêtre temporelle de vidéo et d’état du robot, classe l’étape courante — saisie, alignement, pliage ou relâchement — et estime la progression à l’intérieur de cette étape. Il transforme ainsi l’unique bit de réussite à la fin d’un essai en une estimation dense de la progression de 0 à 1. Les échantillons d’entraînement comprennent aussi de courts retours en arrière, ce qui oblige le modèle à utiliser l’ordre temporel lorsque deux images individuelles se ressemblent.

Ce modèle de progression peut ensuite repondérer les démonstrations pour un clonage comportemental aligné sur la récompense avant l’entraînement d’une politique SmolVLA ou PI0. SARM fournit des étiquettes explicites d’étape et de progression que la politique de bout en bout n’a pas déduites de façon fiable à partir de 499 épisodes. Apprendre la même structure sans SARM exigerait un jeu de données beaucoup plus vaste couvrant les variations, les échecs, les reprises et les transitions entre étapes.

La politique ne peut toujours pas observer directement le contact, la force de préhension ou la tension du tissu, car ses entrées se limitent aux images RVB et aux positions articulaires. Des doigts sensibles à la force amélioreraient l’observation du contact, tandis qu’une variation contrôlée de l’état initial, des démonstrations correctives et des exemples d’échec élargiraient les états représentés pendant l’entraînement.

Une même expérience sur quatre types de calcul

Nous avons entraîné les modèles localement, sur Modal et RunPod, et sur la grappe Slurm Sockeye de l’UBC. En pratique, le transfert des données, la préparation des environnements et la récupération des artefacts prenaient souvent plus de temps que le calcul sur GPU.

• En local, l’itération était la plus rapide puisque données, caméras, code et poids étaient déjà réunis.
• Modal / RunPod facilitaient l’accès ponctuel aux GPU, au prix des téléversements, des démarrages à froid, des environnements dupliqués et de la gestion des artefacts.
• Sockeye fournissait des V100 et la reproductibilité de Slurm, mais les nœuds de calcul n’avaient pas accès à Internet, le stockage du projet était en lecture seule pendant les tâches et l’espace temporaire inscriptible pouvait être purgé. Il fallait préparer dépendances et poids, utiliser Weights & Biases hors ligne et recopier les résultats.

Pour ce volume de données, un GPU local plus lent pouvait terminer une itération plus tôt une fois comptabilisés l’empaquetage distant, le téléversement et la récupération des artefacts. Cela nous a conduits à séparer dans le dépôt les outils de collecte, réparation, visualisation, entraînement et inférence plutôt qu’à tout enfermer dans un carnet lié à une seule machine.

Équipe et responsabilités

Le projet réunissait trois disciplines, et la répartition du travail est importante :

• J’étais responsable du logiciel et de la pile d’apprentissage robotique : interfaces matérielles, intégration des étalonnages, collecte et réparation synchronisées, visualisation Rerun, entraînement et inférence des politiques, fiabilité temporelle et USB, service de commande de production, et transfert des expériences entre les environnements local, infonuagique et HPC. La majeure partie de cette implémentation est disponible dans robo-ops.
• Sloan Sobie et Dawson March, tous deux étudiants en génie mécanique, se sont principalement consacrés à la conception mécanique, la fabrication, les effecteurs et l’intégration du système physique.
• Genevieve Merz, Cameron Powell et Jaden Legate, tous trois étudiants à Sauder, ont dirigé la découverte du marché par des entretiens avec des restaurants et des entreprises en démarrage, la validation du problème client et le positionnement du produit.

Le travail d’ingénierie et l’étude de marché ont avancé en parallèle, ce qui nous a permis d’évaluer le prototype dans le contexte de restauration auquel il était destiné.

Affiche, rapport et code source

Nous avons présenté l’affiche ci-dessous à l’assemblée générale annuelle de la section de Vancouver de l’IEEE. Sélectionnez-la pour ouvrir le PDF complet.

Ouvrir l'affiche · code source de l'affiche

Le rapport technique final de 55 pages contient les exigences complètes, la conception mécanique et logicielle, les résultats de vérification, l’étude de marché et les annexes. (Écrit en Typst.)

L’implémentation se trouve dans le dépôt public robo-ops, le cadre robotique modifié dans le fork LeRobot de Linique, et le reste du projet dans l’organisation GitHub Linique.

Suggestions de lecture :

• HTTP 418 : Robot autonome de recherche d'indices en simulation