Résumé Technique : SR-Platform

Énoncé du Problème

La mise à l'échelle de l'apprentissage robotique nécessite de vastes collections d'environnements de simulation diversifiés et physiquement plausibles. Cependant, la construction de ces environnements reste un goulot d'étranglement majeur. Créer une scène MuJoCo prête à l'entraînement exige généralement une expertise en modélisation d'actifs 3D, en spécification MJCF, en agencement spatial, en évitement des collisions et en intégration de modèles de robots. Bien que les grands modèles de langage (LLM) aient démontré leur potentiel en matière de raisonnement sémantique et de synthèse de code, les approches antérieures reposent souvent sur des bibliothèques d'objets fixes, s'arrêtent à des descriptions symboliques ou nécessitent une intervention manuelle avant l'exécution. Par conséquent, le problème de bout en bout consistant à convertir une invite en langage naturel non contrainte en une scène robotique physiquement valide et prête pour le simulateur reste insuffisamment résolu.

Méthodologie : SR-Platform

SR-Platform est un système agentique déployé en production conçu pour synthétiser des environnements MuJoCo exécutables à partir de descriptions en langage naturel libre. Plutôt que de s'appuyer sur un LLM monolithique, le système emploie un pipeline à quatre couches, typé et auditable, coordonné par un PipelineCoordinator. L'architecture est déployée sous forme d'une pile Docker à neuf services utilisant le streaming WebSocket, MinIO pour le stockage des maillages, Qdrant pour la récupération sémantique, Redis pour la gestion d'état et InfluxDB pour la télémétrie.

Le pipeline se compose de quatre étapes distinctes :

1. L1 : Orchestrateur
   Cette étape convertit l'invite en langage naturel de l'utilisateur (par exemple, « une chaîne de montage avec un convoyeur et un bras robotique ») en un plan de scène structuré au format JSON. Elle définit les dimensions de la pièce, les listes d'objets, les étiquettes sémantiques, l'identité du robot sélectionné et les paramètres d'anomalie. Implémenté sous forme de flux de travail LangGraph, il sépare la planification sémantique de la génération géométrique afin de réduire la complexité du LLM et de localiser les défaillances.

2. L2 : Forge d'Actifs
   La forge d'actifs résout les étiquettes d'objets en maillages 3D compatibles avec le simulateur (STL). Elle adopte une stratégie de cache prioritaire :

   • Récupération Sémantique : Les étiquettes d'objets sont vectorisées et interrogées contre une base de données vectorielle Qdrant. Si un actif mis en cache à haute similarité existe, le STL est chargé depuis MinIO.
   • Synthèse LLM-vers-CadQuery : En l'absence de correspondance dans le cache, un LLM génère du code CadQuery pour synthétiser une nouvelle géométrie. Ce code est exécuté pour produire un maillage STL, qui est ensuite stocké et indexé pour une réutilisation future.
   • Robustesse : Le système inclut des mécanismes de validation et de réessai automatique. Si le code généré est mal formé ou si la géométrie est invalide, le système tente une régénération ou bascule vers une géométrie simplifiée pour éviter l'échec du travail.

3. L3 : Architecte de Disposition
   Cette étape attribue des poses spatiales (position et rotation) à tous les objets résolus. Elle utilise un modèle de disposition basé sur un LLM pour proposer des placements sémantiquement plausibles (par exemple, des tables sur le sol) et physiquement cohérents (sans chevauchements). Crucialement, elle intègre un IndustryRulesChecker pour vérifier des contraintes telles que les dégagements électriques, les issues de secours incendie, les distances de sécurité des machines et les dégagements de ventilation. Les violations sont renvoyées sous forme d'entrées structurées pour permettre un rééchantillonnage ou un étiquetage d'anomalies.

4. L4 : Pont et Assemblage MJCF
   L'étape finale convertit le plan de scène mis en disposition en un fichier XML MuJoCo exécutable (MJCF). Elle construit le sol, les murs et les corps des objets, en insérant les maillages STL récupérés ou générés avec leurs poses calculées. Un RobotMerger intègre le modèle de robot sélectionné (d'un catalogue incluant UR5, Franka Panda, etc.) dans la scène, en assurant la cohérence du repère de coordonnées. Cette étape est déterministe et n'implique pas d'appels aux LLM.

