Téléopération, les bases : comment les robots apprennent des mains humaines

Imaginez une doctorante dans un laboratoire de robotique, une main enroulée autour d’un petit bras leader, l’autre stabilisant une tasse de café. Lorsqu’elle déplace le bras leader, un bras follower à l’autre bout de la paillasse la reproduit, pince pour pince, jusqu’à ce qu’une serviette soit pliée en un carré net. Elle secoue la serviette et recommence. Puis recommence encore. À la fin de l’après-midi, elle a enregistré deux cents pliages, et chacun d’eux est un exemple d’entraînement.

C’est de là que provient une large part des données de manipulation robotique d’aujourd’hui. Ni récupérées sur le web, ni générées de toutes pièces en simulation, mais exécutées par un humain qui pilote un robot en temps réel. Le jeu de données ouvert DROID offre un bon point de repère : environ 76 000 trajectoires de démonstration et près de 350 heures d’interaction, recueillies dans 13 institutions par une cinquantaine d’opérateurs au fil d’une année de collecte. À côté des corpus de mille milliards de tokens qui sous-tendent les modèles de langage, c’est minuscule. Chaque trajectoire a été gagnée à la main.

La téléopération est le cheval de labour de l’embodied AI (IA incarnée), et elle est bien moins spectaculaire que les modèles qu’elle alimente. Cet article parcourt le pipeline de démonstration de bout en bout : ce que contient réellement une seule démonstration, les rigs que les opérateurs utilisent pour la produire, pourquoi la latence dégrade discrètement les données, et le travail d’annotation et d’assurance qualité qui décide si un enregistrement devient signal ou bruit.

Ce qu’est réellement une démonstration

Faites abstraction du vocabulaire, et une démonstration n’est qu’un faisceau synchronisé de séries temporelles. Pour chaque instant d’un épisode, le rig enregistre ce que le robot a vu, où se trouvait son corps, et ce que l’opérateur lui a demandé de faire.

• Observations : un ou plusieurs flux RGB, une caméra de poignet plus une caméra de scène étant courant, parfois de la profondeur, parfois des mesures tactiles.
• Proprioception : angles articulaires, pose de l’effecteur terminal, largeur d’ouverture de la pince, forces au poignet.
• Actions : les commandes émises par l’opérateur, généralement des poses cibles ou des deltas articulaires, plus un signal d’ouverture ou de fermeture de la pince.
• Métadonnées : une étiquette de tâche, un indicateur de succès, des horodatages, la calibration des caméras, et l’embodiment du robot.

Un épisode est une tentative sur une tâche, de la réinitialisation à l’état terminal, durant généralement de quelques secondes à une minute. La fréquence d’échantillonnage compte plus qu’il n’y paraît : les montages bimanuels de type ALOHA enregistrent autour de 50 Hz, si bien qu’un pliage de quinze secondes représente environ 750 images synchronisées. Échantillonnez trop lentement et les mouvements rapides se replient ; trop vite, et vous noyez le stockage et les dataloaders sous des images redondantes. Il y a aussi un choix plus discret caché dans le flux d’actions : consigner des poses cibles absolues ou des deltas relatifs. Les actions absolues sont faciles à rejouer mais lient les données à une configuration d’espace de travail donnée ; les deltas se transposent mieux d’un montage à l’autre, mais accumulent de petites erreurs. La fréquence et le format d’action sont des décisions précoces, et toutes deux sont difficiles à changer après coup.

Les rigs, du bras leader à la VR

L’interface entre l’humain et le robot façonne tout ce qui vient ensuite : le naturel du mouvement, la vitesse à laquelle les épisodes s’accumulent, et les erreurs qui se retrouvent figées dans les données. Il n’y a pas de vainqueur unique, seulement des compromis.

Deux forces s’opposent. Les rigs à haute fidélité, comme les bras leader à retour d’effort, capturent la compliance subtile qu’exige une tâche riche en contacts, mais ils sont coûteux et plus lents à opérer. Les rigs moins chers, comme une SpaceMouse, se déploient à grande échelle sur de nombreux postes répartis dans de nombreux bâtiments, au prix d’un mouvement qui paraît plus robotique. Les manettes VR portables passent à l’échelle de la même manière, et c’est précisément ainsi que DROID a atteint sa diversité de scènes sur de nombreux sites. Le bon choix dépend de savoir si le goulot d’étranglement est le volume de données ou leur richesse.

La latence est la taxe cachée

