Hybrid AI Robotik: Sichere Integration von LLM und TinyML

Hybrid-KI- und TinyML-Architektur: Sichere Integration in der Robotik

Traditionelle Ansätze zur Integration von LLMs in die Robotik stoßen auf kritische Herausforderungen: Modell-Nichtdeterminismus, Verarbeitungsverzögerungen und Sicherheitsrisiken. Dieser Artikel zerlegt die OpenGrall-Hybridarchitektur, bei der das LLM die strategische Planung übernimmt und TinyML die sichere Echtzeit-Ausführung von Aktionen gewährleistet.

Sicherheit als Architekturprinzip

LLMs sind von Natur aus nichtdeterministisch – ein und derselbe Prompt kann unterschiedliche Befehle erzeugen. Die direkte Weitergabe solcher Befehle an Motoren führt zu unvorhersehbarem Verhalten. Die Lösung von OpenGrall ist die Trennung der Verantwortlichkeiten: Das LLM setzt strategische Ziele, aber der Onboard-Controller auf TinyML-Basis trifft die endgültige Entscheidung zur Aktionsausführung.

Das TinyML-Modell, das auf einem Mikrocontroller (ESP32/STM32) läuft, verarbeitet Sensordaten mit einer Latenz unter 10 ms. Es:

• Hat absolutes Vetorecht gegenüber LLM-Befehlen
• Überwacht die physikalischen Grenzen der Plattform (Trägheit, Nutzlastkapazität)
• Gewährleistet Notabschaltungen bei Hinderniserkennung
• Verwaltet aktive Federung und komplexe mechanische Systeme

Das TinyML-Training erfolgt in einem Simulator mit präzisem physikalischem Modell der Plattform. Dadurch kann das neuronale Netz das „Hardware-Gefühl“ erlernen: Beschleunigung und Bremsen berechnen, unebene Oberflächen kompensieren, Bewegungs trajectorien optimieren. Eingabedaten sind ein minimaler Satz: Entfernungsmesser-Daten, Odometrie, IMU.

Modularität statt Monolithen

Beliebte VLA-Modelle (Vision-Language-Action) werden oft als Black Boxes eingesetzt, was Probleme verursacht:

• Unfähigkeit, neue Sensoren ohne Retraining hinzuzufügen
• Massive Rechenressourcenanforderungen
• Fehlende Transparenz bei Entscheidungsprozessen

OpenGrall setzt auf Trennung der Belange:

• LLM-Agent (Vikhr/Gemma/YandexGPT)

- Setzt strategische Ziele

- Analysiert komprimierte Sensordaten

- Erzeugt JSON-Befehle mit Parametern

- Erklärt die Begründung für Aktionen

• Ausführungsschicht (TinyML/VLA/hardcoded)

- Wandelt Befehle in physische Aktionen um

- Erzwingt Sicherheit

- Passt sich spezifischen Plattformen an

Dieser Ansatz liefert entscheidende Vorteile:

• Sicherheit wird deterministisch statt probabilistisch
• Das LLM kann ohne Umstellung des gesamten Systems getauscht werden
• Die Plattform passt sich mühelos neuen Robotertypen an (Hexapoden, Quadcopter)
• Parallele Entwicklung physischer und logischer Schichten

Lock-freie Architektur

Ein kritischer Fehler in den meisten Implementierungen ist die Synchronisation von LLMs mit schnellen Sensoren. OpenGrall nutzt eine asynchrone WebSocket-Architektur:

• Server (läuft auf jedem Gerät) – zentrale Nabe
• Clients melden sich mit Rollen an (operator/agent/esp/lidar)
• Standardisiertes JSON-Protokoll statt .msg-Dateien
• Dynamische Datenwichtung via WeightCalculator

Das SensorMemory-System verringert bei Anomalien automatisch das Gewicht eines Sensors. Beispiel: Wenn ein Lidar verschmutzt ist (alle Sektoren zeigen dieselbe Entfernung), werden seine Daten ignoriert, bis es gereinigt ist. Damit entfällt manuelle Datenfusion – das LLM entscheidet selbst, welchen Quellen es vertraut, indem es Datengewicht und -alter analysiert.

Token- und Prompt-Optimierung

Der größte Performance-Killer ist ineffiziente Datenübertragung zum LLM. OpenGrall setzt auf zwei Schlüsselmethode:

1. Sensor Data Compression

Rohe Lidar-Punktwolken (Tausende Werte/Sek.) werden in 8 Sektoren mit Schlüsseldaten umgewandelt. Beispielverarbeitung:

• Objekte näher als 80 cm: Winkel, Entfernung, Größe, Geschwindigkeit
• Dynamische Updates: Datenalter, Sensorgewicht

2. System Prompt

Kritische Anweisungen (Antwortformat, verfügbare Befehle) werden via Ollama ins Modell eingebettet. Das spart bis zu 300 Tokens pro Anfrage:

You robot Graal. Dimensions: 51×32×37sm.
0°=↑=directly
Reply JSON: {"action":"move_forward","params":{"speed":300},"reasoning":"..."}
...

Der eigentliche LLM-Request enthält nur aktuelle Daten:

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...

Wichtige Erkenntnisse

• Absolutes TinyML-Veto macht aus probabilistischer Sicherheit eine deterministische Garantie
• Modulare Architektur erlaubt unabhängige Anpassungen an LLM, Sensoren und Plattform
• Dynamische Datenwichtung ersetzt komplexe Sensordatenfusionsalgorithmen
• System-Prompts sparen 65 % Tokens und ermöglichen lokale Modelle <1B
• WebSocket-Protokoll sorgt für Kompatibilität mit allen Geräten, inklusive Mikrocontrollern

Auch experimentelle Sensoren (z. B. Ultraschall-Sonar auf drei Mikrofonen) integrieren sich ohne Codeänderung am Agenten. Das LLM interpretiert Rohdaten eigenständig und kreuzvalidiert sie mit anderen Sensoren. So entsteht ein sich entwickelndes System, in dem jedes neue Modul die Gesamtintelligenz des Roboters steigert.

— Editorial Team