# Architecture hybride IA et TinyML : Intégration sécurisée en robotique
Les approches traditionnelles pour intégrer les LLM en robotique font face à des défis critiques : non-déterminisme des modèles, délais de traitement et risques de sécurité. Cet article décortique l'architecture hybride OpenGrall, où le LLM gère la planification stratégique, et TinyML assure une exécution d'actions en temps réel sécurisée.
La sécurité comme principe architectural
Les LLM sont intrinsèquement non déterministes — une même invite peut générer des commandes différentes. Transmettre directement de telles commandes aux moteurs conduit à un comportement imprévisible. La solution d'OpenGrall est la séparation des responsabilités : le LLM définit les objectifs stratégiques, mais le contrôleur embarqué basé sur TinyML prend la décision finale sur l'exécution des actions.
Le modèle TinyML, exécuté sur un microcontrôleur (ESP32/STM32), traite les données des capteurs avec une latence inférieure à 10 ms. Il :
- Dispose d'un pouvoir de veto absolu sur les commandes du LLM
- Surveille les limites physiques de la plateforme (inertie, capacité de charge)
- Assure des arrêts d'urgence en cas de détection d'obstacles
- Gère la suspension active et les systèmes mécaniques complexes
L'entraînement de TinyML se fait dans un simulateur avec un modèle physique précis de la plateforme. Cela permet au réseau de neurones de « sentir le matériel » : calculer l'accélération/freinage, compenser les surfaces irrégulières, optimiser les trajectoires de mouvement. Les données d'entrée sont un ensemble minimal : données du télémètre, odométrie, IMU.
Modularité plutôt que monolithes
Les modèles VLA populaires (Vision-Language-Action) sont souvent utilisés comme des boîtes noires, ce qui crée des problèmes :
- Impossible d'ajouter de nouveaux capteurs sans réentraînement
- Besoins massifs en ressources de calcul
- Manque de transparence dans la prise de décision
OpenGrall applique la séparation des préoccupations :
- Agent LLM (Vikhr/Gemma/YandexGPT)
- Définit les objectifs stratégiques
- Analyse les données de capteurs compressées
- Génère des commandes JSON avec paramètres
- Explique le raisonnement des actions
- Couche d'exécution (TinyML/VLA/codé en dur)
- Convertit les commandes en actions physiques
- Impose la sécurité
- S'adapte à des plateformes spécifiques
Cette approche apporte des avantages clés :
- La sécurité devient déterministe, non probabiliste
- Le LLM peut être échangé sans réécrire tout le système
- La plateforme s'adapte facilement à de nouveaux types de robots (hexapodes, quadricoptères)
- Développement parallèle des couches physique et logique
Architecture sans verrou
Un défaut critique dans la plupart des implémentations est la synchronisation des LLM avec des capteurs rapides. OpenGrall utilise une architecture WebSocket asynchrone :
- Serveur (exécuté sur n'importe quel appareil) — hub central
- Clients s'enregistrent avec des rôles (opérateur/agent/esp/lidar)
- Protocole JSON standardisé au lieu de fichiers .msg
- Pondération dynamique des données via WeightCalculator
Le système SensorMemory réduit automatiquement le poids d'un capteur en cas d'anomalies. Par exemple, si un lidar est sale (tous les secteurs indiquent la même distance), ses données sont ignorées jusqu'au nettoyage. Cela élimine le besoin de fusion de données manuelle — le LLM décide lui-même quels sources faire confiance en analysant le poids et l'âge des données.
Optimisation des tokens et des invites
Le principal tueur de performances est la transmission inefficace de données vers le LLM. OpenGrall utilise deux méthodes clés :
1. Compression des données de capteurs
Les nuages de points lidar bruts (milliers de valeurs/seconde) sont convertis en 8 secteurs avec paramètres clés. Exemple de traitement :
- Objets à moins de 80 cm : angle, distance, taille, vitesse
- Mises à jour dynamiques : âge des données, poids du capteur
2. Invite système
Les instructions critiques (format de réponse, commandes disponibles) sont intégrées au modèle via Ollama. Cela économise jusqu'à 300 tokens par requête :
You robot Graal. Dimensions: 51×32×37sm.
0°=↑=directly
Reply JSON: {"action":"move_forward","params":{"speed":300},"reasoning":"..."}
...La requête LLM réelle ne contient que les données actuelles :
CURRENT SITUATION:
Time: 1712345720.45
Current intent: inspect the corridor
DIALOG:
Human: Graal, posmotri that tam aheadi
Robot: Understood, investigating
SENSOR DATA (by importantsti):
• lidar: front=0.4m, front_left=1.2m...Points clés
- Veto absolu TinyML transforme la sécurité d'un paramètre probabiliste en garantie déterministe
- Architecture modulaire permet des changements indépendants du LLM, des capteurs et de la plateforme
- Pondération dynamique des données remplace les algorithmes complexes de fusion de capteurs
- Invites système réduisent les tokens de 65 %, permettant l'usage de modèles locaux <1B
- Protocole WebSocket assure la compatibilité avec n'importe quels appareils, y compris microcontrôleurs
Même les capteurs expérimentaux (p. ex., sonar ultrasonore sur trois microphones) s'intègrent sans modifier le code de l'agent. Le LLM interprète indépendamment les données brutes, en les recoupant avec d'autres capteurs. Cela crée un système évolutif où chaque nouveau module booste l'intelligence globale du robot.
— Editorial Team
Aucun commentaire pour le moment.