Der BCI Racer am Cybathlon 2024

Wir freuen uns riesig über den erfolgreichen Abschluss des Cybathlon 2024 BCI Racer (BCI – Brain Computer Interface) Projekts! In diesem Blogpost berichten wir von den vielen Herausforderungen, die aufgetaucht sind und wie wir sie bewältigt haben. So wurde unser bisher grösstes Projekt zum vollen Erfolg!

Der BCI Racer ist ein speziell entwickelter digitaler Hindernisparcours für Menschen mit Paraplegie und Querschnittlähmung. Das Projekt entstand in Zusammenarbeit mit der ETH Zürich im Rahmen des Cybathlon 2024 – einem internationalen Wettkampf, der sich auf die Entwicklung von Assistenztechnologien für Menschen mit Behinderungen konzentriert.

Wir sprechen zuerst über die verschiedenen technischen Herausforderungen, die dieses Projekt mit sich gebracht hat. Auch das Testing verlief anders als gewohnt. Und an einem solch grossen Event wie dem Cybathlon waren wir ebenfalls noch nie vor Ort live am Hosten!

Technische Herausforderungen

Das Projekt hat einige grössere und spannende technische Herausforderungen geboten:

• Nutzer:innengruppen: Viele verschiedene Nutzer:innengruppen des Spiels mit unterschiedlichen Anforderungen: Forscher:innen, Pilot:innen, Administrator:innen, TV-Übertragungsteam, Lai:innen.
• Schnittstellen: Interaktionen mit unterschiedlichen externen Komponenten: BCI-Geräte, ETH-Resultatsystem, Log-Leser und Signaling-Server.
• Multiplayer: Rennen mit einem Host, vier Pilot:innen und vier Kameras gleichzeitig.
• Logging: Zeitechtes Logging über eine Netzwerk-Schnittstelle und das Dateisystem. Zusätzliche Übermittlung der Logs nach einem Rennen an den Host zwecks Nachvollziehbarkeit bei potenziellen Streitigkeiten.
• Internationalität: Das Spiel musste in Multiplayer-Rennen von Amerika über Zürich bis Singapur funktionieren.
• Zuverlässigkeit: Da der Event mit einer Liveübertragung auf dem Fernseher ausgestrahlt wird, musste alles an einem bestimmten Tag unbedingt funktionieren. Eine deutlich höhere Anforderung an die Zuverlässigkeit als wir typischerweise anstreben.
• Konfigurierbarkeit: Die Rennen selbst, aber auch das UI musste stark konfigurierbar sein und dennoch am Renntag faire Bedingungen garantieren. Dazu entwickelten wir Einstellungsmöglichkeiten über ein GUI im Spiel selbst, Tastenkombinationen, erweiterte Einstellungen über eine Datei und am wichtigsten: einen Konfigurator, um eigene Rennen bauen zu können.

Architektur

Um so viele Herausforderungen zu bewältigen, war in diesem Projekt viel technische Planung erforderlich. Die wichtigste Komponente hierin war die Systemarchitektur, mit besonderem Augenmerk auf die externen Komponenten und die Multiplayer-Rennen. Schlussendlich haben wir das Projekt mit folgender Architektur abgeschlossen, wobei in diesem vereinfachten Diagramm nur die gesamten Systeme gezeigt werden und nicht deren Innenleben.

• ETH-Resultatsystem: Diese REST-API lieferte dem Host-Spiel am Tag des Events die Details zu den durchzuführenden Rennen: Welche Teams nehmen auf welcher Position teil, welche Aufgaben gibt es, wie viel Zeit steht zur Verfügung etc. Ausserdem mussten die Spiele auf den Computern der Pilot:innen ihre Resultate an diese API melden. Diese Architektur führte dazu, dass die Integrität des Wettkampfes auch bestehen bleiben würde, wenn die Verbindung zum Host oder den Kameras unterbrochen wird.
• NTP-Time-Server: Alle Komponenten mussten für den Wettkampf ihre Zeit mit einem Zeitserver synchronisieren. So konnte sichergestellt werden, dass für alle Teilnehmenden der Wettkampf gleichzeitig und somit fair beginnt.
• Spiel als Host: Unser Spiel öffnete eine Lobby und ermöglichte den Kameras und den Pilot:innen diesem beizutreten. Der Host verband dann alle Teilnehmenden am Rennen und verteilte die Konfigurationen - so wurde sichergestellt, dass alle Teilnehmenden mit den gleichen Einstellungen spielten. Ausserdem erhielt der Host beim Abschluss des Rennens alle Log-Dateien von den Pilot:innen.
• Spiel als Pilot:in: Das Spiel lief auf den lokalen Computern der teilnehmenden Pilot:innen.
• Signaling Server: Dieser Server wurde verwendet, um die Video-Streams zwischen den Pilot:innen und den Kameras herzustellen. Alle meldeten sich zuerst beim Signaling-Server, dieser wiederum stellte dann direkte Verbindungen her.
• Turn-Server: Je nach Firewall-Einstellungen war es nicht möglich, direkte Video-Streams zwischen Pilot:in und Kamera herzustellen. In diesem Fall wurde das Video-Signal über einen Turn-Server umgeleitet.
• Spiel als Kamera: Für die Live-Übertragung im Fernsehen trat das Übertragungs-Team auch mit unserem Spiel dem jeweiligen Rennen bei. Als Kamera kann das Spiel dann jeweils ein:e Pilot:in beobachten. Die Kommunikation hierbei war zweiseitig, da es unterschiedliche Kameraansichten gab, zwischen denen gewechselt werden konnte.
• BCI-Gerät: Die Pilot:innen steuerten das Spiel mittels eines BCI-Gerätes. Diese kommunizierte mit dem Spiel über das Netzwerk, genauer gesagt einer UDP-Schnittstelle.
• Log-Leser: Zwecks Entwicklung der BCI-Geräte sendete das Spiel Log-Informationen über eine weitere UDP-Schnittstelle.

