Hintergrund

In meiner Masterthesis möchte ich (voraussichtlich) untersuchen, wie Extended Reality (XR) dazu beitragen kann, die Ausdrucksstärke und Interaktionsfähigkeit sozialer Roboter zu erweitern. Aktuelle Modelle wirken oft technisch begrenzt und sind stark von aufwendiger, teurer Hardware abhängig. Statt physischer Upgrades könnten virtuelle Erweiterungen genutzt werden, die flexibler, kosteneffizienter und besser anpassbar sind.

Dieses Projekt versteht sich als erste Machbarkeitsstudie zur technischen Umsetzung eines solchen hybriden Interaktionssystems.

Interviews

Im Rahmen des Masterthesis-Kurses habe ich acht Personen im Alter von 20 bis 35 Jahren interviewt, um erste Einblicke in Erwartungen, Chancen und Grenzen XR-gestützter sozialer Roboter zu gewinnen.

Die Mehrheit der Befragten sieht in XR eine interessante Möglichkeit, physische Roboter zu erweitern. Gleichzeitig äußerten viele auch Skepsis gegenüber dem grundsätzlichen Nutzen sozialer Roboter sowie Bedenken in Bezug auf Kontrolle und Privatsphäre.

Szenario

Als erstes Anwendungsszenario für einen Prototypen habe ich die Entwicklung eines „Anti-Prokrastinations-Roboters“ gewählt. Ziel war es, mithilfe von Sensorik – etwa durch Geräuscherkennung, Körperhaltung oder Anwesenheit – zu erkennen, wann Nutzer:innen sich von ihrer eigentlichen Aufgabe ablenken lassen.

Über ein XR-Headset sollten in solchen Momenten gezielt Reminder oder ein Fokus-Tunnel eingeblendet werden. Gamification-Elemente, wie ein Belohnungssystem in Form einer wachsenden virtuellen Pflanze, sollten zusätzlich dazu motivieren, fokussiert zu bleiben.

Meine Annahme war, dass der Mehrwert eines sozialen Roboters vor allem in seiner physischen Präsenz liegt: Während virtuelle Assistenten leicht in den Hintergrund treten, bleibt ein physischer Roboter im Raum präsent, kann nonverbal reagieren und dadurch verbindlicher wirken.

Umsetzung

Hardware

Für die Umsetzung habe ich den sozialen Roboter Furhat und die Meta Quest 3 kombiniert. Furhat erschien mir – basierend auf der Dokumentation – als die flexibelste Plattform unter den verfügbaren Robotern an der Hochschule. Statt eines Mixed-Reality-Headsets wäre eine reine Augmented-Reality-Brille zwar konzeptionell passender gewesen, bislang konnte mich jedoch kein verfügbares AR-Gerät in Bezug auf die Darstellungsqualität überzeugen (ein Vergleich in Kapitel 3.2.2 meiner Bachelorarbeit). 

Die Quest 3 ist daher in diesem Projekt als Platzhalter für zukünftige AR-Headsets zu verstehen.

Unity

Für die Entwicklung der Hauptanwendung habe ich Unity verwendet, da ich bereits Erfahrung mit der Engine habe und die Dokumentation zur Meta Quest umfangreich und gut gepflegt ist.

Der Prototyp läuft als Standalone-Anwendung direkt auf dem Headset und enthält die vollständige Anwendungslogik. Da mir ein funktionaler Prototyp wichtiger war als visuelle Perfektion, habe ich bewusst weniger Zeit in die gestalterische Ausarbeitung investiert und mich auf die Kernfunktionalität konzentriert.

Die Spalten der Aufgabenübersicht sind technisch so aufgebaut, dass sie mit externen Tools wie Notion, ClickUp oder Trello verbunden werden könnten. Grundlage dafür ist eine selbst definierte JSON-Struktur für die Aufgaben.

Ursprünglich hatte ich geplant, die neue Passthrough Camera API der Meta Quest in Kombination mit Unity Sentis für eine Objekterkennung zu nutzen – etwa um zu erkennen, ob Nutzer:innen konzentriert am Rechner arbeiten oder sich durch ihr Smartphone ablenken lassen. Nach zahlreichen Tests und Performanceproblemen habe ich mich jedoch gegen diese Umsetzung entschieden. Dennoch möchte ich an dieser Stelle auf das Beispielprojekt von Roberto Coviello verweisen, den ich auf dem XR-Hackathon in Köln kennengelernt habe.

Furhat

1. Iteration – Eigener Skill mit WebSocket

Skills sind die Anwendungen, die auf Furhat ausgeführt werden. Sie bilden typischerweise eine soziale Situation ab, können aber grundsätzlich auch andere Anwendungsfälle realisieren. Die Skills werden in Kotlin geschrieben. Da ich bisher nicht mit Kotlin gearbeitet hatte, musste ich mich zunächst intensiv mit dem Aufbau der Beispiel-Skills auseinandersetzen. Mein Plan war es, einen eigenen Skill zu entwickeln, der einen WebSocket-Server bereitstellt. Dieser sollte von meiner Quest-Anwendung aus angesprochen werden und eingehende Nachrichten verarbeiten, um Furhat entsprechend zu steuern. Grundsätzlich funktionierte dieser Ansatz (siehe oberes Video), war jedoch sehr wartungsintensiv, da sowohl der Furhat Skill als auch die Unity-Anwendung parallel entwickelt und synchronisiert werden mussten.

2. Iteration – Furhat AI Creator

