OpenGrall dévoile le mode « Ingénieur » : le robot écrit ses propres pilotes et configure ses modules

OpenGrall a décrit un mode « Ingénieur » : une architecture dans laquelle le robot peut, à partir d'une commande textuelle, créer lui-même des plugins, écrire des pilotes et adapter son code à de nouveaux matériels. L'idée n'est pas d'atteindre l'autonomie totale à tout prix, mais de confier l'intégration routinière à un LLM tout en laissant le contrôle à l'humain.

Comment les rôles sont répartis

Dans le projet OpenGrall, l'intelligence du robot est répartie en deux boucles. Le « Pilote » est un modèle local qui tourne à bord, prend des décisions rapides et pilote 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 sert à ce que le robot ne dépende pas du cloud pour les tâches de base et ne casse pas sa propre logique en usage normal.

L'« Ingénieur » ne s'active que sur demande ou lorsque la tâche exige l'accès à des outils de développement. C'est un LLM dans le cloud, auquel on ouvre le code du projet, les configurations et la documentation. Il ne se contente pas de produire un fragment au hasard : il agit comme un agent à part, qui étudie la structure des plugins, cherche des exemples, modifie des fichiers, exécute du code dans un bac à sable et pose des questions de précision au propriétaire. Si la commande ressemble à « tourne à gauche », c'est le Pilote qui travaille ; si c'est « configure le manipulateur », le relais passe à l'Ingénieur.

Comment fonctionne l'Ingénieur

L'idée centrale du mode est de ne pas tout écrire à la main pour chaque nouveau module. Si l'on branche au robot, par exemple, un servomoteur de caméra sur un ESP32 via WebSocket, le propriétaire n'a qu'à décrire l'appareil et ses commandes disponibles dans un fichier d'autodescription. L'Ingénieur lit ensuite le projet, compare les plugins existants et crée un nouveau module pour ce matériel précis. OpenGrall a assemblé pour cela une boîte à outils dédiée :

• recherche de documentation et d'exemples fonctionnels sur le web
• lecture d'articles, de spécifications et de fichiers du projet
• analyse de l'arborescence et des plugins déjà prêts
• modification ciblée du code et création de nouveaux fichiers
• exécution et vérification du code écrit dans un bac à sable isolé

La suite n'a rien d'une « magie en un clic » : c'est un cycle de développement encadré. Le modèle construit d'abord le squelette de la classe et peut le montrer à un humain avant de générer le fichier complet. Les méthodes sont ensuite remplies étape par étape en mode streaming, afin de ne pas régénérer tout le module ni perdre le contexte. Pour la calibration, l'Ingénieur peut faire intervenir un humain dans la boucle : lui demander de placer un objet devant la caméra, de mesurer la distance jusqu'au boîtier ou de confirmer que le servomoteur a atteint l'angle voulu. C'est surtout important là où une description purement textuelle ne suffit pas.

L'auteur ne mise pas seulement sur le branchement de nouveaux modules, mais aussi sur une refonte plus profonde du système. L'article donne l'exemple d'un navigateur : une version manuelle de base d'environ 1,5 millier de lignes de code peut être remplacée par une implémentation bien plus volumineuse, avec des trajectoires fluides, un recalcul d'itinéraire à la volée et moins de à-coups. Autrement dit, il ne s'agit plus de générer un simple pilote, mais d'essayer de donner au robot un outil pour réécrire ses propres sous-systèmes en fonction d'une nouvelle tâche.

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

La sécurité repose sur trois mécanismes simples : un bac à sable pour exécuter le code, des sauvegardes automatiques avant chaque modification et une génération par étapes avec vérification du résultat. Le code s'exécute avec un délai d'expiration et sans appels système, une copie du fichier est créée avant toute modification, et l'intégration dans la boucle principale ne se fait pas automatiquement. Même si le modèle se trompe ou part sur une mauvaise architecture, l'humain peut arrêter le processus, annuler les changements et prendre la décision finale à la main.

Où s'arrêtent les limites de l'approche

Les auteurs d'OpenGrall le disent sans détour : il ne faut pas idéaliser le premier code généré. Les LLM gardent leurs problèmes chroniques : API obsolètes, dépendances superflues, wrappers erronés et incompatibilité avec l'environnement. La différence tient à ce que l'agent sait lire les logs, relancer les tests et corriger jusqu'à ce que le module fonctionne. Mais en pratique, ce débogage autonome peut prendre non pas des minutes, mais des heures de temps réel, surtout si le matériel est atypique ou la documentation approximative.

Il existe aussi des limites architecturales plus dures. Pour configurer un manipulateur, une caméra ou un lidar, ce mode paraît logique : le modèle voit la description, comprend la géométrie de la tâche et peut assembler une interface fonctionnelle par-dessus des commandes existantes. Mais pour piloter la marche d'un hexapode ou d'autres tâches aux exigences strictes de vitesse et d'adaptabilité, du code Python autogénéré ne suffit plus. Là, selon l'auteur, il faut d'autres approches, comme le TinyML et l'apprentissage en simulation, où le comportement se forge au fil de millions d'itérations au lieu d'être écrit en surface à partir d'une requête textuelle.

Ce que cela signifie

OpenGrall montre un déplacement intéressant : le robot commence à être perçu non comme un appareil au firmware figé, mais comme une plateforme qu'on peut réentraîner et enrichir par des commandes textuelles. On est encore loin d'une robotique entièrement autonome, mais pour intégrer des capteurs, des plugins et certains sous-systèmes, un tel « Ingénieur » peut dès à présent réduire sensiblement le travail manuel, à condition que le dernier interrupteur reste aux mains de l'humain.