Komponenten

Nebst den vielen Code-Packages für die Unity Engine, welche wir von Projekt zu Projekt weiterentwickeln, möchten wir folgende Komponenten, die für den Erfolg des Projektes wichtig waren, hervorheben:

• Das Spiel erforderte schnelle und vor allem fehlerfreie Netzwerkkommunikation. Dies setzten wir mit unserem eigenen REST-Package, aber auch mit Unity Netcode for GameObjects und Unity Transport um.
• Die Video-Streams realisierten wir basierend auf Unity Render Streaming (verwendet WebRTC), welches wir für unsere Zwecke erheblich anpassen mussten.

Testing

Um die hohe Zuverlässigkeit zu erreichen, welche in diesem Projekt erforderlich war, haben wir intern viel Zeit in das Testen der Software und unterschiedlicher Szenarien gesteckt, inklusive dem Testen von Abstürzen und Netzwerk-Zusammenbrüchen. Ausserdem, und hierbei möchten wir dem Team bei der ETH erneut inbrünstig danken, haben wir sehr früh und vor allem sehr viele Integrationstests mit allen Nutzer:innengruppen durchgeführt. Immer wieder und mit immer mehr Genauigkeit haben wir alle Systeme genauso getestet, wie sie am Event verwendet werden würden. Dies war ein wichtiger Beitrag zum Projekterfolg am Event selbst.

Cybathlon 2024 Event

Der Tag begann früh: Wir trafen uns vor Ort und machten uns auf den Weg zur Main-Hall, um unsere Badges und Staff-Shirts abzuholen. Zwischen den Disziplinen wurde die Main-Hall immer wieder umgebaut – neue Setups, Technik, Hindernisse. Jede Challenge brachte ihre eigene Welt mit!

Anschliessend bezogen wir unseren Platz im „Command Center“ – ein Raum mit grossem Bildschirm, auf dem sämtliche Kamerawinkel live die Geschehnisse auf dem Event zeigten. Von hier aus steuerten wir die Übertragung unseres Spiels. Auch das ETH-Team war vor Ort. Wenn unser Spiel an der Reihe war, übernahmen wir das Hosting – von den Qualifikationsrunden an den vorhergehenden Tagen bis hin zum grossen Finale am letzten Tag.

Besonders spannend war es, die Lernkurve der Pilot:innen zu beobachten. Mit jedem Durchlauf wurden die Pilot:innen sicherer und das Bearbeiten der Tasks im Spiel wurde erfolgreicher und schneller. Schön zu sehen war auch, wie gut unser Spiel ausbalanciert war: Die Rennen wurden immer wieder nur durch wenige Sekunden entschieden. Noch schöner war, dass diese spannenden Momente durch keinerlei technische Probleme unsererseits unterbrochen wurden – unser Spiel und unser gesamtes Hosting liefen reibungslos!

Im Laufe der Competition wurde jedoch deutlich: Eine Person hatte einen klaren Vorteil. Der spätere Sieger war der einzige Pilot mit invasiv implantierten Elektroden im Kopf – im Gegensatz zu den anderen Teilnehmenden, die lediglich EEGs auf der Kopfhaut trugen. Die Unterschiede in der Performance waren klar sichtbar. Während Gold somit bald vergeben war, entwickelte sich der Kampf um Platz zwei zum echten Krimi. Es ging um Sekundenbruchteile – begleitet von angespannten Gesichtern, mitfieberndem Teamgeist und lauten Ausrufen im Command-Center.

Was für ein emotionales, schönes Finale für dieses Projekt!