Aufbau eines Fahrsimulators

Planung und Aufbau eines
realistischen Fahrsimulators für
die Untersuchung von kognitiven
Dialogsystemen
Schwerpunkt Software
Studienarbeit am Cognitive Systems Lab
Prof. Dr.-Ing. Tanja Schultz
Fakultät für Informatik
Universität Karlsruhe (TH)
von
cand. inform.
Rikard Öxler
Betreuer:
Prof. Dr.-Ing. Tanja Schultz
Dipl.-Inform. Felix Putze
Tag der Anmeldung: 28. Dezember 2008
Tag der Abgabe:
28. April 2009
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Karlsruhe, den 28. April 2009
Zusammenfassung
Die vorliegende Studienarbeit beschäftigt sich mit dem Aufbau eines Fahrsimulators
zu Forschungszwecken. Der Schwerpunkt liegt dabei bei der dafür notwendigen Software. Das Dokument beschreibt, welche Anforderungen an solch ein System gestellt
werden, welche bisherigen Lösungsansätze es gibt und wie unsere Lösung dafür aussieht. Mit Hilfe dieser Arbeit soll es später möglich sein, das System zu warten oder
Erweiterungen vorzunehmen.
Inhaltsverzeichnis
1 Einleitung
1.1 Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
2 Grundlagen
2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Projektion . . . . . . . . . . . . . . . . . . . . .
2.1.2 Sound . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Eingabegeräte . . . . . . . . . . . . . . . . . . .
2.1.4 Kraftrückmeldung . . . . . . . . . . . . . . . .
2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Was muss ein Simulationssystem für uns leisten
2.2.1.1 Szenarien . . . . . . . . . . . . . . . .
2.2.1.2 Verkehr . . . . . . . . . . . . . . . . .
2.2.1.3 Fahrverhalten . . . . . . . . . . . . . .
2.2.2 Mögliche Szenarien/Versuche . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
3
3
3
4
4
4
4
4
5
5
5
5
3 Analyse bestehender Fahrsimulatoren
3.1 Virtual Environments Laboratory . . .
3.2 VDrift . . . . . . . . . . . . . . . . . .
3.3 Grand Theft Auto . . . . . . . . . . .
3.3.1 Multi Theft Auto . . . . . . . .
3.4 Silab . . . . . . . . . . . . . . . . . . .
3.5 AutoSim . . . . . . . . . . . . . . . . .
3.6 STISIM . . . . . . . . . . . . . . . . .
3.7 SCANeR™ . . . . . . . . . . . . . . . .
3.8 Zusammenfassung . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
9
9
11
12
13
13
4 Arbeit mit GTA
4.1 Aufbau der Infrastruktur . . . . . . . . . . . . . . . .
4.2 Installation . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Lauffähiges Windows unter X Rechnern . . . .
4.2.2 GTA installieren . . . . . . . . . . . . . . . .
4.2.3 Downgrade . . . . . . . . . . . . . . . . . . .
4.2.4 Installation MTA . . . . . . . . . . . . . . . .
4.2.5 Installation unseres Versuchsszenarios . . . . .
4.2.6 Umgebung starten (mehrere Rechner / Server)
4.3 Szenario . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Szenarioerstellung . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
18
18
18
19
19
19
22
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
viii
Inhaltsverzeichnis
4.4
4.5
4.3.1.1 Client . . . . . . . . . . . . . . . . . . .
4.3.1.2 Server . . . . . . . . . . . . . . . . . . .
4.3.2 Szenarioauswertung . . . . . . . . . . . . . . . . .
Pre Open-Source . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Integration Lenkrad . . . . . . . . . . . . . . . .
4.4.2 Mehrere Ansichten integrieren . . . . . . . . . . .
Open-Source . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Installation SourceCode . . . . . . . . . . . . . .
4.5.1.1 Installation der Entwicklungsumgebung
4.5.1.2 SVN Source Code . . . . . . . . . . . .
4.5.1.3 Patch . . . . . . . . . . . . . . . . . . .
4.5.1.4 Compile, Deploy and Run . . . . . . . .
4.5.2 Implementierung der Kameraansicht . . . . . . .
4.5.3 Joystick Support . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
25
25
27
27
27
28
29
29
30
31
5 Evaluierung
33
5.1 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6 Zusammenfassung und Ausblick
43
Literaturverzeichnis
45
1. Einleitung
Jeder, der schon einmal mit einem Navigationssystem im Straßenverkehr unterwegs
war, weiß, dass diese Systeme bei weitem noch nicht ausgereift sind. Zwar findet
man mittlerweile fast immer den Weg, jedoch reicht eine gute Streckenführung allein
nicht aus. Die Eingabe des Zieles und jede weitere Kommunikation mit dem Gerät
erfordert bisher eine hohe Konzentration des Fahrers, so dass sie nicht während
der Fahrt erfolgen darf. Ansonsten könnte es zu gefährlichen Beeinträchtigungen
kommen. Deshalb sollte sich das Gerät an den Benutzer anpassen.
Für die Lösung dieses Problems bietet sich ein adaptives Dialogsystem an. Der Fahrer in einem Auto muss bis zu mehreren Stunden mit dem System interagieren und
muss dabei die ganze Zeit auf den Verkehr und die Umgebung reagieren können.
Der Benutzer darf hier nicht abgelenkt werden, da er somit zu einer Gefahr für sich
und Andere auf der Straße werden könnte. Das Gleiche gilt natürlich auch, wenn
das System einschläfernd wirkt und der Fahrer dadurch zu spät auf Ereignisse im
Straßenverkehr reagiert.
Um eine Evaluierung solcher adaptiver Dialogsystem zu ermöglichen sind Fahrsimulatoren vonnöten. Nur mit ihnen kann garantiert werden, dass niemand verletzt wird
oder sogar Schlimmeres passiert. Hier können in einer sicheren Umgebung alle Funktionen erprobt und verbessert werden. Die Versuche sind beliebig oft reproduzierbar und alle auftretenden Parameter können aufgezeichnet und analysiert werden.
Außerdem ist sichergestellt, dass die für die jeweilige Untersuchung notwendigen
Situationen jederzeit erzeugt und kontrolliert werden können.
Erst wenn die Sicherheit des Systems gewährleistet ist, können die Tests auch auf
Fahrzeuge im realen Straßenverkehr ausgeweitet werden.
1.1
Zielsetzung der Arbeit
Ziel unserer Arbeit war es, einen kompletten Fahrsimulator aufzubauen. Mit diesem
sollen Versuche zur Evaluierung eines adaptiven Dialogsystems durchgeführt werden.
Diese Arbeit beschäftigt sich primär mit der hierfür erforderlichen Software. Der
Aufbau der Hardware wird in Frieder Reinholds Studienarbeit näher beschrieben
[18].
2
1. Einleitung
Zusätzlich zu dem von uns fertiggestellten System soll es mit dieser Arbeit auch
Anderen ermöglicht werden, den Fahrsimulator nachzubilden oder zu warten.
1.2
Gliederung der Arbeit
Die folgenden Kapitel beschäftigen sich mit der Software für einen Fahrsimulator.
Angefangen bei der Suche nach bereits erhältlichen Systemen bis hin zur Implementierung und Evaluierung des von uns entwickelten Systems.
Das Kapitel “Grundlagen” befasst sich damit, was Fahrsimulatoren alles leisten müssen, um unseren Anforderungen Genüge zu tun und sich somit für unsere Versuche
zu eignen.
Im Kapitel “Analyse bestehender Fahrsimulatoren” werden verschiedene existierende
Fahrsimulatoren begutachtet, mit welchen wir uns während unserer Arbeit eingehend
beschäftigt haben.
Das Kapitel “Arbeit mit GTA” beschäftigt sich mit dem letztendlich von uns verwendeten System GTA (Grand Theft Auto). Hier wird erklärt, wie sich die Software
installieren und verwenden lässt.
In der “Evaluierung” beschreiben wir Möglichkeiten, um den von uns aufgebauten
Fahrsimulator auf seine Leistungsfähigkeit hin zu testen.
Im letzten Teil wird eine Zusammenfassung unserer Arbeit und ein Ausblick auf
zukünftige Projekte gegeben.
2. Grundlagen
Immersion bezeichnet den Grad des Eintauchens in eine virtuelle Realität. Unser Ziel
war es eine möglichst hohe Immersion zu ermöglichen, um z. B. Effekte wie erhöhte
kognitive Auslastung unter realistischen Bedingungen untersuchen zu können. Doch
welche Faktoren spielen dafür überhaupt eine Rolle und auf was ist dabei zu achten?
Nachfolgend wird beschrieben welche Kriterien für die Wahl der Hard- und Software
wichtig waren.
2.1
Hardware
Um einen Fahrsimulator betreiben zu können, ist als erstes eine entsprechende Hardware erforderlich. Diese fungiert als Nahtstelle zwischen dem Mensch und der simulierten Welt. Außerdem kann die Software nicht unabhängig von der Hardware
existieren. Die Hardware muss natürlich die Anforderungen (z. B. Performance) der
Software erfüllen können, damit diese voll ausgenutzt werden kann. Zusätzlich muss
sie auch unsere Anforderungen an den Realismus erfüllen. Ein einfacher DesktopRechner mit einem Bildschirm, Tastatur und Maus reicht nicht aus, um ein reales
Fahrgefühl zu vermitteln.
2.1.1
Projektion
Da die Benutzung nur einer, nach vorne ausgerichten, Ansicht ein vorausschauendes
Fahren erschwert, strebten wir einen Aufbau mit mehreren Projektoren an.
Zur Realisierung der, auf nicht nur einen Monitor, beschränkten Ansicht, gibt es
prinzipiell zwei Möglichkeiten. Falls die Simulatorsoftware es unterstützt, können
an einen Rechner mehrere Anzeigen angeschlossen werden. Die mögliche Anzahl
variiert mit den verwendeten Grafikkarten. Da die meisten Simulatoren jedoch wegen
Geschwindigkeitseinbußen darauf verzichten, müssen mehrere Rechner mit je einer
Ansicht in einem Netzwerk verbunden werden.
4
2.1.2
2. Grundlagen
Sound
Der heutzutage in der Standardkonfiguration erhältliche 5.1 Sound reicht für unsere
Zwecke. Dabei erzeugen fünf im Raum verteilte Boxen den mit der Soundkarte generierten Ton und sorgen so für einen Raumklang. Da tiefe Töne schwer zu lokalisieren
sind, genügt ein einzelner Subwoofer.
2.1.3
Eingabegeräte
Als Eingabegerät ist ein Lenkrad, wie es in einem normalen Auto verwendet wird,
einer Tastatur- und Maussteuerung vorzuziehen, da Probanden mit einer solchen
Steuerung vertraut sind und sie mehr Realismus bietet. Es stehen viele, für den
Spielebereich entwickelte, Geräte zur Auswahl. Von einem Lenkrad, bis hin zu drei
Pedalen und einer Sechs-Gang-Schaltung.
2.1.4
Kraftrückmeldung
Für die Kraftrückmeldung gibt es verschiedene Ansätze. Zum einen kann ein einfaches Force-Feedback-Lenkrad verwendet werden, dass unter Windows über die
DirectInput-Schnittstelle von Microsofts DirectX angesprochen wird. Es stehen jedoch auch ausgefeiltere Aufbauten wie Bewegungsplattformen zur Verfügung. Jedoch kommen diese für uns aus Ressourcen- und Platzmangel nicht in Frage. Eine
einfache aber effiziente Lösung um die Motor- und Fahrbahnvirbrationen zu simulieren, ist es, den vorhandenen Sound abzugreifen und die tiefen Frequenzen mit einem
Bassshaker wiederzugeben. Ein Bassshaker erzeugt, als Basslautsprecher ohne Membran, die gewünschten Vibrationen.
2.2
Software
Zusätzlich zum Hardwareaufbau wird eine Software benötigt, die dem Aufbau“Leben
einhaucht”. Diese muss über Unterstützung für die Hardwarekomponenten verfügen.
Beispielsweise lässt sich das von uns gekaufte Logitech G25 Lenkrad noch nicht in
vollem Funktionsumfang in allen Systemen nutzen.
Die Rahmenbedingungen für unseren Simulator waren hauptsächlich durch den Realismus gesetzt, damit die erzielten Erkenntnisse auch auf den echten Straßenverkehr
anwendbar sind. Aber auch die Kosten und die verfügbare Zeit waren sehr wichtige
Faktoren, die zu beachten und einzuhalten waren.
2.2.1
Was muss ein Simulationssystem für uns leisten
Ein Simulator muss natürlich so realistisch wie möglich erscheinen, da seine Hauptaufgabe darin besteht, ein Modell der Realität zu sein. Dieser Realismus ist deswegen
wichtig, damit die Ergebnisse auch auf die Realität anwendbar sind. Versuche sollten wiederholbar sein, weswegen auch eine Skriptbarkeit erforderlich ist, um gleiche
Bedingungen für die einzelnen Probanden zu ermöglichen. Ansonsten sind die Ergebnisse schwer miteinander vergleichbar.
Es muss möglich sein, die Simulationsdurchläufe zu protokollieren um sie später
auszuwerten. Auch erforderlich für diese Auswertung sind Sensordaten, wie z. B.
die Auslenkung des Lenkrads, die synchron untereinander und gegebenenfalls mit
externen Sensoren aufgezeichnet werden müssen.
2.2. Software
2.2.1.1
5
Szenarien
Die virtuelle Umwelt sollte abwechslungsreich sein, um Versuche zu unterschiedlichen Gegebenheiten durchführen zu können. Eine lange monotone Landstraßenfahrt
erfordert andere Fähigkeiten vom Fahrer als eine “Stop and go” Stadtfahrt. Auch
ein direkter Übergang zwischen diesen Szenarien, ohne einen neuen Versuchslauf zu
starten, ist wünschenswert.
Vorteilhaft ist, wenn bereits viele gebräuchliche Szenarien mit der Software mitgeliefert werden. Dadurch entfällt eine womöglich langwierige Einarbeitungszeit.
Noch nicht vorhandene Szenarien sollten sich ohne zu großen Aufwand erstellen lassen. Es ist unvorteilhaft, wenn dafür mehr Zeit verloren geht als mit den eigentlichen
Tests.
2.2.1.2
Verkehr
Damit die virtuelle Welt nicht leer und tot wirkt, sollte Verkehr existieren. Für
den Probanden sollte dieser autonom erscheinen, um die Immersion nicht zu verschlechtern. Dies wird dadurch erreicht, dass die Verkehrsteilnehmer auf den Fahrer
reagieren und sich ansonsten an die Verkehrsregeln halten.
Um einen autonom scheinenden Verkehr zu verwirklichen, muss entweder eine künstliche Intelligenz (KI) die anderen Fahrzeuge steuern oder diese müssen mit Hilfe von
Ereignissen über Skripte gelenkt werden. Der Vorteil von Skripten ist die Wiederholbarkeit der Versuche, der Nachteil der höhere Aufwand zur Erstellung. Mit Skripten
können nur sehr schwer alle auftretenden Situationen abgedeckt werden, dafür jedoch auch bestimmte Situationen provoziert werden.
2.2.1.3
Fahrverhalten
Die Fahrphysik sollte realistisch sein, um sich wie bei einem echten Auto anzufühlen. Von dieser ist unter anderem die Geschwindigkeitswahrnehmung betroffen.
Wenn das Fahrzeug dem Probanden zu langsam vorkommt und er dadurch stärker
beschleunigt, wird das Risiko eines Unfalls erhöht. Dies ist zwar ungefährlich, jedoch
werden die Versuche im Allgemeinen dann abgebrochen.
Ein hoher Realismus erleichtert den Probanden die Auswirkungen ihrer Taten besser
einschätzen zu können, da sie so handeln können wie sie es aus der echten Welt
gewohnt sind.
Wie später in der Evaluation (siehe Kapitel 5) zu sehen sein wird, ist das Fahrverhalten ein nicht zu unterschätzender Faktor.
2.2.2
Mögliche Szenarien/Versuche
Zu Beginn der Arbeit war es noch unklar, welche Software wir für unsere Versuche
verwenden würden. Deshalb suchten wir zuerst generelle Szenarien und Versuche,
mit denen wir, unabhängig von der Simulatorsoftware, das Dialogsystem evaluieren
konnten.
Damit unser System für später stattfindende Experimente vorbereitet ist, überlegten
wir uns einige Versuche, die unter Umständen wirklich durchgeführt werden würden.
6
2. Grundlagen
Hierdurch wollten wir herausfinden, ob unser Fahrsimulator unseren Anforderungen
entsprach, wir also in der Lage wären alle Experimente durchzuführen.
Ziel der Versuche war es, herauszufinden, wann der Fahrer durch Ablenkungen oder
Störungen sein Fahrverhalten ändert. Zudem wollten wir wissen, ob diese Änderungen auch durch denkerische Leistungen stattfinden.
Als mögliche Szenarien hatten wir folgende Ideen:
Informationssystem simulieren
Dem Fahrer werden automatische Hinweise zur Verkehrssituation gegeben und es
wird gemessen, ob und in welchen Situationen er sie befolgt. Beispiele der Hinweise
wären:
“Links herum wäre schneller.”
“Rechts ist Stau, fahren Sie besser links.”
“Achtung, Ihr Vordermann bremst.”
“Achtung, kleines Kind am Straßenrand”
Memory
Hier werden verschiedene Spielkarten an der Strecke verteilt. Die eine Hälfte der
Karten sind rot umrandet, die anderen grün. Die grün umrandeten haben eine gut
erkennbare Nummer (weiß in schwarzem Kreis) - diese muss sich der Proband merken. Kommt eine rotumrandete Karte, so muss er die Nummer der passenden grünen
Karte sagen. Die Zuordnung erfolgt dabei durch das Spielkartenmotiv (z. B. Herz Dame). Zur Motivation kann das Ganze als Wettstreit funktionieren: z. B. wer braucht
am wenigsten Runden, wer war am schnellsten etc.
Fahrer erschrecken
Das Dialogsystem gibt Anweisungen, die vom Probanden möglichst schnell befolgt
werden sollen. Das System schreit z.B. öfters “Halt”. Gewöhnt sich der Fahrer daran
und werden seine Reaktionszeiten schneller oder wird der Fahrer dadurch erschreckt
oder verursacht sogar einen Unfall?
Fahrer irritieren
Ein Auto, welches Schlangenlinien oder extrem langsam fährt, soll den Fahrer irritieren. Verschiedene Sensoren messen dann die Bio-Signale des Fahrers um Stress
und Wut zu messen.
3. Analyse bestehender
Fahrsimulatoren
Zu Beginn unserer Arbeit war es nötig, sich einen Überblick über bestehenden Lösungen für einen Fahrsimulator zu verschaffen. Es war zu dem Zeitpunkt noch nicht
klar, ob wir ein Komplettsystem kaufen, ein bestehendes System erweitern, oder ein
eigenes System entwickeln würden. Es mussten Kosten und Nutzen abgewägt werden. Wir entschieden uns, einen genaueren Blick auf die nachfolgenden Systeme zu
werfen, da sie das meiste Potenzial versprachen. Einen Überblick über die Vor- und
Nachteile der Systeme bietet Tabelle 3.2.
3.1
Virtual Environments Laboratory
Der, von der Northeastern University entwickelte, Fahrsimulator ‘Virtual Environments Laboratory’ [10] schied bei unserer Suche nach einem für uns geeigneten System ziemlich früh aus. Die Grafik war nicht auf dem aktuellen Stand der Technik
und dadurch auch nicht wirklich realistisch. Dieser Realismus ist für uns jedoch von
hohem Interesse.
Der Vorteil dieser Software wäre es, dass sie mit Quellcode geliefert werden würde,
und wir so alles nach unseren eigenen Bedürfnissen anpassen könnten. Auch die
Entwicklung an einer Universität wies auf ein forschungsnahes Projekt hin.
3.2
VDrift
Bei VDrift [15] handelt es sich um ein Open-Source-Projekt, dessen Entwicklung
2005 begann. Da das Ziel des Projekts ein realistischer Autorennen-Simulator war,
existieren hauptsächlich Rennstrecken und Rennfahrzeuge. Die Fahrphysik orientiert sich an echten Autos und fühlt sich auch so an. Es existieren nur geschlossene
Strecken, in denen der Fahrer seine Rundenzeit messen kann. Offene Strecken mit
Kreuzungen und dergleichen sind nicht vorgesehen. Die KI ist nur darauf getrimmt,
der Strecke entlang zu fahren, ohne auf andere Fahrer zu achten. Es gibt auch keine
Kollisionen mit anderen Fahrzeugen, sondern nur mit der Strecke. Die Szenarienerstellung erfordert eine separate Modellierung der Strecke in einem 3D-Modellierer,
8
3. Analyse bestehender Fahrsimulatoren
wie z.B. Blender. Die Definition der befahrbaren Strecke/Straße erfolgt in einem
weiteren Arbeitsgang.
VDrift verfügt über einen Netzwerkmodus mit dem z.B. mehrere Ansichten realisiert
werden können. Eine Lenkradunterstützung für das, von uns verwendete, Logitech
G25 ist auch vorhanden. Dem Spiel integriert ist außerdem ein Replay-Modus, mit
dem die ganze Fahrt aufgezeichnet und zu einem späteren Zeitpunkt wieder betrachtet und analysiert werden kann.
Der Quellcode ist gut verständlich, da er ordentlich kommentiert und übersichtlich
strukturiert ist. Wie bei den meisten offenen Systemen hat man die Möglichkeit kostenlosen Support von anderen Entwicklern über dessen Community (Forum/Chat)
zu bekommen.
Abbildung 3.1: Screenshot aus VDrift
3.3
Grand Theft Auto
Grand Theft Auto III (GTA) [3] ist ein kommerziell erhältliches 3D Spiel, das in
seiner ursprünglichen Version 2001 erschienen ist. Bei den beiden Vorgängern handelte es sich noch um 2D Spiele. 2002 wurde die erste Erweiterung GTA: Vice City
veröffentlicht. Wir betrachten hier GTA: San Andreas, das seit 2004 erhältlich ist.
Es beinhaltet neue Funktionen, wie z.B. dynamische Echtzeitschatten oder Wetterphänomeme (Regen, Nebel, Hitzeflimmern) und eine erhöhte Sichtweite.
GTA:SA zeichnet sich vor allem durch eine 36 km2 große virtuelle Welt aus, die den
amerikanischen Städten Los Angeles, San Francisco und Las Vegas nachempfunden ist. Es existieren ca. 200 verschiedene Fahrzeuge, neben Autos auch Fahrräder,
Hovercrafts oder Helikopter.
3.4. Silab
3.3.1
9
Multi Theft Auto
Multi Theft Auto (MTA) [8] ist eine Modifikation (Mod) für GTA. Ursprünglich als
Experiment entstanden, erweitert es das Spiel um einen Mehrspielermodus, während
das Original nur für den Einzelspielerbetrieb vorgesehen war. Mit diesem Mehrspielermodus ist es möglich, mehrere Ansichten zu integrieren. Im Gegensatz zu anderen verfügbaren GTA-Mods verwendet dieses Mod nicht das Skriptingsystem des
Spiels. Stattdessen nutzt es Hooks, mit denen Funktionsaufrufe des Spiels durch
eigene ersetzt werden. Hierdurch ist es möglich, eigene Funktionalität in ein ansonsten geschlossenes System einzubauen. MTA verfügt über ein Google Code Projekt1 ,
worüber auf den Quellcode und weitere Informationen zugegriffen werden kann.
MTA implementiert zusätzlich die Skriptsprache LUA, mit der es leicht möglich ist,
eigene Projekte und Spielmodi zu verwirklichen. LUA wird in vielen Applikationen,
wie z.B. Adobe’s Photoshop Lightroom oder World of Warcraft verwendet. Es ist
schnell, portabel, mächtig, aber auch leicht zu erlernen. Informationen zu LUA sind
auf der offiziellen Homepage zu finden2 .
Die Skripte müssen nicht kompiliert werden und übertragen sich bei einer Verbindung auf den Server automatisch auf die Clients, was eine einfache Entwicklung
fördert.
3.4
Silab
Silab [2] ist eine kommerzielle Fahrsimulatorsoftware der Firma WIVW, einer Ausgründung aus der Universität Würzburg.
Das Produkt ist modular aufgebaut. Somit ist es einfach, zu einem späteren Zeitpunkt neue Funktionalitäten durch Pakete hinzuzufügen. Es stehen ca. ein Dutzend
Pakete zur Verfügung, von denen sich einige gegenseitig ausschließen, einschließen
oder voraussetzen.
Alle auftretenden Parameter, wie die Bedieneingaben des Fahrers oder Informationen über andere Verkehrsteilnehmer, können synchronisiert aufgezeichnet werden,
um sie später für die Auswertung zu verwenden. Es ist auch möglich eine Wiederholung eines Versuchs später anzuschauen oder ein Video mit diesen Daten zu
generieren.
Die Simulation verfügt über mehr als 20 verschiedene Fahrzeugmodelle, welche zusätzlich mit verschiedenen Texturen belegt werden können. Fußgänger können mit
dem entsprechenden Modul auch eingebunden werden.
Die Grafikausgabe unterstützt beliebig viele Bildkanäle. Licht, Schatten und Reflexionen werden realistisch dargestellt. Auch Wetterphänomene wie Nebel und Regen
werden simuliert.
Das System verfügt über den besten, der von uns betrachteten, Streckeneditor. Bei
diesem muss nicht, wie bei den meisten anderen, zuerst die 3D-Repräsentation des
Szenarios erstellt werden, sondern die Welt wird aus Streckendefinition erstellt. Man
muss also nur festlegen, wo sich die Straßen, Kreuzungen, Häuser etc. befinden, und
1
2
http://code.google.com/p/multitheftauto/
http://www.lua.org/
10
3. Analyse bestehender Fahrsimulatoren
Name des Pakets
Grundpaket
Funktion
Enthält das Software-Framework an sich, eine einfache Fahrdynamik, Datenbasis, Verkehrssimulation, einfache Soundsimulation sowie eine Demostrecke bestehend aus einer kleinen Stadt, Überlandstrecke und einem Autobahnabschnitt. Daneben sind allgemein verwendbare DPUs enthalten aus den Bereichen - Signalverarbeitung
(Filter, Signalgeneratoren usw.) - logische Operationen (Vergleiche,
logische Gatter) - Datenaufzeichnung - Kommunikation über UDP
und TCP/IP
Editierbarkeit Course
Mit diesem Paket können Sie Landstraßen- und Autobahnszenarien selbst entwerfen. Dies beinhaltet die freie Gestaltung von Lageund Höhenplan, Querschnittsprofil, Beschilderung, Straßenmarkierungen, umgebende Landschaft und Verhalten der anderen Fahrzeuge. Einschränkung: Der Querschnitt entlang einer Straße darf sich
nicht ändern und es gibt keine Abzweigungen. Eine Autobahnauffahrt und -abfahrt sowie eine T- und X-Kreuzung für Landstraßen
sind enthalten.
Editierbarkeit Area
Erlaubt
die
Gestaltung
komplexer
Straßengeometrien
(Autobahnauf- und -abfahrten, Kreuzungen, Querschnittsübergänge und Stadtteile). Dies beinhaltet den Entwurf von
Straßengeometrie, Markierungen, Beschilderung, Ampeln, grafische Ausgestaltung und das Verhalten anderer Fahrzeuge.
MOV
Simulation von Fußgängern
Entwicklerpaket DPU
Erlaubt die Programmierung eigener Softwarekomponenten für SILAB in C++.
Entwicklerpaket MATLAB/SIMULINK
Wie ‘Entwicklerpaket DPU’, nur dass die Softwarekomponenten in
MATLAB/SIMULINK entwickelt werden und mit dem RealtimeWorkshop in eine SILAB-DPU kompiliert werden.
Entwicklerpaket ODB
API, mit der effiziente Abfragen von Objekten der simulierten Welt
gemacht werden können.
Entwicklerpaket CAN
API, mit der sehr einfach CAN-bus basierte Hardwarekomponenten
in die Simulation eingebunden werden können.
Erweiterte Soundsimulation
Realistische Simulation von Motor-, Roll- und Windgeräuschen eines 5er BMWs.
Fahrdynamik mstVeda
Fahrdynamiksimulation eines BMW520i.
Fahrdynamik CarSim
Integration der Fahrdynamik aus CarSim.
Fahrdynamik IPG CarMaker
HMI
Integration der Fahrdynamik aus IPG CarMaker.
Generierung
Videos
Die Anzeige eines Bildgenerators wird mit frei wählbarer Kameraperspektive als digitales Video abgespeichert. Die Kameraperspektive sowie das Starten und Beenden der Aufzeichnung kann dabei
abhängig vom Szenario erfolgen.
digitaler
Paket, mit dem sehr einfach HMIs (z.B. Anzeigen und Bedienkomponenten von Fahrerassistenzsystemen oder Kombi-Displays bestimmter Fahrzeugtypen) simuliert werden können.
Tabelle 3.1: Verfügbare Silab-Pakete
3.5. AutoSim
11
der Editor generiert daraus die Strecke. Auch Events können hier leicht definiert
werden.
Es steht auch eine C++ API und eine Matlab/Simulink Target zur Verfügung, mit
dem die Silab-Software erweitert werden kann.
Die Software Komponenten bestehen aus sogenannten DPUs (data processing units).
Sie verfügen über Ein- und Ausgänge, über die sie miteinander verschaltet werden.
So verfügt z. B. die DPU ‘Fahrdynamik’ über Eingänge von der Steuerung und der
Datenbasis sowie über Ausgänge, ebenfalls für die Datenbasis und die Visualisierung.
So kann z. B. die Steuerung leicht durch eine andere ersetzt werden.
Die DPUs können zur Lastverteilung auf verschiedenen Rechnern ausgeführt werden.
Die Kommunikation findet über Netzwerk statt.
Hardware kann über CAN, TCP/IP, UDP, serielle oder parallele Kommunikation
angesprochen werden.
Da kein Zugriff auf den Quellcode besteht, kann nicht alles von uns geändert werden.
Die Grafikqualität ist dadurch von uns nicht beeinflussbar.
Abbildung 3.2: Screenshot aus Silab [13]
3.5
AutoSim
AutoSim [1] ist eine norwegische Firma, die Fahrsimulatoren und Simulationssoftware herstellt, entwickelt und vermarktet.
Ein im Einsatz befindlicher Fahrsimulator wurde uns von einem der Entwickler persönlich beim Fraunhofer Institut in Stuttgart vorgestellt. Hier bot sich uns das Bild,
12
3. Analyse bestehender Fahrsimulatoren
Abbildung 3.3: Silab Streckeneditor (Editierbarkeit Area) [13]
dass das System trotz jahrelangem Einsatz immer noch nicht vollständig ausgereift
war. Ein gravierender Fehler äußerte sich z. B. in einem, von der Strecke abhebenden,
computergesteuerten Auto.
Die Szenarienerstellung ist auch sehr aufwändig und die dafür benötigte Zeit wurde
vom Entwickler mit mehreren Monaten angegeben. Für neue Strecken muss zuerst
eine 3D-Repräsentation erstellt werden, die danach mit Meta-Daten angereichert
wird.
3.6
STISIM
Um uns die Simulatiossoftware ‘STISIM Drive™’ [14] anzuschauen, besuchten wir ein
Industrieunternehmen, welches das System zur Erprobung von Navigationsgeräten
einsetzt.
Verglichen mit den meisten anderen Systemen war die Grafik schlecht. Die Auflösung
war niedrig und auch die Texturen ließen zu wünschen übrig. Außerdem war sie fest
auf drei Ansichten ausgelegt, eine Änderung wäre mit unverhältnismäßig hohem
Aufwand verbunden.
Auch in anderen Bereichen wäre viel Nacharbeit nötig. So hat z. B. der von uns
besuchte Kunde den Sound und den Verkehr selbst neu implementiert, was nicht für
die Qualität der mitgelieferten Komponenten spricht.
Für die Software gibt es nur einen einzigen Ansprechpartner, wodurch es bei hoher
Auslastung zu Verzögerungen kommen kann.
3.7. SCANeR™
3.7
13
SCANeR™
Bei der Software SCANeR™[12] handelt es sich ebenfalls um ein kommerzielles Produkt. Es wird von der französischen Firma Oktal entwickelt und vertrieben. Wir
konnten uns bei der ‘Vehicle Dynamics Expo’ in Stuttgart, bei der auch Oktal vertreten war, persönlich ein Bild von der Software machen.
Dieser Fahrsimulator ist einer der umfangreichsten und am weitesten entwickelten
der von uns betrachteten. Jedoch ist er, selbst mit einem großen Rabatt für Universitäten, auch der teuerste.
Dieses System hatte die beste Grafikausgabe, die wir gesehen haben. Eine hohe
Auflösung, gute Texturen, dynamische Schatten und andere Effekte trugen zu einem
realistischen Eindruck bei. Auch die Skriptingmöglichkeiten schienen ausgereifter als
bei der Konkurrenz. Es bot auch als einziges der Fahrsimulatoren Autoanhänger oder
am Auto befestigte Gegenstände, wie z. B. ein Surfboard, an.
Das System ist ähnlich der anderen kommerziellen Simulatoren in Module/Pakete
unterteilt.
Abbildung 3.4: Screenshot aus SCANeR™[11]
3.8
Zusammenfassung
Am Ende entschieden wir uns dafür, ‘Grand Theft Auto: San Andreas’ mit der
Modifikation ‘Multi Theft Auto’ zu verwenden. Hier boten sich für uns die meisten
Vorteile zu einem vernünftigen Preis. Eine Zusammenfassung der Vor- und Nachteile
bietet Tabelle 3.2.
14
3. Analyse bestehender Fahrsimulatoren
GTA verfügt über den größten Streckenumfang mit der besten Qualität. Die Grafik
kann mit den dedizierten Fahrsimulatoren mithalten.
Durch MTA steht eine gute Erweiterbarkeit und Skriptbarkeit zur Verfügung. Mit
dem Mod ist es für uns außerdem möglich mehrere Ansichten zu verwenden.
+
0
Sound
Unterstützung G25
b
a
+
-
Preis
+
+
Erweiterbarkeit
SourceCode
erweiterbar
erweiterbar Multiplayer
-
Editor
N/A
++
0
Grafik
Anzahl Views
0
+
Verkehr
-
++
-
++
+++
3+
-
+
---
++
++
++
Silab
++
-
+
++
3+
+
+
--
++
++
+
-
++
+
3
+
-
-
+
++
+
Autosim STISIM
+
+
Tabelle 3.2: Vergleich der Systeme
-/+
++
+
1b
1a
+
0
+
++
++
+
+++
+
++
0
0
Strecken Qualität
Strecken Umfang
Virtual Env Lab VDrift GTA/MTA
N/A
++
+++
-
++
+++
3+
+
+
----
+++
++
+++
SCANeR™
+++
3.8. Zusammenfassung
15
16
3. Analyse bestehender Fahrsimulatoren
4. Arbeit mit GTA
Dieses Kapitel beschäftigt sich mit der, von uns zur Verwendung ausgesuchten, Software Grand Theft Auto: San Andreas mit der Netzwerkerweiterung Multi Theft
Auto.
4.1
Aufbau der Infrastruktur
Da die von uns verwendete Software es uns nicht gestattet mehrere Ansichten auf
einem einzelnen PC zu realisieren, griffen wir auf die Netzwerkfähigkeit von MTA
zurück. Dabei ist für jede Ansicht ein Rechner als Client vorgesehen. Somit ist die
Anzahl der Ansichten skalierbar, angefangen von nur einer Front-Projektion, bis zu
einer 360° Rundumansicht und mehreren zusätzlichen Beobachtern.
Je nach verfügbaren Ressourcen kann der Server zusätzlich auf einem der ClientRechner laufen, oder aber auf einem dedizierten System. Das Verwenden eines dedizierten Rechners erlaubt es auf einfachem Wege, während der Versuche Befehle über
die Konsole auszuführen. Läuft die Konsole stattdessen auf dem selben Rechner wie
der Client, muss MTA geschlossen werden, um Zugriff zu erhalten.
18
4.2
4. Arbeit mit GTA
Installation
Um GTA verwenden zu können, ist es zuerst notwendig, alle benötigten Komponenten auf den verschiedenen Rechnern zu installieren. Als Betriebssystem wird
Windows auf den Computern zum Laufen gebracht. Danach folgt die Installation
von GTA und MTA.
4.2.1
Lauffähiges Windows unter X Rechnern
Laut den Systemanforderungen [4] läuft GTA:San Andreas sowohl unter Windows
2000 ab Service Pack 1 als auch unter Windows XP ab Service Pack 1.
Da auf dem, zuerst von uns verwendeten und später eingegliederten, Computer bereits Windows XP installiert war, entschieden wir uns aus Konsistenzgründen die
weiteren Rechner auch damit auszustatten.
Sollte nur eine Linux-Umgebung zur Verfügung stehen, sollte es auch möglich sein,
GTA/MTA mit Wine zu verwenden [9].
Zusätzlich zu Windows werden noch einige Treiber benötigt. Diese befinden sich auf
Datenträgern, die mit der Hardware geliefert wurde.
Auch der Logitech Profiler muss installiert werden. Mit diesem Programm lassen sich
diverse Einstellungen an der Steuerung ändern. Hier kann z. B. die Pedaleinstellung
geändert werden - für unseren Aufbau mit MTA ist die Einstellung der kombinierten
Pedale erforderlich, hierbei werden das Gas und die Bremse auf eine Achse gelegt.
4.2.2
GTA installieren
GTA:SA lässt sich ohne Probleme von der DVD installieren. Eine vollständige Installation ist empfehlenswert, da dadurch nach dem Downgrade (siehe 4.2.3) keine
DVD mehr zum Starten erforderlich ist. Bei dieser Installationsart werden, zusätzlich
zur Standardinstallation, alle Audio-Dateien auf die Festplatte kopiert. Ohne diese
Audio-Dateien beendet sich GTA:SA kurz nach dem Start ohne Fehlermeldung.
Sollte noch kein DirectX 9.0 auf dem Rechner installiert sein, bietet es sich an, dieses
auch von der GTA-DVD zu installieren, da es mitgeliefert wird.
4.2.3
Downgrade
Nachdem GTA installiert ist, muss es, sofern es sich nicht bereits um die Version 1.0
handelt, downgegradet werden[6].
Der Downgrade ist erforderlich, da Rockstar Games die Möglichkeit des Einbindens
von Modifikationen (Mod) in späteren Versionen unterbunden hat. Dies geschah,
nachdem der Mod ‘Hot Coffee’ [16] Aufsehen erregt hatte und das Spiel danach in
einigen Ländern nur noch an Erwachsene oder, wie in Australien, gar nicht mehr
verkauft werden durfte.
Das von MTA zur Verwendung vorgeschlagene Downgrade-Tool funktioniert leider
nicht, da es die Version unserer Installation nicht erkennt. Die uns zur Verfügung
stehende Version ist die Deutsche 2.0.
4.2. Installation
19
Stattdessen verwendeten wir sa-downgrade patch 0.3.1.rar 1 Dieser Downgrader kommt
ohne Versionscheck aus, und lässt sich somit auf unserem System installieren.
Eine bereits entpackte Version befindet sich im gleichnamigen Verzeichnis auf der
beigelegten CD.
4.2.4
Installation MTA
Als nächstes muss MTA installiert werden. Zu Beginn unserer Arbeit verwendeten
wir die ClosedSource Version 1.0-dp2.3. Da wir aber später auf die quelloffene Version
umstiegen, empfiehlt sich die Installation von Release 149 der Nightly Builds, denn
diese ist mit unserer kompatibel. Zum Zeitpunkt unserer Installation war es das
aktuellste Release, weswegen wir uns für diese Version entschieden. Es kann auch
eine neuere Version gewählt werden, falls später entwickelte Funktionen benötigt
werden, jedoch wurde diese von uns noch nicht getestet.
Eine Auflistung der verfügbaren Nightlys findet sich unter:
http://nightly.multitheftauto.com/
Zusätzlich zu diesen tägliche erstellten Kompilaten werden noch weitere Dateien
benötigt. Diese befinden sich in einem separaten Download, da sie sich nur selten
ändern und somit Platz und Bandbreite gespart werden kann, indem sie nicht bei
jedem Update erneut geladen werden müssen. Diese Dateien sind auf der Downloadseite der GoogleCode-Seite aufgelistet.2
Build 149 und die passenden ‘Data files’ befinden sich auch auf der beigelegten CD.
4.2.5
Installation unseres Versuchsszenarios
Bevor wir MTA verwenden können, sind Ressourcen notwendig, in denen mit verschiedenen Skripten Spielmodi oder Erweiterungen definiert sind. Um unser selbst
erstelltes Versuchsszenario in MTA einzubinden, muss der Ordner ‘experiment’ vom
CSL SVN Server3 oder von unserem Datenträger in den ‘resourcen’-Ordner des
MTA-Servers (bei uns unter: C:\Programme\MTASanAndreas\server\mods\deathmatch\
resources\) eingefügt werden.
Das Skript besteht aus einer ‘meta.xml’, einigen Bildern und den beiden Skriptdateien. In der XML-Datei müssen alle Dateien aufgeführt werden, die verwendet
werden sollen. Außerdem ist hier definiert, ob es sich bei den Skripts um Clientoder Serverskripts handelt (siehe 4.3.1).
4.2.6
Umgebung starten (mehrere Rechner / Server)
Nachdem die Installation durchgeführt wurde, ist es möglich MTA zu verwenden.
Um Einstellungen, wie die Auflösung, zu ändern muss jedoch GTA gestartet werden,
da MTA keine Oberfläche dafür bietet. Es empfiehlt sich hier auch die Radiolautstärke zu minimieren. Wenn alle Optionen den Wünschen entsprechend gesetzt sind,
können wir unsere Umgebung starten. Hierfür starten wir zunächst ‘MTA Server’.
1
http://files.filefront.com/sa+downgrade+patch+031rar/;12833867;/fileinfo.html 04.03.09
http://code.google.com/p/multitheftauto/downloads/list
3
svn+ssh://csl.ira.uka.de/svn/driving-simulator-gta
2
20
4. Arbeit mit GTA
Nachdem der Server vollständig geladen ist, muss in der Konsole ‘start experiment’
eingegeben und mit Enter bestätigt werden. Durch diesen Befehl werden die Skripte
aus dem Ordner ‘experiment’ gestartet, in denen unsere Versuchsszenarien definiert
sind. Nachdem der Server wie in Abbildung 4.1 den Start positiv mit “Resource
‘experiment’ started” quittiert hat, können die Clients verbinden. Die neun in diser Abbildung zu sehenden Fehlermeldungen können ignoriert werden. Diese Fehler
treten auf, wenn nicht die zusätzlich erhältlichen offiziellen Ressourcen installiert
werden, sie werden jedoch nicht für unser System benötigt.
Abbildung 4.1: MTA Server Konsole
Auf jedem der verwendeten Simulationsrechner wird nun MTA ausgeführt.
Die Intros müssen mit einigen Mausklicks übersprungen werden. Ohne das Überspringen bleibt nur ein schwarzer Bildschirm zu sehen und die Rechner blieben bei
uns auch vereinzelt hängen.
Bei den Intros und Ladebildschirmen handelt es sich um von uns erstellte Bilder.
Die originalen Bilder wurden von uns angepasst, damit die Probanden einen besseren Eindruck von unserem System bekommen. Auch der Ladesound wurde von uns
geändert, da die ursprüngliche Musik als störend empfunden wurde. Die von uns veränderten Dateien liegen auf dem CSL SVN4 und der CD im Ordner ‘gtabranding’
bei.
Vor dem Verbinden sollte sichergestellt werden, dass die einzelnen Clients über individuelle Spielernamen verfügen, da der Verbindungsaufbau sonst wegen einer Namenskollision abgebrochen wird. Der Name lässt sich im ‘SETTINGS’ Menü ändern.
In dem nach dem Start erscheinenden Menü muss ‘QUICK CONNECT’ gewählt
und in der darauffolgenden Eingabemaske die Adresse, der Port und gegebenenfalls
4
svn+ssh://csl.ira.uka.de/svn/driving-simulator-gta/gtabranding
4.2. Installation
21
ein Passwort des Servers eingegeben werden. Die Adresse lässt sich in der Eingabeaufforderung von Windows durch den Befehl ‘ipconfig’ ermitteln. Der Port wird
beim Start des MTA-Servers angezeigt und ist als Standard auf ‘22003’ gesetzt.
Abbildung 4.2: MTA Client Verbindungsdialog
Nach Änderungen an den Server-Ressourcen wird beim nächsten Verbinden der Download der geänderten Dateien angezeigt. Danach bleibt ein schwarzer Bildschirm zu
sehen und Eingaben zur Wahl des Ansichtmodus sind möglich: Zur Unterscheidung
der verschiedenen Ansichten muss nach dem erfolgreichen Verbinden eine Zahl zwischen 1 und 3 gedrückt werden. Die 1 gibt dem Client die Rolle des Fahrers, er hat
Kontrolle über die Steuerung und die mittlere der drei Ansichten. Die 2 ist für die
linke Ansicht und 3 für die rechte.
22
4.3
4. Arbeit mit GTA
Szenario
Für unsere ersten Versuche mit GTA verwenden wir die später vorgestellte API,
um die Probanden eine vorgegebene Strecke entlangfahren zu lassen. Dabei gibt
ihnen ein, als Wizard fungierender, Beobachter Informationen, die später mit einem
Fragebogen abgefragt werden, um die kognitive Leistung zu messen.
Der Wizard befindet sich in einem anderen Raum und ist auch als Client mit dem
System verbunden. Beim Wizard handelt es sich um einen Menschen, der vom Probanden als artifizielles System wahrgenommen werden soll. Nach dem connecten
wählt er seine Rolle durch Tastendruck aus. Er sieht, wo sich der Fahrer momentan befindet, bekommt aber noch zusätzliche Informationen eingeblendet, die ihm
anzeigen, welche Anweisungen er dem Probanden geben muss. Der Proband und
der Wizard können über einen Audio-Chat miteinander kommunizieren, wobei die
Stimme des Wizard verstellt wird, damit er mehr nach einem Programm als nach
einem Menschen klingt. Zusätzlich sieht der Wizard den Fahrer über eine Webcam.
Vor der festgelegten Strecke wird dem Fahrer die Möglichkeit gegeben, mehrere
Minuten lang nach eigenem Belieben durch die Welt zu fahren, um sich mit dem
Simulator vertraut zu machen. Als Startpunkt wurde eine ebene Strecke in einer der
Städte gewählt.
Nach der freien Fahrt geht es mit dem eigentlichen Versuch los. Das Fahrzeug wird
in ein neue, dem Probanden noch unbekannte Gegend platziert.
Als erstes Ereignis kommt dem Fahrer ein Auto entgegen, wenn er auf die erste vor
ihm liegende Straße einfährt. Zu den weiteren Events zählen auf der Straße stehende
oder gehende Fußgänger, oder andere plötzlich auftauchende Fahrzeuge.
Abbildung 4.3: GTA Projektion für einen Versuchslauf
In diesem Abschnitt wird zusätzlich noch konkret auf die von uns erstellten LUASkripte eingegangen.
4.3. Szenario
4.3.1
23
Szenarioerstellung
Das Szenarioskript besteht aus zwei Textdateien, ‘experiment client.lua’ und ‘experiment server.lua’. Die beiden Dateinamen sind in der Datei ‘meta.xml’ definiert, welche beim Starten des Experimentes eingelesen wird. Eine Einführung in
die Skripting-Umgebung ist unter http://development.mtasa.com/index.php?title=
Scripting Introduction zu finden. Wichtige Konzepte sind die Verwendung von Events,
die auslösen, wenn bestimmte Ereignisse stattgefunden haben, Keybindings, mit denen Tastatureingaben abgefragt werden und colCircles, die als Auslöser für Events
dienen, wenn der Fahrer festgelegte Bereiche durchquert.
4.3.1.1
Client
Das Client-Skript wird beim Verbinden von dem Server auf den Client kopiert und
dann dort ausgeführt. Deshalb werden die Funktionen, welche für die Grafikausgabe
verantwortlich sind, dort definiert. ‘onClientRender’ ist z. B. nur im Client abrufbar,
da sonst alle Berechnungen mehr als 30x in der Sekunde mit dem Server ausgetauscht
werden müssten und die Antwort erst beim nächsten Frame ankommen würde.
Zu Beginn des Skriptes werden zunächst alle Bildschirmeinblendungen (HUD), wie
z. B. Uhrzeit, Lebenspunkte oder Radar ausgeblendet. Sie werden nicht benötigt, da
sie unrealistisch sind, außerdem könnten sie den Fahrer irritieren.
Die Funktion, mit der die Kameraposition angepaßt wird, ist hier ebenso definiert.
In ‘updateCameraPos()’4.1 wird die aktuelle Position und Rotation des virtuellen
Fahrers abgefragt und ein Target-Punkt errechnet, auf den die Kamera gerichtet ist.
Diese Informationen werden über ‘setCameraMatrix’ an das Programm zurückgegeben.
function updateCameraPos ( )
l o c a l pX , pY , pZ = g e t E l e m e n t P o s i t i o n ( d r i v e r )
l o c a l rX , rY , rZ = g e t V e h i c l e R o t a t i o n (
getPlayerOccupiedVehicle ( driver ) )
l o c a l cosA = math . c o s ( math . rad (360− rZ ) )
l o c a l sinA = math . s i n ( math . rad (360− rZ ) )
l o c a l sinB = math . s i n ( math . rad (360−rX ) )
l o c a l t a r g e t X = sinA ∗ 20
l o c a l t a r g e t Y = cosA ∗ 20
l o c a l t a r g e t Z = −sinB ∗ 20
setCameraMatrix (pX , pY , pZ + 1 . 0 , pX + targetX , pY +
targetY , pZ + t a r g e t Z + 1 . 0 )
end
Listing 4.1: Beispiel einer LUA-Funktion
Im Client-Skript sind auch die Zusatzinformationen für den Wizard definiert. So
werden auf seinem Bildschirm Pfeile zur Orientierung angezeigt, wenn der Fahrer in
die angegebenen Bereiche fährt.
4.3.1.2
Server
Über das Server-Skript wird als erstes die Rolle des Clients definiert. Mögliche Rollen: Fahrer, Blick nach links und rechts, oder Wizard. Dazu werden die Tasten 1 bis
24
4. Arbeit mit GTA
6 mit der Funktion ‘setPlayerRole’ verknüpft, sobald ein Client verbunden ist. Beim
Druck auf die ‘1’ wird das Team ‘Fahrer’ erstellt, falls es noch nicht existiert, und
ein Spieler wird erstellt. Ähnliches geschieht bei den anderen Tasten.
Wenn einer der Spieler erstellt wird, wird über das Event ‘onPlayerSpawn’, ‘setObserver’ aufgerufen. Hier wird zunächst die Uhrzeit und das Wetter gesetzt und dann
die Spielzeit verlangsamt, damit nicht schon nach kurzer Zeit die Nacht hereinbricht.
Ohne die Verlangsamung dauert ein Tag im Spiel 24 echte Minuten. Wenn das Team
des erstellten Spielers ‘Fahrer’ entspricht, wird
• ein Fahrzeug erstellt / umpositioniert
• die Türen verschlossen,
• der Fahrer ins Auto gesetzt
• und die Geschwindigkeitsanzeige initialisiert.
Bei der Umpositionierung das Fahrzeugs, wird es zunächst kurz angehoben, da es
ansonsten zu Fehlern kommen kann. Dies hat mit der Kollisionsberechnung zu tun,
weil ohne das Anheben die Stoßdämpferausdehnung zu abrupt geändert wird und
das Fahrzeug dadurch in die Luft katapultiert wird.
Als Fahrzeug wählten wir aus den verfügbaren Modellen das Taxi. Es hatte bessere
Fahreigenschaften als die meisten anderen Autos, z. B. waren die Stoßdämpfer nicht
zu weich eingestellt und es war gut kontrollierbar. Um das Taxi jedoch noch weiter zu
verbessern, nahmen wir einige Änderungen in der ‘handling.cfg’ aus dem GTA ‘data’ Ordner vor. Die maximal Geschwindigkeit wurde reduziert, der Luftwiderstand
reduziert und die Bremse abgeschwächt.
Die in 4.3.2 beschriebene Logfunktion wird auch im Server-Skript definiert.
4.3.2
Szenarioauswertung
Um eine spätere Auswertung zu ermöglichen, werden regelmäßig die Daten des Fahrers gespeichert. Bei diesen Daten handelt es sich um die Position und Rotation des
Fahrzeuges in der virtuellen Welt.
Hierfür werden beim Aufruf von ‘startLog’ Log-Dateien und ein Filehandler darauf
erzeugt. Die Dateien haben im Namen den Startzeitpunkt in der Form“player log ’Jahr’’Monat’-’Tag’-’Stunde’-’Minute’-’Sekunde’.txt”.
Nach der Dateierstellung wird ein Timer gestartet, mit dem alle 100 Millisekunden
die gewünschten Parameter geschrieben werden. Zusätzlich zur Position wird die
Geschwindigkeit und die genaue Zeit zur späteren Synchronisation gespeichert.
Beim Verlassen des Fahrer-Clients wird der Timer beendet und der Filehandler geschlossen.
4.4. Pre Open-Source
4.4
25
Pre Open-Source
Zu beginn unserer Arbeit handelte es sich bei MTA noch um ein Closed-Source
Projekt. Im Laufe unserer Arbeit änderte sich dies und wir konnten die in 4.5 vorgestellten Änderungen implementieren. Da wir jedoch zunächst keinen Zugriff auf
den Quellcode von MTA hatten, mussten Probleme, wie das Nichtvorhandensein von
einer Lenkradunterstützung und die Implementierung von mehreren Ansichten, auf
anderen Wegen gelöst werden.
4.4.1
Integration Lenkrad
MTA enthielt keine Unterstützung für DirectInput und somit für Joysticks/Lenkräder/Gamepads, weswegen die Entwickler XPadder vorschlagen [7], um dennoch in
der Lage zu sein, nicht auf eine Tastatursteuerung ausweichen zu müssen.
Durch dieses Programm wird jedoch nur eine digitale Steuerung wie auf der Tastatur ermöglicht, es gibt also keine Abstufungen bei der Lenkung und dem Gas. In
Tests zeigt sich die Lösung als unbrauchbar, da ein leichter nicht von einem starken
Lenkradausschlag zu unterscheiden war.
Als nächstes probierten wir den Pinnacle Game Profiler aus. Hiermit war es möglich
bis zu 9 Segmente einer Lenkradachse auf verschiedene Tasten zu legen. Jedoch
gab es nur die Möglichkeit, diese Events über ein LUA-Skript auszuwerten. Hier
zeigte sich das Problem, dass die Events von MTA aus zu selten - das minimale
Timerinterval liegt bei 50ms - gepollt wurden und es außerdem zu wenige Segmente
gab, weswegen die Steuerung sich nach wie vor sehr ruckelig anfühlte.
Um die Probleme zu umgehen, schrieben wir ein externes Programm, das die Lenkradachsen über Pulsweitenmodulation (PWM) in Tastaturevents umwandelt. Bei
PWM wird das Zeitverhältnis zwischen zwei Zuständen, in diesem Fall ‘Taste gedrückt’ und ‘keine Taste gedrückt’, so angepasst, dass es im Durchschnitt der Auslenkung der Lenkradachse entspricht. Als Grundlage wurde das dem DirectX SDK
als Beispiel beiliegende Programm zum Joystickinfo auslesen verwendet. Es wurde
dahin gehend erweitert, dass es über ‘keybd event’ virtuelle Tastendrücke an Windows weitergibt.
Auch wenn wir, wie später in 4.5.3 gezeigt, eine bessere Lösung für das Lenkproblem
verwendeten, kann unser Tool, da es MTA umgeht, auch für andere Systeme genutzt
werden, die nur eine Tastatureingabe erlauben.
Um das Tool selber kompilieren zu können muss Visual C++ 2003, wie in 4.5.1.1 beschrieben, installiert werden. Es liegen jedoch auch Projektdateien für neuere Visual
Studio Versionen und eine fertige ausführbare Datei auf unserer CD bei.
4.4.2
Mehrere Ansichten integrieren
Die Idee bei der Integration mehrerer Ansichten ist die, dass die einzelnen Clients aus
der Fahrersicht in die Richtungen der Leinwände schauen und somit die 3 Beamerbilder gemeinsam ein zusammenhängendes Bild darstellen (siehe Abb. 4.4). MTA
bietet folgende integriete Kameraansichten:
• Third-Person (Außenansicht auf den Spieler)
26
4. Arbeit mit GTA
Abbildung 4.4: Zusammenhängende Projektion
• Egoperspektive
• Freie Kamera
Da die einzelnen Ansichten vom selben Punkt aus in verschiedene Richtungen zeigen
und nur ein Fahrer gleichzeitig an der selben Stelle existieren kann, wählten wir die
freie Kamera.
Die freie Kamera unterstützt keine Drehung um die Blickachse. Deshalb kann es
auf Strecken mit starker Steigung zu Darstellungsproblemen in der Seitenansichten
kommen. Steht das Fahrzeug auf einer Steigung, so wird hier die Frontansicht darauf
angepasst, die Seitenansichten zeigen jedoch weiterhin ein horizontales Bild.
Diese Lösung wurde später (siehe 4.5.2) durch eine Änderung im MTA Quellcode
weitgehend ersetzt.
4.5. Open-Source
4.5
27
Open-Source
Die Veröffentlichung von MTA als Open-Source machte die Lösung einiger unserer Probleme überhaupt erst möglich. So war es uns zum Beispiel möglich, eine
integrierte Joystick-Unterstützung zu verwenden und die Projektionsmatrix für die
Ansichten zu manipulieren.
4.5.1
Installation SourceCode
Die Installation der nötigen Mittel orientiert sich größtenteils an der vom den MTA
Entwicklern vorgeschlagenen Vorgehensweise [5].
4.5.1.1
Installation der Entwicklungsumgebung
Um MTA aus dem Quellcode zu kompilieren wird Visual C++ aus der Visual Studio
2003 Familie benötigt. Es existieren zwar auch Visual Studio 2005 Projektdateien,
jedoch ließen sich diese nicht von uns zur Ausführung bringen, selbst nachdem wir
sie mit einigen Anpassungen zum fehlerfreien Kompilieren gebracht hatten. Falls zu
einem späteren Zeitpunkt diese Fehler von den Entwicklern gelöst sein sollten, wäre
es auch möglich, anstatt das komplette Visual Studio 2003 zu installieren, auf das
kostenlos erhältliche Visual C++ Express zurückzugreifen.
Da MTA einige Funktionen von DirectShow verwendet, muss das Platform SDK installiert werden. In der Vergangenheit war DirectShow ein Bestandteil von DirectX,
ist jetzt jedoch nur noch im Platform SDK oder im Windows SDK enthalten. Beim
Ausführen des Setups können alle anderen Komponenten weggelassen werden (siehe
Abb. 4.5), die benötigte Größe des Downloads und des verwendeten Festplattenplatzes wird dadurch erheblich reduziert. Anstatt 1,05GB werden nur noch 60MB
benötigt.
Abbildung 4.5: Installation der DirectShow-Komponenten des Platform-SDK
28
4. Arbeit mit GTA
Zusätzlich wird das DirectX 9 SDK von Microsoft benötigt. In den neusten SDKs befinden sich keine DirectX 8 Header-Dateien mehr, weswegen auf eine ältere Version,
zum Beispiel vom August 2008, zurückgegriffen werden sollte.
Nachdem alle SDKs installiert wurden, müssen noch die Include-Pfade in Visual
C++ angepasst werden. Eigentlich sollten diese bereits richtig gesetzt sein, was auf
unseren Systemen jedoch nicht der Fall war. Im Falle des Platform-SDKs kann es
reichen, ‘register paths’ auszuführen. Ansonsten sollten die VC++ Projektordner um
die Include- und Library-Pfade des Platform- und DirectX-SDK erweitert werden
(siehe Abb. 4.6)
Abbildung 4.6: Include- und Library-Pfade
includes:
C:\Programme\MircosoftPlatformSDKforWindowsServer2008R2\include
C:\Programme\MircosoftSDKs\Windowsv6.0A\include
C:\Programme\MircosoftDirectXSDK(August2008)\include
libs:
C:\Programme\MircosoftPlatformSDKforWindowsServer2008R2\lib
C:\Programme\MircosoftDirectXSDK(August2008)\lib\x86
4.5.1.2
SVN Source Code
Nachdem die Umgebung installiert ist, muss der MTA Quellcode auf den Computer
kopiert werden. Die Quellen liegen in einem von GoogleCode gehosteten SVN. Das
Herunterladen geschieht mit dem kostenlos erhältlichen TortoiseSVN5 als Subversionclient, welches dazu installiert werden muss.
Zunächst erstellen wir den Ordner ‘source’ auf C: . Hier checken wir
http://multitheftauto.googlecode.com/svn/trunk/
in den Ordner C:\source\trunk aus. Dies ist der Großteil der benötigten Quellen.
Danach wird
http://multitheftauto.googlecode.com/svn/vendor/
nach C:\source\trunk\vendor ausgecheckt. Hier befinden sich einige Bibliotheken
von Drittanbietern, die für das Kompilieren erforderlich sind.
5
http://tortoisesvn.net/
4.5. Open-Source
29
Zusätzlich zu den Dateien aus den Repositories werden noch weitere Abhängigkeiten
benötigt. Diese finden sich auf der Google Code Seite von MTA unter den Downloads.
Die erforderliche Datei heißt multitheftauto deps-rXXX.exe.
4.5.1.3
Patch
Als nächstes spielen wir die von uns erstellten Patches ein, in denen die in den
nächsten Abschnitten beschriebenen Änderungen auf die Originalquellen angewandt
werden. Die dafür benötigten Diff-Dateien sind im CSL SVN6 oder auf unserer CD
zu finden. Mit der Datei ‘proj path patch.diff’ die in 4.5.1.4 beschrieben ist, wird
der Deploy-Prozess vereinfacht, indem weniger Schritte bei Änderungen erforderlich
sind. In ‘mta patch.diff’ wird zum einen der Joystick Support (siehe 4.5.3) für unsere
Bedürfnisse angepasst. Zum Anderen befinden sich darin die Änderungen für die
Kamera Projektion (siehe 4.5.2).
4.5.1.4
Compile, Deploy and Run
Nachdem alle erforderlichen Dateien vorhanden sind, kann nun kompiliert werden.
Dazu wird entweder die gesamte ‘Solution’ erstellt, oder es wird bei Änderungen nur
ein Unterprojekt neu erstellt.
In den originalen Projekteinstellungen für die Nightly-Konfiguration liegen die Ausgabepfade in dem Unterordner ‘./output’ und man muss die darin befindlichen Dateien zur Verwendung in die entsprechenden Ordner kopieren. Um diesen deployProzess zu vereinfachen, haben wir die Outputpfade mit unserem Patch angepasst,
damit alle Dateien beim Linken gleich in den richtigen Ordnern erstellt werden.
Zusätzlich haben wir für die beiden Ansichten Rechts und Links zwei eigene Konfigurationen erstellt, bei denen die Dateien auf die als Netzlaufwerke verbundenen
Verzeichnisse der beiden Computer geschrieben werden. Die Netzlaufwerke müssen
dabei folgendermaßen mit Schreibzugriff verbunden sein:
Rechner rechts ‘c:\Programme\MTA San Andreas’ -> y:\
Rechner links ‘c:\Programme\MTA San Andreas’ -> z:\
Wenn man nun als Konfiguration ‘Nightly rechts’ oder ‘Nightly links’ wählt und das
Projekt erstellen lässt, werden die entsprechenden Dateien mit den verschiedenen
integrierten Ansichten auf den PCs erstellt und können gestartet werden.
Bisher haben wir nur die Zielpfade für ‘Client - Core’ für die beiden zur Seite projizierenden Rechner angepasst. Hier finden nämlich die Berechnungen für die Kameramatrizen statt. Wenn in Zukunft auch Unterschiede in anderen Unterprojekten
implementiert werden, müssen die anderen Pfade auch angepasst werden. Unter Umständen sind auch andere Netzlaufwerke einzurichten, wenn sich diese Änderungen
auf Dateien im GTA-Ordner beziehen. In diesem Fall kann z. B. :
Rechner rechts ‘c:\Programme\GTA San Andreas’ -> u:\
Rechner links ‘c:\Programme\GTA San Andreas’ -> v:\
verbunden werden.
Falls noch Änderungen am Quellcode vorgenommen werden müssen, ist es unter
Umständen nötig, MTA neu zu starten. Bei Änderungen in den Unterprojekten,
6
svn+ssh://csl.ira.uka.de/svn/driving-simulator-gta/mta patch
30
4. Arbeit mit GTA
deren Namen mit Server* beginnen, muss der MTA Server geschlossen werden, um
die verwendeten Dateien freizugeben. Bei den anderen Paketen reicht es, den Client
vorher zu beenden.
4.5.2
Implementierung der Kameraansicht
Da die LUA-Implementierung der Kameraansichten starken Limitierungen unterlag,
änderten wir unser Vorgehen komplett zu C++. Hier hatten wir die Möglichkeit,
direkt auf die Projektionsmatrizen zuzugreifen und hatten zusätzlich eine flüssigere
Darstellung.
Die erste Änderung besteht darin, dass wir für die Seitenansichten die Blickrichtung jeweils gedreht haben. Hierzu haben wir in der Datei ‘CClientCamera.cpp’ die
Verarbeitung der fixierten Kamera geändert. Je nachdem mit welchen Compilerparametern für die jeweiligen Rechner kompiliert wird, wird der Blickpunkt um 70°
nach rechts oder links angepasst. Dieser Winkel wurde gewählt, da die Ansichten im
Widescreenmodus diesen Blickwinkel haben.
Die zweite Änderung bewirkt, dass der Fahrer nicht mehr die ganze Zeit das Gefühl hat, einen Berg hinaufzufahren. Dies wird durch eine Positionsverlagerung des
Horizontes auf Kopfhöhe erreicht.
Abbildung 4.7: Auswirkung unseres Patches auf die Spielgrafik
In Direkt3D ist der Renderingprozess als Pipeline aufgebaut[17]. In dieser wird aus
einer dreidimensionalen Szene ein zweidimensionales Bild erstellt. Direct3D benutzt
dabei drei Transformationen, um 3D Koordinaten zu Pixelkoordinaten umzuwandeln. Die Transformationen sind Welt-Transformation, View-Transformation und
Projektions-Transformation. Diese sind durch Matrizen repräsentiert und werden
nacheinander auf die Koordinaten in der Form (x,y,z) angewandt.
Unsere Änderungen setzen nach der View-Transformation an, da hier das Koordinatensystem dem der Kamera entspricht (0,0,0 entspricht also dem Zentrum der
Kamera, die Blickrichtung ist entlang der z-Achse mit einer vertikalen y-Achse). So
können wir leicht Objekte, die sich weiter weg von der Kamera befinden - also einen
größeren z-Wert haben - nach unten verschieben.
Die Anpassungen fanden in der Funktion ‘StoreTransform’ in der Datei
‘CDirect3DData.cpp’ statt. Diese Datei gehört zu dem Projekt ‘Client - Core’. Diese Funktion wird von GTA aufgerufen, wenn Transformationsmatrizen gespeichert
werden, um sie an die Grafikkarte weiterzugeben.
4.5. Open-Source
31
Mittels einer Scherungsoperation
schoben:

 
x11 x12 x13 x14
1
x21 x22 x23 x24  0

 
x31 x32 x33 x34  · 0
x41 x42 x43 x44
0
wird der projizierte Bildausschnitt vertikal ver0
1
t
0
0
0
1
0
 
