Der Sprung in ein spannendes Hardware-Projekt

Der Auftrag war klar: eine Software zur Steuerung eines Bewegungskräfte-simulierenden Rennsitzes zu entwerfen. Welche Anforderungen und Ausprägungen diese Software definieren dagegen nicht.

Der „Sitz“, im Moment nur „MotionBase“ genannt, ist eine, teilweise noch in Entwicklung befindliche, Konstruktion aus zwei Elektromotoren, die eine Platte, auf der sich ein Sitz befindet, in definierte Positionen bewegen. Die den Bewegungen zugrunde liegenden Informationen sollen aus PC-Spielen extrahierte, telemetrische Daten sein.

motionbase

(Prototyp der Vorgänger-Version)

Ergründen der Anforderung

Viele Ungewissheiten und ein außerordentlicher Motivationsschub schmückten die Anfangsphase des Projekts. Die Leidenschaft des Kunden für die MotionBase und meine Begeisterung für PC-Spiele ergänzten sich wunderbar in der Analyse für das an private Endverbraucher gerichtete Produkt. Die Vision war daher schnell erstellt, die Unbestimmtheit des genauen Ziels und damit der zu verwendeten Technologien blieb aber weiterhin.

Zu Beginn waren einige Recherchen zu folgenden Themen notwendig:

  1. Wie können die telemetrischen Daten aus Spielen abgezogen werde?
  2. Welche Technologien (Java, .NET) sind am besten geeignet, wenn sie an einen privaten Endverbraucher gerichtet sind?
  3. Welche Daten wird man von der unterschiedlichen Software (PC-Spiele) empfangen und wie können/müssen diese verarbeitet werden?
  4. Wie soll die Motionbase angesteuert werden?

Auf einen Großteil der Fragen ließen sich auch in der HEC keine Ansprechpartner finden, somit wurden diese Fragen im Rahmen eines „Proof of Concept“ gesondert betrachtet.

 

Ungewisse Datenstrukturen und unbestimmte Anwendungsgebiete

In Rücksprache mit Kollegen wurden Vermutungen zu möglichen Daten-Extraktionspunkten aufgestellt, wobei u.a. folgende Technologien auftauchten:

  • OpenGL
  • DirectX
  • Verschiedene Game-Engines (Unreal, Snowdrop, CryEngine, …)
  • Mehrspieler-Schnittpunkte

OpenGL und DirectX (Software für visuelle Darstellungen) verfielen schon aufgrund der langwierigen Berechnungszeit. Bei der Untersuchung großer Rennsimulation -Titel und dem Abgleich der verwendeten GameEngines mit den großen Engines der Branche fiel auf, dass sich die größeren Studios für ihre Rennserien eigene Engines entwerfen, die nicht frei verfügbar sind und sich damit von der Verwendung ausschlossen.

Bei der Betrachtung anderer, vergleichbarer Simulations-Software (XSimulator) wurde auf Daten-Export-Schnittstellen hingewiesen, die üblicherweise nur für die Mehrspieler-Komponente von Spielen als Direkt-Kommunikation genutzt wird. Des Problems Lösung waren also die von den Spieleentwicklern vorgesehenen Kommunikationsschnittstellen, vornehmlich die oft genutzten UDP-Schnittstellen, die nahezu unkontrolliert Spieledaten über den Äther schicken.

Um nun also Spieledaten empfangen zu können, musste ermittelt werden an welche IP und über welchen Port die tatsächlichen Daten verschickt werden würden und in welcher Form sie dort ankamen. Die ankommenden UDP-Pakete bestehen aus, für jedes Spiel an unterschiedliche Ports gesendeten, unterschiedlich aufgebauten, Byte-Arrays, die nun nach den benötigten Werten entschlüsselt werden mussten. Zu diesem Zweck ist es nötig die Positionen der Werte (Floats) im Byte-Array zu ermitteln, was nur durch externe Informationen oder sehr aufwendige Trial-and-Error-Maßnahmen passieren kann.

 

Prototyp

Unter Berücksichtung des auf den Windows-PC ausgerichteten Produktes wurde eine Windows-Forms-Anwendung zur Analyse und Testdurchführung mit VisualStudio erstellt. Der Aufbau eines Programms zum Empfang der UDP-Pakete des Spiels DIRT 3 (Codemasters) stellte sich als vergleichsweise einfach heraus, die Dokumentation bzw. Bereitstellung des Aufbaus des UDP-Paket-ByteArrays seitens des Herstellers (Codemasters) aber nicht. Nach Recherchen konnte diese Struktur durch die Analyse anderer Software ermittelt und angewandt werden. An diesem Punkt war es nun schon möglich die benötigten Daten (G-Kräfte für X- und Y-Achse) zu ermitteln und anzuzeigen.

Nach weiterer Abstimmung mit dem Kunden stellte sich heraus, dass es durchaus das Bestreben gäbe das Produkt in Zukunft neben dem Windows-PC auch für andere Endgeräte (Playstation, Xbox, Linux, Mac) bereitzustellen. Durch diesen Umstand und die eigentliche Kernkompetenz des Entwicklungsteams wurde sich daher für die Umsetzung mit Java entschieden. Aktuell findet die Umsetzung in einer JavaFX Umgebung statt.

 

Aktuelle Entwicklung

Die aktuelle Entwicklung verwendet folgende Elemente:

  • Eclipse Keplar mit JavaFX 8 Plugin
  • Git und Gitblit
  • Chef zur Einrichtung der Umgebung
  • Als Datenbank dienen XML-Dateien, da es nur sehr geringere Mengen an hinterlegten Daten geben wird. Diese XML-Struktur wird mit JAXB erzeugt.
  • MVC-Pattern
    • Models: Game, Profile, TelemetryData
    • View-Controller: Jede View besteht aus einer FXML-Datei, der ein Controller zugeordnet ist und die Steuerungselemente der View verwaltet und Funktionen abrufbar implementiert.
      • fxml – GforceViewController
  • SceneBuilder zur Erstellung der FXML- View-Dateien
  • RXTX für die Kommunikation mit seriellen Schnittstellen
  • Ardulink zur Kommunikation mit einem über USB verbundenen Arduino-Controller (für Testzwecke, der zu verwendende Controller befindet sich in Entwicklung)

Momentan werden von der Software folgende Spiele unterstützt:

  • Dirt 3 (Codemasters)
  • F1 2015 (Codemasters)
  • Project Cars (Slightly Mad Studios)
  • Assetto Corsa (Kunos Simulazioni)

 

Herausforderung der Entwicklung

Die Entwicklung an unbekannten Schnittstellen, mit einer Vielzahl an unbekannter Spiele-Software, zur Steuerung einer unbekannten Hardware, stellt viele Herausforderungen bereit, die auch in Zukunft auf dieses Projekt zukommen.

Folgende Fragen für die Zukunft stellen sich schon jetzt:

  1. Wie kann mit so unterschiedlichen Daten ein erfreuliches Simulations-Ergebnis erzeugt werden?
  2. Was muss getan werden um G-Kräfte aus anderen Daten ermitteln zu können, sofern die G-Kräfte nicht explizit angeboten werden? Eine denkbare Berechnung aus Position- und Orienti
  3. Was passiert bei unsauberen Daten, bzw. unvorhergesehenen Daten-Spitzen?
  4. Hält die JavaFX-Struktur der Datenmenge stand und bleibt die Steuerung der Hardware konstant/schnell?
  5. Wie schnell reagiert der Sitz auf Übertragung und wie schnell werden die Befehle umgesetzt?
Verfasst von Michael Braune am 6. März 2017