OpenGrall présente le mode « Ingénieur » : le robot écrit lui-même des pilotes et configure des modules

OpenGrall a décrit le mode « Ingénieur » — une architecture dans laquelle un robot peut créer des plugins, écrire des drivers et adapter le code à nouveau matériel basé sur des commandes texte. L'idée n'est pas une autonomie complète à tout prix, mais de déléguer l'intégration routinière à une LLM tout en conservant le contrôle humain.

Comment fonctionnent les rôles

Dans le projet OpenGrall, l'intelligence du robot est divisée en deux circuits. Le « Pilote » est un modèle local qui fonctionne à bord, prend rapidement des décisions et gère le mouvement en temps réel. Il voit les capteurs, lit les fichiers du projet et peut mettre à jour la mémoire, mais n'a pas le droit de modifier le code système.

Ce mode est nécessaire pour que le robot ne dépende pas du cloud pour les tâches de base et ne casse pas sa propre logique pendant le fonctionnement normal. L'« Ingénieur » s'active uniquement sur demande ou lorsqu'une tâche nécessite l'accès aux outils de développement. C'est déjà une LLM cloud qui se voit donner accès au code du projet, aux configurations et à la documentation.

Il ne se contente pas de générer du code à l'aveuglette, mais agit comme un agent séparé : étudie la structure des plugins, recherche des exemples, édite des fichiers, exécute du code dans un bac à sable et pose des questions clarificatrices au propriétaire. Si la commande ressemble à « tourne à gauche », le Pilote fonctionne ; si elle ressemble à « configure le manipulateur », le témoin passe à l'Ingénieur.

Comment fonctionne l'Ingénieur

L'idée principale du mode est de ne pas tout écrire manuellement pour chaque nouveau module. Si, par exemple, une caméra servo sur ESP32 est connectée au robot via WebSocket, le propriétaire n'a besoin que de décrire l'appareil et les commandes disponibles dans un fichier d'auto-description. Après cela, l'Ingénieur lit le projet, compare les plugins existants et crée un nouveau module pour un matériel spécifique. OpenGrall a rassemblé un ensemble séparé d'outils pour cela :

• recherche de documentation et d'exemples fonctionnels sur le web
• lecture d'articles, de spécifications et de fichiers du projet
• analyse de la structure des répertoires et des plugins existants
• édition ciblée du code et création de nouveaux fichiers
• exécution et test du code écrit dans un bac à sable isolé

Vient ensuite non pas « la magie d'un bouton », mais un cycle de développement contrôlé. D'abord, le modèle construit un squelette de classe et peut le montrer à un humain avant de générer le fichier complet. Ensuite, les méthodes sont remplies étape par étape en mode streaming pour éviter de régénérer l'intégralité du module et de perdre le contexte.

Pour l'étalonnage, l'Ingénieur peut impliquer un humain dans la boucle : lui demander de placer un objet devant la caméra, mesurer la distance jusqu'au boîtier ou confirmer que le servo a atteint l'angle souhaité. C'est particulièrement important là où une description textuelle seule ne suffit pas. L'auteur mise non seulement sur la connexion de nouveaux modules, mais aussi sur une restructuration plus profonde du système.

L'article donne un exemple avec un navigateur : la version manuelle de base d'environ 1 500 lignes de code peut être remplacée par une implémentation beaucoup plus vaste avec des trajectoires fluides, recalcul d'itinéraire à la volée et moins de secousses. En d'autres termes, on ne parle plus de générer un seul driver, mais de donner au robot un outil pour réécrire ses propres sous-systèmes pour une nouvelle tâche.

« La décision finale appartient à l'humain. »

La sécurité est maintenue par trois mécanismes simples : un bac à sable pour l'exécution du code, des sauvegardes automatiques avant chaque modification et une génération étape par étape avec vérification des résultats. Le code s'exécute avec un délai d'attente et sans appels système, une copie du fichier est créée avant modification et l'intégration dans le cycle principal ne se fait pas automatiquement. Même si le modèle commet une erreur ou suit un chemin architectural incorrect, un humain peut arrêter le processus, annuler les modifications et prendre la décision finale manuellement.

Où l'approche a ses limites

Les auteurs d'OpenGrall disent directement que le premier code généré ne doit pas être idéalisé. Les LLMs ont les mêmes problèmes chroniques : API obsolètes, dépendances inutiles, wrappers incorrects et incompatibilité avec l'environnement. La seule différence est que l'agent peut lire les logs, redémarrer les tests et faire des corrections lui-même jusqu'à ce que le module fonctionne. Mais en pratique, un tel débogage autonome peut prendre non pas des minutes, mais des heures de temps réel, surtout si le matériel est non standard ou si la documentation est brute.

Il y a aussi des limitations architecturales plus rigides. Pour configurer un manipulateur, une caméra ou un lidar, ce mode a du sens : le modèle voit la description, comprend la géométrie de la tâche et peut assembler une interface fonctionnelle sur des commandes existantes. Mais pour contrôler la démarche d'un hexapode ou d'autres tâches avec des exigences strictes en matière de vitesse et d'adaptabilité, le code Python auto-généré seul n'est pas suffisant. Selon l'auteur, d'autres approches sont nécessaires — par exemple, TinyML et l'apprentissage en simulation, où le comportement est développé par des millions d'itérations, pas écrit superficiellement sur la base d'une demande textuelle.

Ce que cela signifie

OpenGrall démontre un changement intéressant : un robot commence à être perçu non pas comme un dispositif rigidement programmé, mais comme une plateforme qui peut être davantage entraînée et étendue avec des commandes texte. La robotique entièrement autonome est encore loin, mais pour l'intégration de capteurs, de plugins et de sous-systèmes individuels, un tel « Ingénieur » peut déjà réduire considérablement la quantité de travail manuel — à condition que le dernier interrupteur reste entre les mains humaines.