Die Funkverbindung bricht ab. Der Roboter muss trotzdem denken.
Ein FTS in der Fabrik hinter einem Stahlregal. Eine Inspektionsdrohne in einer Turbinenhalle. Ein Pipeline-Crawler im Stahlrohr. Ein Schiff unter Deck. Die gemeinsame Eigenschaft: die Funkverbindung ist unterbrochen oder fehlt — und der Roboter muss weiter wahrnehmen, entscheiden und handeln.
Wahrnehmung am Gerät
Kamera-Frames, LiDAR-Scans, IMU-Datenströme laufen durch das native Inferenced. Objekterkennung, Anomalie-Erkennung, Klassifikation auf der Recheneinheit des Roboters — kein Umweg über eine Basisstation.
Sprachbefehle
STT rein, Befehl interpretiert, Aktion ausgeführt, TTS raus — alles an Bord. Nützlich für Inspektions-Teams, die mit Drohnen sprechen, für Werks-Operatoren, die FTS dirigieren, für Außendienst-Techniker, die Service-Roboter bedienen.
xLSTM-Prognose
Der xLSTM-Prognose-Daemon (Port 8884) übernimmt Trajektorien-Prognose, Bewegungsplanung und Recovery-Strategie auf Zeitreihen-Sensordaten. Linear in der Sequenzlänge — passt besser zu stundenlangen Telemetrie-Fenstern als ein Transformer.
Store-and-forward
Der IoT-Worker puffert die Telemetrie lokal, solange die Verbindung weg ist, und spielt sie an die Flottenzentrale zurück, sobald die Verbindung wieder steht. Keine verlorenen Frames, keine verlorenen Ereignisse.
Edge-Deployment
Läuft auf einem Pi 4, einem Industrial-Gateway, einem Jetson oder jeder Linux-Recheneinheit am Roboter. Dasselbe Binary wie das Rechenzentrums-Eldric; nur die aktivierten Module unterscheiden sich.
Recovery-Entscheidungen
Bricht die Verbindung ab, kann eine vorab geladene Policy den Roboter in einen sicheren Zustand führen. Steht sie wieder, gleicht die Flottenzentrale ab. Weiche Echtzeit an der Linie; harte Echtzeit bleibt Aufgabe des Motorcontrollers.