Chaque montage de téléopération est une boucle de commande avec un humain à l’intérieur. L’opérateur voit une image vidéo, décide, déplace la manette ; la commande voyage jusqu’au robot, le robot bouge, et la nouvelle image revient. Additionnez l’exposition et l’encodage de la caméra, les sauts réseau, les cycles de commande et l’affichage, et l’aller-retour descend rarement sous les 100 ms, même sur une paillasse locale. Sur un réseau, cela peut être bien pire.

On commence à percevoir une boucle comme molle autour de 100 à 150 ms, et l’on compense comme le ferait n’importe quel conducteur sur une connexion à la traîne : on ralentit, on dépasse la cible puis on corrige, on avance par petits pas prudents. Ces compensations sont fidèlement enregistrées comme des actions. Une policy (politique de contrôle) entraînée sur des démonstrations à forte latence apprend l’hésitation comme si elle faisait partie de la tâche. C’est l’une des raisons pour lesquelles un rig propre et à faible latence produit des données qui entraînent mieux, et pas seulement des données plus agréables à collecter.

Il existe aussi une défaillance plus subtile. Si les flux d’observation et d’action sont horodatés sur des horloges différentes et jamais correctement alignés, le jeu de données enseigne au modèle que le robot a bougé avant la commande qui l’a provoqué. La synchronisation temporelle infra-image est une plomberie sans éclat, et c’est là que se loge une part surprenante de corruption silencieuse des données.

Une policy de robot hérite des habitudes de ceux qui l’ont manipulée comme une marionnette. Si chaque opérateur hésite au même endroit, le modèle hésitera lui aussi, et aucune quantité de paramètres ne l’en dissuadera.

Des séquences aux étiquettes

Un enregistrement brut n’est pas encore exploitable pour l’entraînement. Les modèles vision-langage-action (VLA) modernes attendent que chaque épisode porte une instruction en langage naturel, comme plier la serviette ou poser la tasse sur l’étagère, et souvent une structure plus fine : des segments de sous-tâches, des images-clés à la saisie et au relâchement, et une étiquette de succès ou d’échec fiable.

Une partie peut être gabaritée dès la collecte ; l’opérateur choisit la tâche dans un menu avant chaque épisode. Le reste relève de la revue humaine : visionner les séquences, corriger les résultats mal étiquetés, et rédiger ou vérifier le texte. Des boîtes à outils comme LeRobot ont standardisé le format d’épisode, de sorte que des jeux de données issus de laboratoires et de robots différents puissent être mutualisés, ce qui est le principe fondateur des travaux cross-embodiment tels qu’Open X-Embodiment. Une astuce utile empruntée à l’apprentissage par renforcement est le réétiquetage a posteriori (hindsight relabeling) : une exécution qui a manqué la cible visée a tout de même réussi ce qu’elle a réellement accompli, et peut donc être réétiquetée avec l’objectif atteint plutôt que jetée. La cohérence des étiquettes entre les sources se révèle compter autant que le simple nombre d’épisodes.

Le contrôle qualité, la frontière entre données et bruit

La collecte produit un tas d’épisodes. L’assurance qualité décide lesquels survivent, et c’est là qu’une grande partie de la valeur se crée.

• Filtrage des succès : écarter ou réétiqueter les tentatives ratées, sauf lorsque les échecs sont conservés à dessein pour apprendre le comportement de récupération.
• Vérifications de synchronisation et de calibration : confirmer que les paramètres extrinsèques des caméras, les horodatages et la proprioception concordent, et signaler la dérive à mesure que les fixations se desserrent au fil d’une longue session.
• Détection des valeurs aberrantes et des doublons : repérer les images perdues, les flux figés et les épisodes quasi identiques qui gonflent les décomptes sans apporter de diversité.
• Validation par rejeu : réexécuter les actions enregistrées sur le robot ou en simulation pour confirmer qu’elles reproduisent le résultat.

Les jeux de données qui documentent ce processus, avec RH20T comme exemple ouvert qui détaille son protocole multi-robots et multi-capteurs, sont bien plus utiles qu’un dépôt plus volumineux sans provenance. En pratique, les équipes jettent couramment une fraction non négligeable de ce qu’elles enregistrent. Le taux de rejet est une fonctionnalité, pas un échec.

Où va vraiment l’effort

Le chiffre en une d’un jeu de données robotique est le nombre de démonstrations. Le chiffre qui prédit si une policy généralise est plus difficile à imprimer : la diversité des scènes, la propreté de l’alignement temporel, l’honnêteté avec laquelle les échecs ont été étiquetés, la cohérence du langage d’un opérateur à l’autre. La téléopération a l’air d’être la partie facile, une personne qui promène un robot. L’ingénierie qui transforme ces mouvements en données d’entraînement est la partie difficile, et c’est celle qu’il vaut la peine de réussir.