OpenGrall a Présenté une Architecture pour Robots IA où le Modèle de Langage Gère la Stratégie

OpenGrall propose un changement simple mais important en robotique : un modèle de langage ne doit pas contrôler un robot au niveau des moteurs et des réactions instantanées. Ici, le modèle de langage n'est responsable que du sens, de la planification et du choix de la prochaine étape, tandis que la sécurité, le mouvement et les réflexes de bas niveau sont séparés dans une boucle de rétroaction distincte. Par cette approche, le projet vise à éliminer le principal problème de la plupart des démonstrations de « robots GPT », où la machine parle magnifiquement mais gèle ensuite pendant plusieurs secondes avant chaque action.

Les auteurs commencent par le problème le plus douloureux — la sécurité. Un LLM est non déterministe : la même demande peut produire des réponses différentes, ce qui signifie que lui confier le contrôle direct des moteurs est dangereux. OpenGrall introduit un schéma hybride pour cela, où le rôle de « moelle épinière » est joué par un modèle TinyML ou une autre boucle d'exécution rigide sur un microcontrôleur.

C'est précisément cela qui comprend la physique de la plateforme spécifique, gère la suspension, la navigation d'obstacles et a un droit de veto sur toute commande. Si un opérateur ou un LLM dit d'avancer, mais qu'un télémètre détecte un objet plus proche que 10 centimètres, la commande ne sera tout simplement pas exécutée. Le temps de réaction d'arrêt d'urgence déclaré est inférieur à 10 millisecondes.

La logique ici est pragmatique : le LLM pense, tandis que le module d'exécution agit et peut arrêter l'action dangereuse à tout moment. La deuxième grande force d'OpenGrall est la modularité. Le projet sépare « penser » et « faire » pour que les deux parties puissent être modifiées indépendamment.

Le rôle du cerveau peut être joué par un LLM local, un VLM ou un modèle en nuage si une tâche plus complexe comme la planification multi-étapes ou la recherche web est nécessaire. Le rôle de l'exécuteur — modèle TinyML, VLA ou même un simple algorithme codé en dur si la plateforme est simple. Le système entier est connecté via un serveur WebSocket, et les appareils se connectent comme des clients ordinaires avec des rôles comme agent, opérateur, lidar ou esp.

Cela permet d'ajouter de nouveaux capteurs sans réécrire le noyau et même de construire un schéma où un agent fonctionne avec plusieurs corps simultanément : par exemple, une plateforme à roues et un drone. Pour un projet open source sur du matériel faible, cet accent est particulièrement important : l'architecture n'est pas liée à un type de robot ou à un modèle spécifique. Le bloc d'ingénierie clé est la liaison de SensorMemory et WeightCalculator.

Au lieu d'envoyer indiscriminément tous les flux bruts au LLM, le système collecte les données de manière asynchrone, évalue leur fraîcheur et fiabilité, puis les transforme en un prompt court. Si un lidar se salit ou un VLM devient aveugle au soleil, leur poids diminue avant le moment de la prise de décision. Si un capteur est lent, cela ne bloque pas les autres.

L'article fournit un exemple illustratif : un nuage de points lidar est condensé en huit secteurs, et les objets proches sont décrits par angle, distance, taille et vitesse. Pour le LLM, ce n'est plus du bruit mais une situation structurée. Une nuance importante est qu'OpenGrall n'essaie pas d'écrire manuellement des règles complexes de fusion de données.

Le LLM lui-même agit comme arbitre, voyant la source, l'âge et le poids de chaque signal et choisissant une action au format JSON sur cette base. En même temps, le prompt système est intégré dans le modèle à l'avance, par exemple via Ollama, donc dans le cycle de travail seule la partie opérationnelle « nue » entre dans la demande. Selon l'estimation de l'auteur, cela réduit le prompt d'environ 450 à 150 tokens.

Un accent séparé de l'article est de combattre la « lenteur ». Dans de nombreux frameworks classiques, le robot attend le capteur le plus lent, et de ce fait, la télémétrie rapide reste effectivement inactive. OpenGrall rejette une telle synchronisation : le lidar, le VLM et l'odométrie écrivent les données en mémoire indépendamment, et l'agent prend les valeurs les plus fraîches et les plus fiables du moment.

Mais même après cela, le LLM pense toujours pendant des centaines de millisecondes, donc du côté ESP32, un mouvement inertiel a été ajouté : s'il n'y a pas encore de nouvelle commande, le robot ne gèle pas figé mais continue doucement sa dernière action sûre avec amortissement de vitesse. Une autre couche d'optimisation est la mise en cache des décisions par hash de contexte. Si le robot fait à nouveau face au même couloir vide, le système n'appelle pas à nouveau le modèle mais prend la solution déjà vérifiée du cache.

Ensuite, cette idée se développe vers des habitudes familières et des réflexes de haut niveau : les stratégies réussies peuvent déjà être exécutées sans le LLM, et le retour d'information humain renforce leur poids. En plus de cela, le projet stocke la mémoire épisodique des instructions humaines et permet même une fixation d'objectifs autonome, quand le robot choisit indépendamment ce qu'explorer, ce retenir ou avec qui engager un dialogue en temps d'inactivité. Plus largement, OpenGrall est intéressant non pas comme une autre tentative de « boulonner GPT sur un robot », mais comme une tentative de faire évoluer la robotique LLM vers une architecture plus mature.

Il n'y a pas de promesse d'un cerveau universel magique, mais il y a une division claire des responsabilités, un travail avec du matériel limité, une protection contre les actions dangereuses et un chemin vers un apprentissage progressif sans réentraînement complet de tout le système. Pour les développeurs, cela signifie un moyen plus réaliste de construire des robots basés sur des modèles modernes : utiliser le LLM où il est fort et ne pas le forcer à faire ce qui convient mieux à une boucle d'exécution petite, rapide et prévisible.