Contributions Clés

L'article décrit quatre contributions principales :

1. Pipeline Agentique de Bout en Bout : Un système qui convertit les descriptions d'espaces de travail en langage naturel en scènes MuJoCo exécutables contenant des modèles de robots, des actifs maillés, des poses d'objets et des coordonnées d'éclosion.
2. Forge d'Actifs Sensible au Cache : Un mécanisme combinant la récupération sémantique avec la génération LLM-vers-CadQuery, réduisant les appels LLM redondants pour les types d'objets précédemment générés.
3. Vérification de Disposition Industrielle : L'intégration de la vérification des contraintes (dégagements, sécurité, issues de secours) dans le processus de synthèse de scène avant l'assemblage MJCF.
4. Télémétrie de Production : Un rapport sur 30 jours de données de production couvrant 611 appels LLM réussis, détaillant la latence par étape, le comportement de réessai et les limites de débit.

Résultats Expérimentaux

Le système a été évalué à l'aide de données de télémétrie de production issues d'une fenêtre de déploiement de 30 jours.

• Latence : Pour une scène de cinq objets où tous les objets manquent le cache, la latence médiane de bout en bout est d'environ 50 secondes. Lorsque les objets sont récupérés depuis le cache, la latence chute à 30–40 secondes.
• Performance par Étape : La Forge d'Actifs L2 est le contributeur dominant de la latence. La latence médiane pour une génération CadQuery au premier essai (skill_generator) est de 17,9 secondes (p95 : 65,4 s). Les appels de réessai sont plus lents, avec une médiane de 24,4 secondes.
• Fiabilité : La forge d'actifs présente un taux de réessai au premier essai de 11,3 %. Les échecs sont principalement dus à un code CadQuery mal formé ou à une géométrie invalide. Les mécanismes de réessai automatique et de basculement permettent au système de récupérer sans annuler la génération complète de la scène.
• Débit : Le système prend en charge cinq travaux de génération simultanés. Le débit est limité par la génération d'actifs L2 mais peut être mis à l'échelle horizontalement en ajoutant des workers, car l'architecture partage des services sans état (Redis, MinIO, Qdrant).
• Performance des Modèles : Les benchmarks sur les CAO mécaniques et les actifs libres indiquent que claude-opus-4-6-fast atteint la plus grande précision géométrique pour les pièces mécaniques, tandis que qwen3-coder-480b offre un équilibre solide entre vitesse et coût.

Importance et Revendications

L'article présente SR-Platform comme une étape vers une génération d'environnements de simulation robotique plus évolutive et accessible. En permettant aux utilisateurs de produire des scènes MuJoCo exécutables à partir d'invites en anglais courant en moins d'une minute, le système réduit l'effort manuel requis pour construire des environnements d'entraînement diversifiés.

Les auteurs soulignent que la valeur du système réside dans sa conception orientée production : il ne s'agit pas simplement d'un prototype de recherche, mais d'un service déployé comprenant un streaming de progression en temps réel, une exécution de travaux asynchrone, une récupération d'actifs sémantique et une isolation d'état par utilisateur. L'article revendique que cette approche agentique, qui sépare la planification sémantique, la génération d'actifs, le raisonnement de disposition et l'assemblage du simulateur, permet un meilleur mise en cache, débogage et validation que les invites LLM de bout en bout uniques. De plus, l'inclusion de la vérification des contraintes industrielles vise à combler le fossé entre les scènes visuellement plausibles et les environnements physiquement valides, prêts au déploiement.

Les auteurs notent modestement des limites, reconnaissant que le système cible actuellement les environnements industriels intérieurs et semi-structurés et que le code CAO généré par LLM, bien que récupérable, n'est pas encore un compilateur déterministe garanti. Des travaux futurs sont proposés pour inclure la génération image-vers-3D, des moteurs physiques de plus haute fidélité et une exportation directe vers des formats de jeux de données d'apprentissage robotique.