x11
0


0 x21
=
0 x31
1
x41
x12 + x13 ∗ t
x22 + x23 ∗ t
x32 + x33 ∗ t
x42 + x43 ∗ t
x13
x23
x33
x43

x14
x24 

x34 
x44
Der Parameter t gibt die Stärke der Scherung an. Wir wählten t=-0.1 da dies den
Horizont in Augenhöhe setzt.
Projektionskegel
y
y
z
Kamera
z
Kamera
Abbildung 4.8: Änderung des Projektionskegels
4.5.3
Joystick Support
In der von uns verwendeten SVN Revision 149 von MTA existierte bereits ein grundlegender Joystick Support, durch einen Bug in der Implementierung war es jedoch
nicht möglich, das G25 Lenkrad von Logitech zu verwenden. In der Implementierung
wurden nicht alle verfügbaren Achsen abgefragt, sondern nur die Achsen bis zur ersten nicht vorhandenen, da das Polling an der Lücke abbrach. Außerdem wurde nur
eine der beiden Slider abgefragt. Bei Slidern handelt es sich um alle Achsen, die nach
den ersten sechs Achsen (3 Richtungen + 3 Rotationen) kommen.
Nachdem die Fehler beseitigt waren, war es nötig, ein Mapping für das von uns
verwendete G25 Lenkrad zu erstellen. In dem Mapping werden den einzelnen Achsen die Funktionen und Wertebereiche zugeordnet. So wird z. B. ‘eJoyX’, was der
Lenkung entspricht, in beide Richtungen dem ‘eLeftStickX’ zugewiesen.
Durch die von uns durchgeführten Änderungen war eine analoge, d.h. flüssige und
sensibel einstellbare Steuerung des Fahrzeugs möglich.
Hinweis: In späteren Revisionen von MTA ist unser Patch nicht mehr notwendig
und es ist auch möglich, über die MTA Settings die Achsen und Knöpfe zu konfigurieren.
32
4. Arbeit mit GTA
5. Evaluierung
Um die Leistung unseres fertigen Fahrsimulators zu testen, entschieden wir uns
einen Fragebogen zu erstellen. Mit diesem wollen wir in der Lage sein, das von uns
modifizierte GTA, mit einem anderen System zu vergleichen. Als Referenzsystem
wählten wir das Spiel “Need for Speed: Underground (NfS)”. Um Vergleichbarkeit
zu gewährleisten wurden beide Systeme mit identischem Hardwareaufbau1 getestet.
NfS hatten wir zu ersten Tests bereits auf unserem Hauptrechner installiert und
Versuche in einzelnen Stadien des Aufbaus durchgeführt, um z. B. das Lenkrad zu
testen. Da es sich nur um die Demo des Spiels handelt, war nur ein Teil der Strecke
befahrbar.
Das Spiel unterscheidet sich trotz des gleichen Aufbaus grundlegend, da es nicht
alle vorhandenen Hardwarekomponenten verwenden kann. Mit NfS ist es so z. B.
nicht möglich mehr als eine Ansicht zu verwenden und die befahrbare Welt ist viel
kleiner. Dafür existiert eine bessere Lenkradunterstützung mit Force-Feedback. Auch
autonom agierender Verkehr ist vorhanden. Im Überblick gab es also die folgenden
zwei Versuche:
Versuch GTA
• 3 Ansichten (vorne, links und rechts)
• GTA Testszenario mit wenig Verkehr
• Geschwindigkeitsanzeige
Versuch NfS
• eine Ansicht
• NfS:Underground Nachtfahrt mit Verkehr
• ForceFeedback
1
Beschreibung des Hardwareaufbaus unter [18]
34
5. Evaluierung
Mit Hilfe des Fragebogens wollen wir feststellen, wo die Stärken und Schwächen unseres Systems liegen. Dazu ließen wir jeden Fahrer beide Systeme jeweils 7 Minuten
fahren und danach beurteilen. Die Hälfte der Probanden fuhr zuerst GTA, die andere
NfS, um eine Beeinflussung der Ergebnisse, z. B. durch Gewöhnung, auszugleichen.
Am Ende des Versuches bekamen die Probanden via Fragebogen folgende Fragen
gestellt:
35
Fragebogen 1 Dieser Fragebogen diente zur statistischen Erfassung und Klassifizierung des Probanden.
• Wie alt sind Sie?
• Ihr Geschlecht?
• Haben Sie Erfahrung mit Computerrennspielen?
• Haben Sie einen Führerschein?
• Seit wievielen Jahren haben Sie Ihren Führerschein?
• Wieviel fahren Sie durchschnittlich pro Monat?
• Fahren Sie hauptsächlich Ihnen bekannte Strecken?
• Fahren Sie mit Navigationsgerät?
• Fahren Sie überwiegend Autobahn?
• Wieviele verschiedene Autos sind Sie bereits längere Zeit (min. 3 Monate)
gefahren?
• Welchen Fahrzeugtyp (Kleinwagen, LKW etc.) fahren Sie zur Zeit
Fragebogen 2 Dieser Fragebogen diente dazu Meinungen der Probanden zu bekommen, ohne Beeinflussung durch gezielte Fragen des dritten Fragebogen.
• Was empfanden Sie als besonders realistisch/unrealistisch? Pro Versuch jeweils
zwei Freitexte.
• Was fehlt Ihrer Meinung nach zum Vergleich mit einem echten Auto? Freitext.
Fragebogen 3
• Wieviel trägt ... Ihrer Meinung nach zur Qualität eines Fahrsimulators bei?
Jeweils fünfstufige Skala von “gar nicht” bis “sehr viel”.
– Kraftrückmeldung des Lenkrads
– Bewegung der Sitzkiste
– Ansicht(Anzahl/Größe Blickfeld)
– Ansicht(Qualität/Auflösung)
– Fahrverhalten des Fahrzeugs
– Verkehr
– Umgebung in der Simulation
• Wie realistisch empfanden Sie ... in Versuch 1 bzw. 2? Pro Versuch jeweils
fünfstufige Skala von “gar nicht” bis “sehr viel”.
– Kraftrückmeldung des Lenkrads
36
5. Evaluierung
– Bewegung der Sitzkiste
– Ansicht (Anzahl/Größe Blickfeld)
– Ansicht (Qualität/Auflösung)
– Fahrverhalten des Fahrzeugs
– Verkehr
– Umgebung in der Simulation
• Wie realistisch fanden Sie die Sitzkiste? Fünfstufige Skala von “Videospiel” bis
“echtes Auto”.
• Ist Ihnen schlecht geworden? Pro Versuch jeweils fünfstufige Skala von “gar
nicht” bis “sehr stark”.
• Bewerten Sie die Versuche? Jeweils ein Freitext.
5.1
Ergebnis
Im Laufe der Evaluierung mussten 3 der 17 Versuche vorzeitig beendet werden,
da den Probanden schlecht wurde. Ein Proband musste sich sogar übergeben. Die
Simulator Sickness2 tritt also auch in unserem Aufbau auf.
Wir nahmen an, dass den Probanden in GTA grundsätzlich schlechter wird, als in
NFS. Die Gründe dafür vermuteten wir in der umfangreicheren Simulation durch
drei Ansichten und der unserer Meinung nach schlechteren Steuerung in GTA. Um
das zu überprüfen führten wir einen zweiseitig, gepaarten T-Test durch. Unser Signifikanzniveau legten wir auf α = 0, 05 fest. Das Ergebnis ergab p = 0.03656. Damit
ist das Ergebnis signifikant.
Die seitlichen Ansichten gaben den Probanden mehr Übersicht, das wurde vorwiegend positiv empfunden. Da allerdings der Sichtbereich dadurch komplett durch die
Projektion abgedeckt ist und der Proband nichts mehr von der “echten” Realität
sieht, könnte dies ein Grund für die erhöhte Übelkeit beim GTA-Versuch sein.
Ein weiterer Kritikpunkt beim GTA-Versuch ist das Fahr- und vor allem Lenkverhalten. Insbesondere ältere Menschen und Menschen ohne Computerrennspielerfahrung
hatten Probleme das Auto unter Kontrolle zu halten. Hier entdeckten wir eine Verzögerung der Lenkübertragung zur Software. Wir vermuten, dass entweder zu gut
interpoliert wird oder die Ansteuerung des Lenkrades nicht latenzfrei funktioniert.
Desweiteren bietet GTA keine dynamische Kraftrückmeldung des Lenkrades, die
Rückstellfeder hat also immer die gleiche Kraft unabhängig der aktuellen Geschwindigkeit.
Anhand der erstellten Daten vermuten wir, dass die Simulator Sickness mit dem
Alter und der Erfahrung bezüglich Computerrennspielen zusammenhängt. Wobei
Alter und Erfahrung aller Wahrscheinlichkeit nach korrelieren.
Einige Probanden fanden es störend, dass Elemente wie Kupplung und Schaltung
vorhanden sind, jedoch nicht genutzt werden.
Die Vibration des Sitzes via Bassshaker wurde - wenn Sie aktiv bemerkt wurde - als
realistisch empfunden.
2
Eine durch Täuschung der Sinnesorgane hervorgerufene Übelkeit.
5.1. Ergebnis
37
Abbildung 5.1: Alter der Probanden
Abbildung 5.2: Geschlecht der Probanden
Abbildung 5.3: Probanden mit Erfahrung in Computerrennspielen
38
5. Evaluierung
Abbildung 5.4: Die Probanden fahren
vorwiegend bekannte Strecken.
Abbildung 5.5: Probanden mit Führerschein
Abbildung 5.6: Die meisten Probanden fahren ohne Navigationsgerät.
Abbildung 5.7: Nur wenige Probanden fahren viel Autobahn.
5.1. Ergebnis
Abbildung 5.8: Seit wievielen Jahren haben die Probanden einen Führerschein
Abbildung 5.9: Durchschnittliche Fahrkilometer pro Monat
39
40
5. Evaluierung
Abbildung 5.10: Im Schnitt “kennen” die Probanden ca 3-4 Autos.
Abbildung 5.11: Die meisten Probanden fahren Kleinwagen bis Mittelklasse.
5.1. Ergebnis
41
Abbildung 5.12: GTA hat mit der dritten Ansicht überzeugt. Bei der Lenkung und dem Fahrverhalten hat NFS besser abgeschnitten.
42
5. Evaluierung
Abbildung 5.13: Die Sitzkiste wurde als überwiegend realistisch empfunden.
Abbildung 5.14: Bei GTA besteht erhöhte Simulatorsicknessgefahr.
6. Zusammenfassung und Ausblick
Nachdem wir bestehende System untersucht und analysiert haben, waren wir in
der Lage, selbst einen Fahrsimulator zu entwerfen. Diesen bauten wir mit Hilfe der
uns zur Verfügung stehenden Mitteln auf. Durch diese Arbeit entstand am CSL ein
funktionsfähiger Fahrsimulator, mit dem bereits Versuche durchgeführt werden.
Unter anderem stehen folgende Funktionalitäten zur Verfügung:
• Softwareumgebung auf Basis von GTA
– Grafikausgabe einer realistischen Umgebung
– 5.1 Soundausgabe
– große virtuelle Welt
• Ansteuerung über Spielelenkrad Logitech G25
• Drei Ansichten über Netzwerk
• Szenarioskriptbarkeit
Es gibt aber immer noch zahlreiche Verbesserungsmöglichkeiten:
• Da die Steuerung des Fahrzeugs einer der Hauptkritikpunkte der Probanden
war, sollte versucht werden diese zu verbessern. Wir vermuten, dass die Lenkung zu träge reagiert und deshalb schwer zu handhaben ist.
• Zusätzlich zu einer schneller reagierenden Lenkung wäre Force-Feedback wünschenswert. Dies würde eine weitere Qualitätsverbesserung darstellen.
• Es sollte auch ermöglicht werden, die 6-Gang-Schaltung und die Kupplung in
der Software zu verwenden. Beide Elemente sind momentan zwar mit unserem
Simulator verbunden und der Status kann abgefragt werden, jedoch gibt es in
unserer Software noch keine Möglichkeit, diese Informationen zu verwenden.
44
6. Zusammenfassung und Ausblick
• Der in der Sitzkiste eingebaute Tachometer könnte über eine Schnittstelle,
z. B. USB, als Hardware in die Simulationsumgebung eingebunden werden.
Dies würde gegenüber der Bildschirmeinblendung den Realismus erhöhen, da
die Geschwindigkeitsanzeige wie in einem echten Auto wäre.
• Ein wichtiger Punkt ist die Einbindung von Verkehr. Es gab bereits erste
Versuche, aufgezeichneten Verkehr zu verwenden. Dieser nimmt jedoch noch
keine Rücksicht auf andere Verkehrsteilnehmer. Ein autonomer Verkehr ist
anzustreben.
• Ein grafischer Editor könnte die Erstellung von Szenarien stark vereinfachen.
Es könnte z. B. innerhalb der Software zugänglich sein und die Positionierung
und Identifizierung von Objekten vereinfachen und Skripte automatisch erstellen.
Literaturverzeichnis
[1] Autosim. http://www.autosim.no/.
[2] Fahrsimulationssoftware
Silab.
ProdukteDienstleistungen/SILAB/index.php.de.
http://www.wivw.de/
[3] GTA III - Grand Theft Auto 3.
grandtheftauto3/.
http://www.rockstargames.com/
[4] GTA San Andreas: System Requirements.
sanandreas/pc/.
http://www.rockstargames.com/
[5] Instructions on how to compile MTA yourself.
multitheftauto/wiki/HowToBuild.
http://code.google.com/p/
[6] Known Issues: Does MTASA:DM work with v1.01 or v2.00 of GTA San Andreas. http://development.mtasa.com/index.php?title=Known Issues - FAQ#
Does MTASA:DM work with v1.01 or v2.00 of GTA San Andreas.3F.
[7] Known Issues: Gamepad Support. http://development.mtasa.com/index.php?
title=Known Issues - FAQ#Gamepad support.
[8] MTA - Multi Theft Auto. http://www.mtasa.com.
[9] MTASA: Wine compatibility. http://mtasa.com/71.html.
[10] Northeastern University Virtual Environment Laboratory. http://www.coe.neu.
edu/Research/velab/index.php.
[11] Oktal: SCANeR™Screenshot. http://www.oktal.fr/index.php?Page=AutoOffer.
[12] SCANeR™. http://www.scanersimulation.com/.
[13] Silab: Screenshots. http://www.wivw.de/ProdukteDienstleistungen/SILAB/
screenshots.php.de.
[14] STISIM. http://www.stisimdrive.com/.
[15] VDrift - Open Source Racing Simulator. http://www.vdrift.net.
[16] Wikipedia: GTA San Andreas - Hot Coffee. http://de.wikipedia.org/wiki/GTA
San Andreas#Hot Coffee.
[17] Möller, Tomas und Eric Haines: Real-time rendering. Peters, 2. ed. Auflage, 2002.
46
Literaturverzeichnis
[18] Reinhold, Frieder: Studienarbeit: Aufbau eines Fahrsimulators - Schwerpunkt Hardware. Universität Karlsruhe, 2009.