Durch einen Hinweis von Yin kam ich auf die Idee, den Furhat AI Creator zu testen – eine No-Code-Plattform, mit der sich Konversationsroboter per Prompt konfigurieren lassen. Das gesamte Verhalten (inklusive Gestik) wird automatisch generiert. Über ein JSON-Schema sollen laut Dokumentation externe APIs angebunden werden können, um eine Zwei-Wege-Kommunikation mit anderen Systemen zu ermöglichen. Ich versuchte daher, eine einfache Schnittstelle mit FastAPI in Python zu implementieren, über die Furhat und meine Quest-Anwendung Nachrichten austauschen sollten. In der Praxis war es mir jedoch nicht möglich, zuverlässig Daten vom Server abzurufen. Die Konfigurationsmöglichkeiten des AI Creators sind stark eingeschränkt, was das Debugging und die Fehlersuche erschwerte. Zusätzlich besteht die Einschränkung, dass der Virtual Furhat – eine lokale Simulation des Roboters – trotz einer Lizenzgebühr von 5.000 € pro Jahr nur für 10 Sekunden mit dem AI Creator genutzt werden kann. Eine ausführliches Testen außerhalb der Hochschule war so kaum möglich. Auch die vollständige Abhängigkeit von den Servern von Furhat Robotics empfand ich als kritisch.

3. Iteration – TCP-Verbindung mit C#-Library

Furhat bietet auch eine Remote API, mit der sich der Roboter von externen Programmen aus steuern lässt. Eigentlich wollte ich diese Methode als Nächstes testen, stieß dann aber zufällig auf eine inoffizielle C#-Bibliothek, die eine direkte TCP-Kommunikation mit Furhat ermöglicht. Damit konnte ich Befehle direkt aus meiner Unity-Anwendung an Furhat senden – ohne einen zusätzlichen Skill oder Bridge-Server implementieren zu müssen. Die Umsetzung war deutlich einfacher als bei den vorherigen Ansätzen und vereinfachte vor allem die Wartung. Natürlich brachte auch dieser Ansatz eigene Herausforderungen mit sich, war für meine Zwecke aber insgesamt der praktikabelste.

LLM Integration

Um die Konversationen natürlicher zu gestalten, habe ich ein Large Language Model (LLM) angebunden. Anstatt die Schnittstellen der großen KI-Plattformen wie OpenAI, Anthropic oder Google Gemini zu verwenden – was mit zusätzlichen Kosten verbunden gewesen wäre – wollte ich aus Interesse ein lokales System integrieren.

Die eigentliche Einbindung in Unity war dank eines bestehenden Packages relativ unkompliziert. Viel Zeit floss jedoch in die Optimierung der Latenz, um eine möglichst flüssige Interaktion zu ermöglichen. Da die Rechenleistung der Quest 3 nicht mit High-End-Geräten vergleichbar ist, kamen nur sehr kleine Modelle infrage – sogenannte Tiny Models mit weniger als 2B (Billion = Milliarde) Parametern. 

Trotz Tests mit verschiedenen Modellen (z. B. LLaMa, Gemma, Qwen) war die Latenz zu hoch für eine natürlich wirkende Interaktion. In der finalen Version verbindet sich die Quest daher mit einem lokalen Server auf meinem Laptop, auf dem das Modell Llama 3.2 3B läuft. Dank der Nvidia Grafikkarte (RTX 4070) liegt die Reaktionszeit bei nur noch etwa 1-2 Sekunden.

Finaler Prototyp

Github Repository

Ich räume das Repo derzeit noch auf. Wer einen Zugang zum Testen benötigt oder das Projekt als Vorlage für eine eigene Anwendung nutzen möchte, kann sich gerne bei mir melden.

Fazit

Der entstandene Prototyp zeigt, dass sich soziale Robotik und Extended Reality grundsätzlich miteinander kombinieren lassen. Eine wirklich überzeugende Symbiose zwischen beiden Systemen zu schaffen, erweist sich jedoch als technisch komplex und gestalterisch herausfordernd.

Während der Entwicklung stellte sich für mich zunehmend die Frage nach der tatsächlichen Sinnhaftigkeit dieser Verbindung: Warum sollte man überhaupt einen physischen sozialen Roboter nutzen – und ihn nicht vollständig durch einen virtuellen Agenten ersetzen?

Aus meiner Sicht wäre es spannender, XR gezielt dort einzusetzen, wo Roboter zwar über hohe mechanische Autonomie, aber nur eingeschränkte soziale Ausdrucksfähigkeit verfügen – etwa bei mobilen Robotern mit Manipulatoren (z.B. Greifer), Drohnen oder humanoiden Systemen wie Unitree G1 oder Boston Dynamics Atlas.

Durch XR ließen sich nicht nur neue Interaktionsformen schaffen, sondern auch der Uncanny-Valley-Effekt gezielt umgehen.

Ein kurzes Wort zu Vibe-Coding: Trotz KI-gestützter Tools wie Cursor oder GitHub Copilot, hat mich die Entwicklung viele Nächte und Nerven gekostet. Das derzeit größte Problem ist aus meiner Sicht die fehlende Code-Konsistenz und die sehr unkritischen „People Pleaser“-Antworten die man meist bekommt. Ohne jegliche Vorkenntnisse ist es aus meiner Sicht derzeit noch schwierig, komplexere Systeme umzusetzen. Gleichzeitig sind KI-Coding-Tools bereits jetzt eine enorme Unterstützung. Es ist absehbar, dass sich die Arbeit von Informatiker:innen und Designer:innen grundlegend verändern wird, auch wenn viele das nicht wahrhaben wollen.