Planung und Aufbau eines realistischen Fahrsimulators fur¨ die Untersuchung von kognitiven Dialogsystemen - Schwerpunkt Software

Studienarbeit am Cognitive Systems Lab Prof. Dr.-Ing. Tanja Schultz Fakult¨at fur¨ Informatik Universit¨at Karlsruhe (TH)

von cand. inform. Rikard Oxler¨

Betreuer: Prof. Dr.-Ing. Tanja Schultz Dipl.-Inform. Felix Putze

Tag der Anmeldung: 28. Dezember 2008 Tag der Abgabe: 28. April 2009

Ich erkl¨are hiermit, dass ich die vorliegende Arbeit selbst¨andig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.

Karlsruhe, den 28. April 2009

Zusammenfassung

Die vorliegende Studienarbeit besch¨aftigt sich mit dem Aufbau eines Fahrsimulators zu Forschungszwecken. Der Schwerpunkt liegt dabei bei der dafur¨ notwendigen Soft- ware. Das Dokument beschreibt, welche Anforderungen an solch ein System gestellt werden, welche bisherigen L¨osungsans¨atze es gibt und wie unsere L¨osung dafur¨ aus- sieht. Mit Hilfe dieser Arbeit soll es sp¨ater m¨oglich sein, das System zu warten oder Erweiterungen vorzunehmen.

Inhaltsverzeichnis

1 Einleitung 1 1.1 Zielsetzung der Arbeit ...... 1 1.2 Gliederung der Arbeit ...... 2

2 Grundlagen 3 2.1 Hardware ...... 3 2.1.1 Projektion ...... 3 2.1.2 Sound ...... 4 2.1.3 Eingabeger¨ate...... 4 2.1.4 Kraftruckmeldung¨ ...... 4 2.2 Software...... 4 2.2.1 Was muss ein Simulationssystem fur¨ uns leisten ...... 4 2.2.1.1 Szenarien ...... 5 2.2.1.2 Verkehr ...... 5 2.2.1.3 Fahrverhalten ...... 5 2.2.2 M¨ogliche Szenarien/Versuche ...... 5

3 Analyse bestehender Fahrsimulatoren 7 3.1 Virtual Environments Laboratory ...... 7 3.2 VDrift ...... 7 3.3 Grand Theft Auto ...... 8 3.3.1 Multi Theft Auto ...... 9 3.4 Silab...... 9 3.5 AutoSim...... 11 3.6 STISIM ...... 12 3.7 SCANeR™ ...... 13 3.8 Zusammenfassung ...... 13

4 Arbeit mit GTA 17 4.1 Aufbau der Infrastruktur ...... 17 4.2 Installation ...... 18 4.2.1 Lauff¨ahiges Windows unter X Rechnern ...... 18 4.2.2 GTA installieren ...... 18 4.2.3 Downgrade ...... 18 4.2.4 Installation MTA ...... 19 4.2.5 Installation unseres Versuchsszenarios ...... 19 4.2.6 Umgebung starten (mehrere Rechner / Server) ...... 19 4.3 Szenario ...... 22 4.3.1 Szenarioerstellung ...... 23 viii Inhaltsverzeichnis

4.3.1.1 Client ...... 23 4.3.1.2 Server ...... 23 4.3.2 Szenarioauswertung ...... 24 4.4 PreOpen-Source ...... 25 4.4.1 Integration Lenkrad ...... 25 4.4.2 Mehrere Ansichten integrieren ...... 25 4.5 Open-Source...... 27 4.5.1 Installation SourceCode ...... 27 4.5.1.1 Installation der Entwicklungsumgebung ...... 27 4.5.1.2 SVN Source Code ...... 28 4.5.1.3 Patch ...... 29 4.5.1.4 Compile, Deploy and Run ...... 29 4.5.2 Implementierung der Kameraansicht ...... 30 4.5.3 Joystick Support ...... 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 Streckenfuhrung¨ allein nicht aus. Die Eingabe des Zieles und jede weitere Kommunikation mit dem Ger¨at erfordert bisher eine hohe Konzentration des Fahrers, so dass sie nicht w¨ahrend der Fahrt erfolgen darf. Ansonsten k¨onnte es zu gef¨ahrlichen Beeintr¨achtigungen kommen. Deshalb sollte sich das Ger¨at an den Benutzer anpassen. Fur¨ die L¨osung dieses Problems bietet sich ein adaptives Dialogsystem an. Der Fah- rer 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¨onnen. Der Benutzer darf hier nicht abgelenkt werden, da er somit zu einer Gefahr fur¨ sich und Andere auf der Straße werden k¨onnte. Das Gleiche gilt naturlich¨ auch, wenn das System einschl¨afernd wirkt und der Fahrer dadurch zu sp¨at auf Ereignisse im Straßenverkehr reagiert. Um eine Evaluierung solcher adaptiver Dialogsystem zu erm¨oglichen sind Fahrsimu- latoren vonn¨oten. Nur mit ihnen kann garantiert werden, dass niemand verletzt wird oder sogar Schlimmeres passiert. Hier k¨onnen in einer sicheren Umgebung alle Funk- tionen erprobt und verbessert werden. Die Versuche sind beliebig oft reproduzier- bar und alle auftretenden Parameter k¨onnen aufgezeichnet und analysiert werden. Außerdem ist sichergestellt, dass die fur¨ die jeweilige Untersuchung notwendigen Situationen jederzeit erzeugt und kontrolliert werden k¨onnen. Erst wenn die Sicherheit des Systems gew¨ahrleistet ist, k¨onnen 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 durchgefuhrt¨ werden. Diese Arbeit besch¨aftigt sich prim¨ar mit der hierfur¨ erforderlichen Software. Der Aufbau der Hardware wird in Frieder Reinholds Studienarbeit n¨aher beschrieben [18]. 2 1. Einleitung

Zus¨atzlich zu dem von uns fertiggestellten System soll es mit dieser Arbeit auch Anderen erm¨oglicht werden, den Fahrsimulator nachzubilden oder zu warten.

1.2 Gliederung der Arbeit

Die folgenden Kapitel besch¨aftigen sich mit der Software fur¨ einen Fahrsimulator. Angefangen bei der Suche nach bereits erh¨altlichen Systemen bis hin zur Implemen- tierung und Evaluierung des von uns entwickelten Systems. Das Kapitel “Grundlagen” befasst sich damit, was Fahrsimulatoren alles leisten mus-¨ sen, um unseren Anforderungen Genuge¨ zu tun und sich somit fur¨ unsere Versuche zu eignen. Im Kapitel“Analyse bestehender Fahrsimulatoren”werden verschiedene existierende Fahrsimulatoren begutachtet, mit welchen wir uns w¨ahrend unserer Arbeit eingehend besch¨aftigt haben. Das Kapitel “Arbeit mit GTA” besch¨aftigt sich mit dem letztendlich von uns ver- wendeten System GTA (Grand Theft Auto). Hier wird erkl¨art, wie sich die Software installieren und verwenden l¨asst. In der “Evaluierung” beschreiben wir M¨oglichkeiten, um den von uns aufgebauten Fahrsimulator auf seine Leistungsf¨ahigkeit hin zu testen. Im letzten Teil wird eine Zusammenfassung unserer Arbeit und ein Ausblick auf zukunftige¨ Projekte gegeben. 2. Grundlagen

Immersion bezeichnet den Grad des Eintauchens in eine virtuelle Realit¨at. Unser Ziel war es eine m¨oglichst hohe Immersion zu erm¨oglichen, um z. B. Effekte wie erh¨ohte kognitive Auslastung unter realistischen Bedingungen untersuchen zu k¨onnen. Doch welche Faktoren spielen dafur¨ uberhaupt¨ eine Rolle und auf was ist dabei zu achten?

Nachfolgend wird beschrieben welche Kriterien fur¨ die Wahl der Hard- und Software wichtig waren.

2.1 Hardware

Um einen Fahrsimulator betreiben zu k¨onnen, ist als erstes eine entsprechende Hard- ware erforderlich. Diese fungiert als Nahtstelle zwischen dem Mensch und der si- mulierten Welt. Außerdem kann die Software nicht unabh¨angig von der Hardware existieren. Die Hardware muss naturlich¨ die Anforderungen (z. B. Performance) der Software erfullen¨ k¨onnen, damit diese voll ausgenutzt werden kann. Zus¨atzlich muss sie auch unsere Anforderungen an den Realismus erfullen.¨ Ein einfacher Desktop- Rechner mit einem Bildschirm, Tastatur und Maus reicht nicht aus, um ein reales Fahrgefuhl¨ 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¨ankten Ansicht, gibt es prinzipiell zwei M¨oglichkeiten. Falls die Simulatorsoftware es unterstutzt,¨ k¨onnen an einen Rechner mehrere Anzeigen angeschlossen werden. Die m¨ogliche Anzahl variiert mit den verwendeten Grafikkarten. Da die meisten Simulatoren jedoch wegen Geschwindigkeitseinbußen darauf verzichten, mussen¨ mehrere Rechner mit je einer Ansicht in einem Netzwerk verbunden werden. 4 2. Grundlagen

2.1.2 Sound Der heutzutage in der Standardkonfiguration erh¨altliche 5.1 Sound reicht fur¨ unsere Zwecke. Dabei erzeugen funf¨ im Raum verteilte Boxen den mit der Soundkarte gene- rierten Ton und sorgen so fur¨ einen Raumklang. Da tiefe T¨one schwer zu lokalisieren sind, genugt¨ ein einzelner Subwoofer.

2.1.3 Eingabeger¨ate Als Eingabeger¨at 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, fur¨ den Spielebereich entwickelte, Ger¨ate zur Auswahl. Von einem Lenkrad, bis hin zu drei Pedalen und einer Sechs-Gang-Schaltung.

2.1.4 Kraftruckmeldung¨ Fur¨ die Kraftruckmeldung¨ gibt es verschiedene Ans¨atze. Zum einen kann ein ein- faches Force-Feedback-Lenkrad verwendet werden, dass unter Windows uber¨ die DirectInput-Schnittstelle von Microsofts DirectX angesprochen wird. Es stehen je- doch auch ausgefeiltere Aufbauten wie Bewegungsplattformen zur Verfugung.¨ Je- doch kommen diese fur¨ uns aus Ressourcen- und Platzmangel nicht in Frage. Eine einfache aber effiziente L¨osung um die Motor- und Fahrbahnvirbrationen zu simulie- ren, ist es, den vorhandenen Sound abzugreifen und die tiefen Frequenzen mit einem Bassshaker wiederzugeben. Ein Bassshaker erzeugt, als Basslautsprecher ohne Mem- bran, die gewunschten¨ Vibrationen.

2.2 Software Zus¨atzlich zum Hardwareaufbau wird eine Software ben¨otigt, die dem Aufbau“Leben einhaucht”. Diese muss uber¨ Unterstutzung¨ fur¨ die Hardwarekomponenten verfugen.¨ Beispielsweise l¨asst sich das von uns gekaufte Logitech G25 Lenkrad noch nicht in vollem Funktionsumfang in allen Systemen nutzen. Die Rahmenbedingungen fur¨ unseren Simulator waren haupts¨achlich durch den Rea- lismus gesetzt, damit die erzielten Erkenntnisse auch auf den echten Straßenverkehr anwendbar sind. Aber auch die Kosten und die verfugbare¨ Zeit waren sehr wichtige Faktoren, die zu beachten und einzuhalten waren.

2.2.1 Was muss ein Simulationssystem fur¨ uns leisten Ein Simulator muss naturlich¨ so realistisch wie m¨oglich erscheinen, da seine Haupt- aufgabe darin besteht, ein Modell der Realit¨at zu sein. Dieser Realismus ist deswegen wichtig, damit die Ergebnisse auch auf die Realit¨at anwendbar sind. Versuche soll- ten wiederholbar sein, weswegen auch eine Skriptbarkeit erforderlich ist, um gleiche Bedingungen fur¨ die einzelnen Probanden zu erm¨oglichen. Ansonsten sind die Er- gebnisse schwer miteinander vergleichbar. Es muss m¨oglich sein, die Simulationsdurchl¨aufe zu protokollieren um sie sp¨ater auszuwerten. Auch erforderlich fur¨ diese Auswertung sind Sensordaten, wie z. B. die Auslenkung des Lenkrads, die synchron untereinander und gegebenenfalls mit externen Sensoren aufgezeichnet werden mussen.¨ 2.2. Software 5

2.2.1.1 Szenarien Die virtuelle Umwelt sollte abwechslungsreich sein, um Versuche zu unterschiedli- chen Gegebenheiten durchfuhren¨ zu k¨onnen. Eine lange monotone Landstraßenfahrt erfordert andere F¨ahigkeiten vom Fahrer als eine “Stop and go” Stadtfahrt. Auch ein direkter Ubergang¨ zwischen diesen Szenarien, ohne einen neuen Versuchslauf zu starten, ist wunschenswert.¨ Vorteilhaft ist, wenn bereits viele gebr¨auchliche Szenarien mit der Software mitge- liefert werden. Dadurch entf¨allt eine wom¨oglich langwierige Einarbeitungszeit. Noch nicht vorhandene Szenarien sollten sich ohne zu großen Aufwand erstellen las- sen. Es ist unvorteilhaft, wenn dafur¨ 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. Fur¨ den Probanden sollte dieser autonom erscheinen, um die Immersion nicht zu ver- schlechtern. 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 kunst-¨ liche Intelligenz (KI) die anderen Fahrzeuge steuern oder diese mussen¨ mit Hilfe von Ereignissen uber¨ Skripte gelenkt werden. Der Vorteil von Skripten ist die Wiederhol- barkeit der Versuche, der Nachteil der h¨ohere Aufwand zur Erstellung. Mit Skripten k¨onnen nur sehr schwer alle auftretenden Situationen abgedeckt werden, dafur¨ je- doch auch bestimmte Situationen provoziert werden.

2.2.1.3 Fahrverhalten Die Fahrphysik sollte realistisch sein, um sich wie bei einem echten Auto anzu- fuhlen.¨ Von dieser ist unter anderem die Geschwindigkeitswahrnehmung betroffen. Wenn das Fahrzeug dem Probanden zu langsam vorkommt und er dadurch st¨arker beschleunigt, wird das Risiko eines Unfalls erh¨oht. Dies ist zwar ungef¨ahrlich, jedoch werden die Versuche im Allgemeinen dann abgebrochen. Ein hoher Realismus erleichtert den Probanden die Auswirkungen ihrer Taten besser einsch¨atzen zu k¨onnen, da sie so handeln k¨onnen wie sie es aus der echten Welt gewohnt sind. Wie sp¨ater in der Evaluation (siehe Kapitel 5) zu sehen sein wird, ist das Fahrver- halten ein nicht zu untersch¨atzender Faktor.

2.2.2 M¨ogliche Szenarien/Versuche Zu Beginn der Arbeit war es noch unklar, welche Software wir fur¨ unsere Versuche verwenden wurden.¨ Deshalb suchten wir zuerst generelle Szenarien und Versuche, mit denen wir, unabh¨angig von der Simulatorsoftware, das Dialogsystem evaluieren konnten. Damit unser System fur¨ sp¨ater stattfindende Experimente vorbereitet ist, uberlegten¨ wir uns einige Versuche, die unter Umst¨anden wirklich durchgefuhrt¨ werden wurden.¨ 6 2. Grundlagen

Hierdurch wollten wir herausfinden, ob unser Fahrsimulator unseren Anforderungen entsprach, wir also in der Lage w¨aren alle Experimente durchzufuhren.¨ Ziel der Versuche war es, herauszufinden, wann der Fahrer durch Ablenkungen oder St¨orungen sein Fahrverhalten ¨andert. Zudem wollten wir wissen, ob diese Anderun-¨ gen auch durch denkerische Leistungen stattfinden. Als m¨ogliche 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¨aren: “Links herum w¨are 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¨alfte der Karten sind rot umrandet, die anderen grun.¨ Die grun¨ umrandeten haben eine gut erkennbare Nummer (weiß in schwarzem Kreis) - diese muss sich der Proband mer- ken. Kommt eine rotumrandete Karte, so muss er die Nummer der passenden grunen¨ Karte sagen. Die Zuordnung erfolgt dabei durch das Spielkartenmotiv (z. B. Herz Da- me). 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¨oglichst schnell befolgt werden sollen. Das System schreit z.B. ¨ofters “Halt”. Gew¨ohnt 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¨ahrt, soll den Fahrer irri- tieren. 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¨otig, sich einen Uberblick¨ uber¨ bestehenden L¨o- sungen fur¨ 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 wurden.¨ Es mussten Kosten und Nutzen abgew¨agt wer- den. Wir entschieden uns, einen genaueren Blick auf die nachfolgenden Systeme zu werfen, da sie das meiste Potenzial versprachen. Einen Uberblick¨ uber¨ die Vor- und Nachteile der Systeme bietet Tabelle 3.2.

3.1 Virtual Environments Laboratory Der, von der Northeastern University entwickelte, Fahrsimulator ‘Virtual Environ- ments Laboratory’ [10] schied bei unserer Suche nach einem fur¨ uns geeigneten Sy- stem ziemlich fruh¨ aus. Die Grafik war nicht auf dem aktuellen Stand der Technik und dadurch auch nicht wirklich realistisch. Dieser Realismus ist fur¨ uns jedoch von hohem Interesse. Der Vorteil dieser Software w¨are es, dass sie mit Quellcode geliefert werden wurde,¨ und wir so alles nach unseren eigenen Bedurfnissen¨ anpassen k¨onnten. Auch die Entwicklung an einer Universit¨at 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¨achlich Rennstrecken und Rennfahrzeuge. Die Fahrphysik orien- tiert sich an echten Autos und fuhlt¨ 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 Szenariener- stellung 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 verfugt¨ uber¨ einen Netzwerkmodus mit dem z.B. mehrere Ansichten realisiert werden k¨onnen. Eine Lenkradunterstutzung¨ fur¨ 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¨ateren Zeitpunkt wieder betrach- tet und analysiert werden kann. Der Quellcode ist gut verst¨andlich, da er ordentlich kommentiert und ubersichtlich¨ strukturiert ist. Wie bei den meisten offenen Systemen hat man die M¨oglichkeit ko- stenlosen Support von anderen Entwicklern uber¨ 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¨altliches 3D Spiel, das in seiner ursprunglichen¨ Version 2001 erschienen ist. Bei den beiden Vorg¨angern han- delte es sich noch um 2D Spiele. 2002 wurde die erste Erweiterung GTA: Vice City ver¨offentlicht. Wir betrachten hier GTA: San Andreas, das seit 2004 erh¨altlich ist. Es beinhaltet neue Funktionen, wie z.B. dynamische Echtzeitschatten oder Wetter- ph¨anomeme (Regen, Nebel, Hitzeflimmern) und eine erh¨ohte Sichtweite. GTA:SA zeichnet sich vor allem durch eine 36 km2 große virtuelle Welt aus, die den amerikanischen St¨adten Los Angeles, San Francisco und Las Vegas nachempfun- den ist. Es existieren ca. 200 verschiedene Fahrzeuge, neben Autos auch Fahrr¨ader, Hovercrafts oder Helikopter. 3.4. Silab 9

3.3.1 Multi Theft Auto Multi Theft Auto (MTA) [8] ist eine Modifikation (Mod) fur¨ GTA. Ursprunglich¨ als Experiment entstanden, erweitert es das Spiel um einen Mehrspielermodus, w¨ahrend das Original nur fur¨ den Einzelspielerbetrieb vorgesehen war. Mit diesem Mehrspie- lermodus ist es m¨oglich, mehrere Ansichten zu integrieren. Im Gegensatz zu ande- ren verfugbaren¨ 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¨oglich, eigene Funktionalit¨at in ein anson- sten geschlossenes System einzubauen. MTA verfugt¨ uber¨ ein Google Code Projekt1, woruber¨ auf den Quellcode und weitere Informationen zugegriffen werden kann. MTA implementiert zus¨atzlich die Skriptsprache LUA, mit der es leicht m¨oglich 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¨achtig, aber auch leicht zu erlernen. Informationen zu LUA sind auf der offiziellen Homepage zu finden2. Die Skripte mussen¨ nicht kompiliert werden und ubertragen¨ sich bei einer Verbin- dung auf den Server automatisch auf die Clients, was eine einfache Entwicklung f¨ordert.

3.4 Silab Silab [2] ist eine kommerzielle Fahrsimulatorsoftware der Firma WIVW, einer Aus- grundung¨ aus der Universit¨at Wurzburg.¨ Das Produkt ist modular aufgebaut. Somit ist es einfach, zu einem sp¨ateren Zeit- punkt neue Funktionalit¨aten durch Pakete hinzuzufugen.¨ Es stehen ca. ein Dutzend Pakete zur Verfugung,¨ von denen sich einige gegenseitig ausschließen, einschließen oder voraussetzen. Alle auftretenden Parameter, wie die Bedieneingaben des Fahrers oder Informatio- nen uber¨ andere Verkehrsteilnehmer, k¨onnen synchronisiert aufgezeichnet werden, um sie sp¨ater fur¨ die Auswertung zu verwenden. Es ist auch m¨oglich eine Wie- derholung eines Versuchs sp¨ater anzuschauen oder ein Video mit diesen Daten zu generieren. Die Simulation verfugt¨ uber¨ mehr als 20 verschiedene Fahrzeugmodelle, welche zu- s¨atzlich mit verschiedenen Texturen belegt werden k¨onnen. Fußg¨anger k¨onnen mit dem entsprechenden Modul auch eingebunden werden. Die Grafikausgabe unterstutzt¨ beliebig viele Bildkan¨ale. Licht, Schatten und Refle- xionen werden realistisch dargestellt. Auch Wetterph¨anomene wie Nebel und Regen werden simuliert. Das System verfugt¨ uber¨ den besten, der von uns betrachteten, Streckeneditor. Bei diesem muss nicht, wie bei den meisten anderen, zuerst die 3D-Repr¨asentation des Szenarios erstellt werden, sondern die Welt wird aus Streckendefinition erstellt. Man muss also nur festlegen, wo sich die Straßen, Kreuzungen, H¨auser etc. befinden, und

1http://code.google.com/p/multitheftauto/ 2http://www.lua.org/ 10 3. Analyse bestehender Fahrsimulatoren

Name des Pakets Funktion Grundpaket Enth¨alt das Software-Framework an sich, eine einfache Fahrdyna- mik, Datenbasis, Verkehrssimulation, einfache Soundsimulation so- wie eine Demostrecke bestehend aus einer kleinen Stadt, Uberland-¨ strecke und einem Autobahnabschnitt. Daneben sind allgemein ver- wendbare DPUs enthalten aus den Bereichen - Signalverarbeitung (Filter, Signalgeneratoren usw.) - logische Operationen (Vergleiche, logische Gatter) - Datenaufzeichnung - Kommunikation uber¨ UDP und TCP/IP Editierbarkeit Course Mit diesem Paket k¨onnen Sie Landstraßen- und Autobahnszenari- en selbst entwerfen. Dies beinhaltet die freie Gestaltung von Lage- und H¨ohenplan, Querschnittsprofil, Beschilderung, Straßenmarkie- rungen, umgebende Landschaft und Verhalten der anderen Fahrzeu- ge. Einschr¨ankung: Der Querschnitt entlang einer Straße darf sich nicht ¨andern und es gibt keine Abzweigungen. Eine Autobahnauf- fahrt und -abfahrt sowie eine T- und X-Kreuzung fur¨ Landstraßen sind enthalten. Editierbarkeit Area Erlaubt die Gestaltung komplexer Straßengeometrien (Autobahnauf- und -abfahrten, Kreuzungen, Querschnitts- uberg¨ ¨ange und Stadtteile). Dies beinhaltet den Entwurf von Straßengeometrie, Markierungen, Beschilderung, Ampeln, grafi- sche Ausgestaltung und das Verhalten anderer Fahrzeuge. MOV Simulation von Fußg¨angern Entwicklerpaket DPU Erlaubt die Programmierung eigener Softwarekomponenten fur¨ SI- LAB in C++. Entwicklerpaket MAT- Wie ‘Entwicklerpaket DPU’, nur dass die Softwarekomponenten in LAB/SIMULINK MATLAB/SIMULINK entwickelt werden und mit dem Realtime- Workshop in eine SILAB-DPU kompiliert werden. Entwicklerpaket ODB API, mit der effiziente Abfragen von Objekten der simulierten Welt gemacht werden k¨onnen. Entwicklerpaket CAN API, mit der sehr einfach CAN-bus basierte Hardwarekomponenten in die Simulation eingebunden werden k¨onnen. Erweiterte Soundsimula- Realistische Simulation von Motor-, Roll- und Windger¨auschen ei- tion nes 5er BMWs. Fahrdynamik mstVeda Fahrdynamiksimulation eines BMW520i. Fahrdynamik CarSim Integration der Fahrdynamik aus CarSim. Fahrdynamik IPG Car- Integration der Fahrdynamik aus IPG CarMaker. Maker HMI Paket, mit dem sehr einfach HMIs (z.B. Anzeigen und Bedienkom- ponenten von Fahrerassistenzsystemen oder Kombi-Displays be- stimmter Fahrzeugtypen) simuliert werden k¨onnen. Generierung digitaler Die Anzeige eines Bildgenerators wird mit frei w¨ahlbarer Kamera- Videos perspektive als digitales Video abgespeichert. Die Kameraperspek- tive sowie das Starten und Beenden der Aufzeichnung kann dabei abh¨angig vom Szenario erfolgen.

Tabelle 3.1: Verfugbare¨ Silab-Pakete 3.5. AutoSim 11 der Editor generiert daraus die Strecke. Auch Events k¨onnen hier leicht definiert werden. Es steht auch eine C++ API und eine Matlab/Simulink Target zur Verfugung,¨ mit dem die Silab-Software erweitert werden kann. Die Software Komponenten bestehen aus sogenannten DPUs (data processing units). Sie verfugen¨ uber¨ Ein- und Ausg¨ange, uber¨ die sie miteinander verschaltet werden. So verfugt¨ z. B. die DPU ‘Fahrdynamik’ uber¨ Eing¨ange von der Steuerung und der Datenbasis sowie uber¨ Ausg¨ange, ebenfalls fur¨ die Datenbasis und die Visualisierung. So kann z. B. die Steuerung leicht durch eine andere ersetzt werden. Die DPUs k¨onnen zur Lastverteilung auf verschiedenen Rechnern ausgefuhrt¨ werden. Die Kommunikation findet uber¨ Netzwerk statt. Hardware kann uber¨ CAN, TCP/IP, UDP, serielle oder parallele Kommunikation angesprochen werden. Da kein Zugriff auf den Quellcode besteht, kann nicht alles von uns ge¨andert werden. Die Grafikqualit¨at 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 Simulationssoft- ware herstellt, entwickelt und vermarktet. Ein im Einsatz befindlicher Fahrsimulator wurde uns von einem der Entwickler per- s¨onlich 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¨andig ausgereift war. Ein gravierender Fehler ¨außerte sich z. B. in einem, von der Strecke abhebenden, computergesteuerten Auto.

Die Szenarienerstellung ist auch sehr aufw¨andig und die dafur¨ ben¨otigte Zeit wurde vom Entwickler mit mehreren Monaten angegeben. Fur¨ neue Strecken muss zuerst eine 3D-Repr¨asentation 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¨aten einsetzt.

Verglichen mit den meisten anderen Systemen war die Grafik schlecht. Die Aufl¨osung war niedrig und auch die Texturen ließen zu wunschen¨ ubrig.¨ Außerdem war sie fest auf drei Ansichten ausgelegt, eine Anderung¨ w¨are mit unverh¨altnism¨aßig hohem Aufwand verbunden.

Auch in anderen Bereichen w¨are viel Nacharbeit n¨otig. So hat z. B. der von uns besuchte Kunde den Sound und den Verkehr selbst neu implementiert, was nicht fur¨ die Qualit¨at der mitgelieferten Komponenten spricht.

Fur¨ die Software gibt es nur einen einzigen Ansprechpartner, wodurch es bei hoher Auslastung zu Verz¨ogerungen kommen kann. 3.7. SCANeR™ 13

3.7 SCANeR™ Bei der Software SCANeR™[12] handelt es sich ebenfalls um ein kommerzielles Pro- dukt. Es wird von der franz¨osischen Firma Oktal entwickelt und vertrieben. Wir konnten uns bei der ‘Vehicle Dynamics Expo’ in Stuttgart, bei der auch Oktal ver- treten war, pers¨onlich 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 fur¨ Univer- sit¨aten, auch der teuerste. Dieses System hatte die beste Grafikausgabe, die wir gesehen haben. Eine hohe Aufl¨osung, gute Texturen, dynamische Schatten und andere Effekte trugen zu einem realistischen Eindruck bei. Auch die Skriptingm¨oglichkeiten schienen ausgereifter als bei der Konkurrenz. Es bot auch als einziges der Fahrsimulatoren Autoanh¨anger oder am Auto befestigte Gegenst¨ande, wie z. B. ein Surfboard, an. Das System ist ¨ahnlich der anderen kommerziellen Simulatoren in Module/Pakete unterteilt.

Abbildung 3.4: Screenshot aus SCANeR™[11]

3.8 Zusammenfassung

Am Ende entschieden wir uns dafur,¨ ‘Grand Theft Auto: San Andreas’ mit der Modifikation ‘Multi Theft Auto’ zu verwenden. Hier boten sich fur¨ uns die meisten Vorteile zu einem vernunftigen¨ Preis. Eine Zusammenfassung der Vor- und Nachteile bietet Tabelle 3.2. 14 3. Analyse bestehender Fahrsimulatoren

GTA verfugt¨ uber¨ den gr¨oßten Streckenumfang mit der besten Qualit¨at. Die Grafik kann mit den dedizierten Fahrsimulatoren mithalten. Durch MTA steht eine gute Erweiterbarkeit und Skriptbarkeit zur Verfugung.¨ Mit dem Mod ist es fur¨ uns außerdem m¨oglich mehrere Ansichten zu verwenden. 3.8. Zusammenfassung 15 ™ 3+ 3+ 3 3+ b 1 Tabelle 3.2: Vergleich der Systeme a - ++- ++ --- + -- + - +++ ++ ---- + +++ 00 00 ++ +++ ++ ++ + + ++ ++ 0 + + +++ - +++ + + + ++ 0 + ++ +++ + ++ ++ + ++ - ++ + ++ -/+ ++ - + - ++ + - ++ - - N/A ++ +++ ++N/A + 1 + +++ Virtual Env Lab VDrift GTA/MTA Silab Autosim STISIM SCANeR at ¨ Preis Sound Grafik Editor Verkehr ¨ utzung G25 SourceCode Anzahl Views Erweiterbarkeit erweiterbar erweiterbar Multiplayer b a Strecken Umfang Strecken Qualit Unterst 16 3. Analyse bestehender Fahrsimulatoren 4. Arbeit mit GTA

Dieses Kapitel besch¨aftigt sich mit der, von uns zur Verwendung ausgesuchten, Soft- ware 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¨ahigkeit von MTA zuruck.¨ Dabei ist fur¨ 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¨atzlichen Beobachtern. Je nach verfugbaren¨ Ressourcen kann der Server zus¨atzlich auf einem der Client- Rechner laufen, oder aber auf einem dedizierten System. Das Verwenden eines dedi- zierten Rechners erlaubt es auf einfachem Wege, w¨ahrend der Versuche Befehle uber¨ die Konsole auszufuhren.¨ L¨auft die Konsole stattdessen auf dem selben Rechner wie der Client, muss MTA geschlossen werden, um Zugriff zu erhalten. 18 4. Arbeit mit GTA

4.2 Installation

Um GTA verwenden zu k¨onnen, ist es zuerst notwendig, alle ben¨otigten Kompo- nenten 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¨ahiges Windows unter X Rechnern

Laut den Systemanforderungen [4] l¨auft 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¨ater eingegliederten, Computer be- reits Windows XP installiert war, entschieden wir uns aus Konsistenzgrunden¨ die weiteren Rechner auch damit auszustatten. Sollte nur eine Linux-Umgebung zur Verfugung¨ stehen, sollte es auch m¨oglich sein, GTA/MTA mit Wine zu verwenden [9]. Zus¨atzlich zu Windows werden noch einige Treiber ben¨otigt. Diese befinden sich auf Datentr¨agern, die mit der Hardware geliefert wurde. Auch der Logitech Profiler muss installiert werden. Mit diesem Programm lassen sich diverse Einstellungen an der Steuerung ¨andern. Hier kann z. B. die Pedaleinstellung ge¨andert werden - fur¨ 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¨asst sich ohne Probleme von der DVD installieren. Eine vollst¨andige In- stallation ist empfehlenswert, da dadurch nach dem Downgrade (siehe 4.2.3) keine DVD mehr zum Starten erforderlich ist. Bei dieser Installationsart werden, zus¨atzlich 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¨oglichkeit des Einbindens von Modifikationen (Mod) in sp¨ateren Versionen unterbunden hat. Dies geschah, nachdem der Mod ‘Hot Coffee’ [16] Aufsehen erregt hatte und das Spiel danach in einigen L¨andern 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 Verfugung¨ 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¨asst 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¨achstes muss MTA installiert werden. Zu Beginn unserer Arbeit verwendeten wir die ClosedSource Version 1.0-dp2.3. Da wir aber sp¨ater 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 fur¨ diese Version entschieden. Es kann auch eine neuere Version gew¨ahlt werden, falls sp¨ater entwickelte Funktionen ben¨otigt werden, jedoch wurde diese von uns noch nicht getestet. Eine Auflistung der verfugbaren¨ Nightlys findet sich unter: http://nightly.multitheftauto.com/ Zus¨atzlich zu diesen t¨agliche erstellten Kompilaten werden noch weitere Dateien ben¨otigt. Diese befinden sich in einem separaten Download, da sie sich nur selten ¨andern und somit Platz und Bandbreite gespart werden kann, indem sie nicht bei jedem Update erneut geladen werden mussen.¨ Diese Dateien sind auf der Download- seite 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¨onnen, sind Ressourcen notwendig, in denen mit ver- schiedenen 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¨ager in den ‘resourcen’-Ordner des MTA-Servers (bei uns unter: C:\Programme\MTASanAndreas\server\mods\deathmatch\ resources\) eingefugt¨ werden. Das Skript besteht aus einer ‘meta.xml’, einigen Bildern und den beiden Skript- dateien. In der XML-Datei mussen¨ alle Dateien aufgefuhrt¨ werden, die verwendet werden sollen. Außerdem ist hier definiert, ob es sich bei den Skripts um Client- oder Serverskripts handelt (siehe 4.3.1).

4.2.6 Umgebung starten (mehrere Rechner / Server)

Nachdem die Installation durchgefuhrt¨ wurde, ist es m¨oglich MTA zu verwenden. Um Einstellungen, wie die Aufl¨osung, zu ¨andern muss jedoch GTA gestartet werden, da MTA keine Oberfl¨ache dafur¨ bietet. Es empfiehlt sich hier auch die Radiolaut- st¨arke zu minimieren. Wenn alle Optionen den Wunschen¨ entsprechend gesetzt sind, k¨onnen wir unsere Umgebung starten. Hierfur¨ starten wir zun¨achst ‘MTA Server’.

1http://files.filefront.com/sa+downgrade+patch+031rar/;12833867;/fileinfo.html 04.03.09 2http://code.google.com/p/multitheftauto/downloads/list 3svn+ssh://csl.ira.uka.de/svn/driving-simulator-gta 20 4. Arbeit mit GTA

Nachdem der Server vollst¨andig geladen ist, muss in der Konsole ‘start experiment’ eingegeben und mit Enter best¨atigt 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¨onnen die Clients verbinden. Die neun in di- ser Abbildung zu sehenden Fehlermeldungen k¨onnen ignoriert werden. Diese Fehler treten auf, wenn nicht die zus¨atzlich erh¨altlichen offiziellen Ressourcen installiert werden, sie werden jedoch nicht fur¨ unser System ben¨otigt.

Abbildung 4.1: MTA Server Konsole

Auf jedem der verwendeten Simulationsrechner wird nun MTA ausgefuhrt.¨

Die Intros mussen¨ mit einigen Mausklicks ubersprungen¨ werden. Ohne das Uber-¨ springen bleibt nur ein schwarzer Bildschirm zu sehen und die Rechner blieben bei uns auch vereinzelt h¨angen.

Bei den Intros und Ladebildschirmen handelt es sich um von uns erstellte Bilder. Die originalen Bilder wurden von uns angepasst, damit die Probanden einen besse- ren Eindruck von unserem System bekommen. Auch der Ladesound wurde von uns ge¨andert, da die ursprungliche¨ Musik als st¨orend empfunden wurde. Die von uns ver- ¨anderten Dateien liegen auf dem CSL SVN4 und der CD im Ordner ‘gtabranding’ bei.

Vor dem Verbinden sollte sichergestellt werden, dass die einzelnen Clients uber¨ in- dividuelle Spielernamen verfugen,¨ da der Verbindungsaufbau sonst wegen einer Na- menskollision abgebrochen wird. Der Name l¨asst sich im ‘SETTINGS’ Menu¨ ¨andern.

In dem nach dem Start erscheinenden Menu¨ muss ‘QUICK CONNECT’ gew¨ahlt und in der darauffolgenden Eingabemaske die Adresse, der Port und gegebenenfalls

4svn+ssh://csl.ira.uka.de/svn/driving-simulator-gta/gtabranding 4.2. Installation 21 ein Passwort des Servers eingegeben werden. Die Adresse l¨asst sich in der Einga- beaufforderung 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 Anderungen¨ an den Server-Ressourcen wird beim n¨achsten Verbinden der Dow- nload der ge¨anderten Dateien angezeigt. Danach bleibt ein schwarzer Bildschirm zu sehen und Eingaben zur Wahl des Ansichtmodus sind m¨oglich: Zur Unterscheidung der verschiedenen Ansichten muss nach dem erfolgreichen Verbinden eine Zahl zwi- schen 1 und 3 gedruckt¨ werden. Die 1 gibt dem Client die Rolle des Fahrers, er hat Kontrolle uber¨ die Steuerung und die mittlere der drei Ansichten. Die 2 ist fur¨ die linke Ansicht und 3 fur¨ die rechte. 22 4. Arbeit mit GTA

4.3 Szenario Fur¨ unsere ersten Versuche mit GTA verwenden wir die sp¨ater vorgestellte API, um die Probanden eine vorgegebene Strecke entlangfahren zu lassen. Dabei gibt ihnen ein, als Wizard fungierender, Beobachter Informationen, die sp¨ater 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 Pro- banden als artifizielles System wahrgenommen werden soll. Nach dem connecten w¨ahlt er seine Rolle durch Tastendruck aus. Er sieht, wo sich der Fahrer momen- tan befindet, bekommt aber noch zus¨atzliche Informationen eingeblendet, die ihm anzeigen, welche Anweisungen er dem Probanden geben muss. Der Proband und der Wizard k¨onnen uber¨ einen Audio-Chat miteinander kommunizieren, wobei die Stimme des Wizard verstellt wird, damit er mehr nach einem Programm als nach einem Menschen klingt. Zus¨atzlich sieht der Wizard den Fahrer uber¨ eine Webcam. Vor der festgelegten Strecke wird dem Fahrer die M¨oglichkeit 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¨adte gew¨ahlt. 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¨ahrt. Zu den weiteren Events z¨ahlen auf der Straße stehende oder gehende Fußg¨anger, oder andere pl¨otzlich auftauchende Fahrzeuge.

Abbildung 4.3: GTA Projektion fur¨ einen Versuchslauf

In diesem Abschnitt wird zus¨atzlich noch konkret auf die von uns erstellten LUA- Skripte eingegangen. 4.3. Szenario 23

4.3.1 Szenarioerstellung Das Szenarioskript besteht aus zwei Textdateien, ‘experiment client.lua’ und ‘ex- periment server.lua’. Die beiden Dateinamen sind in der Datei ‘meta.xml’ defi- niert, welche beim Starten des Experimentes eingelesen wird. Eine Einfuhrung¨ 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¨osen, wenn bestimmte Ereignisse stattgefunden haben, Keybindings, mit de- nen Tastatureingaben abgefragt werden und colCircles, die als Ausl¨oser fur¨ 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 ausgefuhrt.¨ Deshalb werden die Funktionen, welche fur¨ 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 mussten¨ und die Antwort erst beim n¨achsten Frame ankommen wurde.¨ Zu Beginn des Skriptes werden zun¨achst alle Bildschirmeinblendungen (HUD), wie z. B. Uhrzeit, Lebenspunkte oder Radar ausgeblendet. Sie werden nicht ben¨otigt, da sie unrealistisch sind, außerdem k¨onnten 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 uber¨ ‘setCameraMatrix’ an das Programm zuruckgege-¨ ben. function updateCameraPos() local pX, pY, pZ = getElementPosition(driver) local rX, rY, rZ = getVehicleRotation( getPlayerOccupiedVehicle(driver)) local cosA = math.cos(math.rad(360−rZ ) ) local sinA = math. sin(math.rad(360−rZ ) ) local sinB = math. sin(math.rad(360−rX) ) local targetX = sinA ∗ 20 local targetY = cosA ∗ 20 local targetZ = −sinB ∗ 20 setCameraMatrix(pX, pY, pZ + 1.0, pX + targetX, pY + targetY, pZ + targetZ + 1.0) end Listing 4.1: Beispiel einer LUA-Funktion

Im Client-Skript sind auch die Zusatzinformationen fur¨ den Wizard definiert. So werden auf seinem Bildschirm Pfeile zur Orientierung angezeigt, wenn der Fahrer in die angegebenen Bereiche f¨ahrt.

4.3.1.2 Server Uber¨ das Server-Skript wird als erstes die Rolle des Clients definiert. M¨ogliche Rol- len: Fahrer, Blick nach links und rechts, oder Wizard. Dazu werden die Tasten 1 bis 24 4. Arbeit mit GTA

6 mit der Funktion ‘setPlayerRole’ verknupft,¨ 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. Ahnliches¨ geschieht bei den anderen Tasten.

Wenn einer der Spieler erstellt wird, wird uber¨ das Event ‘onPlayerSpawn’, ‘setOb- server’ aufgerufen. Hier wird zun¨achst 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 Turen¨ verschlossen,

• der Fahrer ins Auto gesetzt

• und die Geschwindigkeitsanzeige initialisiert.

Bei der Umpositionierung das Fahrzeugs, wird es zun¨achst kurz angehoben, da es ansonsten zu Fehlern kommen kann. Dies hat mit der Kollisionsberechnung zu tun, weil ohne das Anheben die Stoßd¨ampferausdehnung zu abrupt ge¨andert wird und das Fahrzeug dadurch in die Luft katapultiert wird.

Als Fahrzeug w¨ahlten wir aus den verfugbaren¨ Modellen das Taxi. Es hatte bessere Fahreigenschaften als die meisten anderen Autos, z. B. waren die Stoßd¨ampfer nicht zu weich eingestellt und es war gut kontrollierbar. Um das Taxi jedoch noch weiter zu verbessern, nahmen wir einige Anderungen¨ in der ‘handling.cfg’ aus dem GTA ‘da- ta’ Ordner vor. Die maximal Geschwindigkeit wurde reduziert, der Luftwiderstand reduziert und die Bremse abgeschw¨acht.

Die in 4.3.2 beschriebene Logfunktion wird auch im Server-Skript definiert.

4.3.2 Szenarioauswertung

Um eine sp¨atere Auswertung zu erm¨oglichen, werden regelm¨aßig die Daten des Fah- rers gespeichert. Bei diesen Daten handelt es sich um die Position und Rotation des Fahrzeuges in der virtuellen Welt.

Hierfur¨ 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 gewunschten¨ Parameter geschrieben werden. Zus¨atzlich zur Position wird die Geschwindigkeit und die genaue Zeit zur sp¨ateren Synchronisation gespeichert.

Beim Verlassen des Fahrer-Clients wird der Timer beendet und der Filehandler ge- schlossen. 4.4. Pre Open-Source 25

4.4 Pre Open-Source Zu beginn unserer Arbeit handelte es sich bei MTA noch um ein Closed-Source Projekt. Im Laufe unserer Arbeit ¨anderte sich dies und wir konnten die in 4.5 vor- gestellten Anderungen¨ implementieren. Da wir jedoch zun¨achst keinen Zugriff auf den Quellcode von MTA hatten, mussten Probleme, wie das Nichtvorhandensein von einer Lenkradunterstutzung¨ und die Implementierung von mehreren Ansichten, auf anderen Wegen gel¨ost werden.

4.4.1 Integration Lenkrad MTA enthielt keine Unterstutzung¨ fur¨ DirectInput und somit fur¨ Joysticks/Lenkr¨a- der/Gamepads, weswegen die Entwickler XPadder vorschlagen [7], um dennoch in der Lage zu sein, nicht auf eine Tastatursteuerung ausweichen zu mussen.¨ Durch dieses Programm wird jedoch nur eine digitale Steuerung wie auf der Tasta- tur erm¨oglicht, es gibt also keine Abstufungen bei der Lenkung und dem Gas. In Tests zeigt sich die L¨osung als unbrauchbar, da ein leichter nicht von einem starken Lenkradausschlag zu unterscheiden war. Als n¨achstes probierten wir den Pinnacle Game Profiler aus. Hiermit war es m¨oglich bis zu 9 Segmente einer Lenkradachse auf verschiedene Tasten zu legen. Jedoch gab es nur die M¨oglichkeit, diese Events uber¨ 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 anfuhlte.¨ Um die Probleme zu umgehen, schrieben wir ein externes Programm, das die Lenk- radachsen uber¨ Pulsweitenmodulation (PWM) in Tastaturevents umwandelt. Bei PWM wird das Zeitverh¨altnis zwischen zwei Zust¨anden, in diesem Fall ‘Taste ge- druckt’¨ und ‘keine Taste gedruckt’,¨ so angepasst, dass es im Durchschnitt der Aus- lenkung 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 uber¨ ‘keybd event’ virtuelle Tastendrucke¨ an Win- dows weitergibt. Auch wenn wir, wie sp¨ater in 4.5.3 gezeigt, eine bessere L¨osung fur¨ das Lenkproblem verwendeten, kann unser Tool, da es MTA umgeht, auch fur¨ andere Systeme genutzt werden, die nur eine Tastatureingabe erlauben. Um das Tool selber kompilieren zu k¨onnen muss Visual C++ 2003, wie in 4.5.1.1 be- schrieben, installiert werden. Es liegen jedoch auch Projektdateien fur¨ neuere Visual Studio Versionen und eine fertige ausfuhrbare¨ 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¨ande schauen und somit die 3 Beamer- bilder gemeinsam ein zusammenh¨angendes 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¨angende 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¨ahlten wir die freie Kamera. Die freie Kamera unterstutzt¨ 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¨osung wurde sp¨ater (siehe 4.5.2) durch eine Anderung¨ im MTA Quellcode weitgehend ersetzt. 4.5. Open-Source 27

4.5 Open-Source

Die Ver¨offentlichung von MTA als Open-Source machte die L¨osung einiger unse- rer Probleme uberhaupt¨ erst m¨oglich. So war es uns zum Beispiel m¨oglich, eine integrierte Joystick-Unterstutzung¨ zu verwenden und die Projektionsmatrix fur¨ die Ansichten zu manipulieren.

4.5.1 Installation SourceCode

Die Installation der n¨otigen Mittel orientiert sich gr¨oß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¨otigt. Es existieren zwar auch Visual Studio 2005 Projektdateien, jedoch ließen sich diese nicht von uns zur Ausfuhrung¨ bringen, selbst nachdem wir sie mit einigen Anpassungen zum fehlerfreien Kompilieren gebracht hatten. Falls zu einem sp¨ateren Zeitpunkt diese Fehler von den Entwicklern gel¨ost sein sollten, w¨are es auch m¨oglich, anstatt das komplette Visual Studio 2003 zu installieren, auf das kostenlos erh¨altliche Visual C++ Express zuruckzugreifen.¨ Da MTA einige Funktionen von DirectShow verwendet, muss das Platform SDK in- stalliert werden. In der Vergangenheit war DirectShow ein Bestandteil von DirectX, ist jetzt jedoch nur noch im Platform SDK oder im Windows SDK enthalten. Beim Ausfuhren¨ des Setups k¨onnen alle anderen Komponenten weggelassen werden (siehe Abb. 4.5), die ben¨otigte Gr¨oße des Downloads und des verwendeten Festplatten- platzes wird dadurch erheblich reduziert. Anstatt 1,05GB werden nur noch 60MB ben¨otigt.

Abbildung 4.5: Installation der DirectShow-Komponenten des Platform-SDK 28 4. Arbeit mit GTA

Zus¨atzlich wird das DirectX 9 SDK von Microsoft ben¨otigt. In den neusten SDKs be- finden sich keine DirectX 8 Header-Dateien mehr, weswegen auf eine ¨altere Version, zum Beispiel vom August 2008, zuruckgegriffen¨ werden sollte. Nachdem alle SDKs installiert wurden, mussen¨ 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’ auszufuhren.¨ 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¨altlichen TortoiseSVN5 als Subver- sionclient, welches dazu installiert werden muss. Zun¨achst 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¨otigten Quellen. Danach wird http://multitheftauto.googlecode.com/svn/vendor/ nach C:\source\trunk\vendor ausgecheckt. Hier befinden sich einige Bibliotheken von Drittanbietern, die fur¨ das Kompilieren erforderlich sind.

5http://tortoisesvn.net/ 4.5. Open-Source 29

Zus¨atzlich zu den Dateien aus den Repositories werden noch weitere Abh¨angigkeiten ben¨otigt. 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¨achstes spielen wir die von uns erstellten Patches ein, in denen die in den n¨achsten Abschnitten beschriebenen Anderungen¨ auf die Originalquellen angewandt werden. Die dafur¨ ben¨otigten 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 Anderungen¨ erforderlich sind. In ‘mta patch.diff’ wird zum einen der Joystick Support (siehe 4.5.3) fur¨ unsere Bedurfnisse¨ angepasst. Zum Anderen befinden sich darin die Anderungen¨ fur¨ 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 Anderungen¨ nur ein Unterprojekt neu erstellt. In den originalen Projekteinstellungen fur¨ die Nightly-Konfiguration liegen die Aus- gabepfade in dem Unterordner ‘./output’ und man muss die darin befindlichen Da- teien zur Verwendung in die entsprechenden Ordner kopieren. Um diesen deploy- Prozess zu vereinfachen, haben wir die Outputpfade mit unserem Patch angepasst, damit alle Dateien beim Linken gleich in den richtigen Ordnern erstellt werden. Zus¨atzlich haben wir fur¨ die beiden Ansichten Rechts und Links zwei eigene Kon- figurationen erstellt, bei denen die Dateien auf die als Netzlaufwerke verbundenen Verzeichnisse der beiden Computer geschrieben werden. Die Netzlaufwerke mussen¨ 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¨ahlt und das Projekt erstellen l¨asst, werden die entsprechenden Dateien mit den verschiedenen integrierten Ansichten auf den PCs erstellt und k¨onnen gestartet werden. Bisher haben wir nur die Zielpfade fur¨ ‘Client - Core’ fur¨ die beiden zur Seite pro- jizierenden Rechner angepasst. Hier finden n¨amlich die Berechnungen fur¨ die Ka- meramatrizen statt. Wenn in Zukunft auch Unterschiede in anderen Unterprojekten implementiert werden, mussen¨ die anderen Pfade auch angepasst werden. Unter Um- st¨anden sind auch andere Netzlaufwerke einzurichten, wenn sich diese Anderungen¨ 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 Anderungen¨ am Quellcode vorgenommen werden mussen,¨ ist es unter Umst¨anden n¨otig, MTA neu zu starten. Bei Anderungen¨ in den Unterprojekten, 6svn+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, ¨anderten wir unser Vorgehen komplett zu C++. Hier hatten wir die M¨oglichkeit, direkt auf die Projektionsmatrizen zuzugreifen und hatten zus¨atzlich eine flussigere¨ Darstellung. Die erste Anderung¨ besteht darin, dass wir fur¨ die Seitenansichten die Blickrich- tung jeweils gedreht haben. Hierzu haben wir in der Datei ‘CClientCamera.cpp’ die Verarbeitung der fixierten Kamera ge¨andert. Je nachdem mit welchen Compilerpa- rametern fur¨ die jeweiligen Rechner kompiliert wird, wird der Blickpunkt um 70° nach rechts oder links angepasst. Dieser Winkel wurde gew¨ahlt, da die Ansichten im Widescreenmodus diesen Blickwinkel haben. Die zweite Anderung¨ bewirkt, dass der Fahrer nicht mehr die ganze Zeit das Ge- fuhl¨ hat, einen Berg hinaufzufahren. Dies wird durch eine Positionsverlagerung des Horizontes auf Kopfh¨ohe 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 umzuwan- deln. Die Transformationen sind Welt-Transformation, View-Transformation und Projektions-Transformation. Diese sind durch Matrizen repr¨asentiert und werden nacheinander auf die Koordinaten in der Form (x,y,z) angewandt. Unsere Anderungen¨ setzen nach der View-Transformation an, da hier das Koordi- natensystem 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¨onnen wir leicht Objekte, die sich weiter weg von der Kamera befinden - also einen gr¨oßeren z-Wert haben - nach unten verschieben. Die Anpassungen fanden in der Funktion ‘StoreTransform’ in der Datei ‘CDirect3DData.cpp’ statt. Diese Datei geh¨ort zu dem Projekt ‘Client - Core’. Die- se Funktion wird von GTA aufgerufen, wenn Transformationsmatrizen gespeichert werden, um sie an die Grafikkarte weiterzugeben. 4.5. Open-Source 31

Mittels einer Scherungsoperation wird der projizierte Bildausschnitt vertikal ver- schoben:       x11 x12 x13 x14 1 0 0 0 x11 x12 + x13 ∗ t x13 x14 x21 x22 x23 x24 0 1 0 0 x21 x22 + x23 ∗ t x23 x24   ·   =   x31 x32 x33 x34 0 t 1 0 x31 x32 + x33 ∗ t x33 x34 x41 x42 x43 x44 0 0 0 1 x41 x42 + x43 ∗ t x43 x44

Der Parameter t gibt die St¨arke der Scherung an. Wir w¨ahlten t=-0.1 da dies den Horizont in Augenh¨ohe setzt.

Projektionskegel y y

z

Kamera z

Kamera

Abbildung 4.8: Anderung¨ des Projektionskegels

4.5.3 Joystick Support In der von uns verwendeten SVN Revision 149 von MTA existierte bereits ein grund- legender Joystick Support, durch einen Bug in der Implementierung war es jedoch nicht m¨oglich, das G25 Lenkrad von Logitech zu verwenden. In der Implementierung wurden nicht alle verfugbaren¨ Achsen abgefragt, sondern nur die Achsen bis zur er- sten nicht vorhandenen, da das Polling an der Lucke¨ 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¨otig, ein Mapping fur¨ das von uns verwendete G25 Lenkrad zu erstellen. In dem Mapping werden den einzelnen Ach- sen die Funktionen und Wertebereiche zugeordnet. So wird z. B. ‘eJoyX’, was der Lenkung entspricht, in beide Richtungen dem ‘eLeftStickX’ zugewiesen. Durch die von uns durchgefuhrten¨ Anderungen¨ war eine analoge, d.h. flussige¨ und sensibel einstellbare Steuerung des Fahrzeugs m¨oglich. Hinweis: In sp¨ateren Revisionen von MTA ist unser Patch nicht mehr notwendig und es ist auch m¨oglich, uber¨ die MTA Settings die Achsen und Kn¨opfe zu konfigu- rieren. 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¨ahlten wir das Spiel “Need for Speed: Underground (NfS)”. Um Vergleichbarkeit zu gew¨ahrleisten 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 durchgefuhrt,¨ 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¨oglich mehr als eine Ansicht zu verwenden und die befahrbare Welt ist viel kleiner. Dafur¨ existiert eine bessere Lenkradunterstutzung¨ mit Force-Feedback. Auch autonom agierender Verkehr ist vorhanden. Im Uberblick¨ 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 1Beschreibung des Hardwareaufbaus unter [18] 34 5. Evaluierung

Mit Hilfe des Fragebogens wollen wir feststellen, wo die St¨arken und Schw¨achen un- seres Systems liegen. Dazu ließen wir jeden Fahrer beide Systeme jeweils 7 Minuten fahren und danach beurteilen. Die H¨alfte der Probanden fuhr zuerst GTA, die andere NfS, um eine Beeinflussung der Ergebnisse, z. B. durch Gew¨ohnung, auszugleichen. Am Ende des Versuches bekamen die Probanden via Fragebogen folgende Fragen gestellt: 35

Fragebogen 1 Dieser Fragebogen diente zur statistischen Erfassung und Klassifi- zierung des Probanden.

• Wie alt sind Sie?

• Ihr Geschlecht?

• Haben Sie Erfahrung mit Computerrennspielen?

• Haben Sie einen Fuhrerschein?¨

• Seit wievielen Jahren haben Sie Ihren Fuhrerschein?¨

• Wieviel fahren Sie durchschnittlich pro Monat?

• Fahren Sie haupts¨achlich Ihnen bekannte Strecken?

• Fahren Sie mit Navigationsger¨at?

• Fahren Sie uberwiegend¨ Autobahn?

• Wieviele verschiedene Autos sind Sie bereits l¨angere Zeit (min. 3 Monate) gefahren?

• Welchen Fahrzeugtyp (Kleinwagen, LKW etc.) fahren Sie zur Zeit

Fragebogen 2 Dieser Fragebogen diente dazu Meinungen der Probanden zu be- kommen, 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¨agt ... Ihrer Meinung nach zur Qualit¨at eines Fahrsimulators bei? Jeweils funfstufige¨ Skala von “gar nicht” bis “sehr viel”.

– Kraftruckmeldung¨ des Lenkrads – Bewegung der Sitzkiste – Ansicht(Anzahl/Gr¨oße Blickfeld) – Ansicht(Qualit¨at/Aufl¨osung) – Fahrverhalten des Fahrzeugs – Verkehr – Umgebung in der Simulation

• Wie realistisch empfanden Sie ... in Versuch 1 bzw. 2? Pro Versuch jeweils funfstufige¨ Skala von “gar nicht” bis “sehr viel”.

– Kraftruckmeldung¨ des Lenkrads 36 5. Evaluierung

– Bewegung der Sitzkiste – Ansicht (Anzahl/Gr¨oße Blickfeld) – Ansicht (Qualit¨at/Aufl¨osung) – Fahrverhalten des Fahrzeugs – Verkehr – Umgebung in der Simulation

• Wie realistisch fanden Sie die Sitzkiste? Funfstufige¨ Skala von “Videospiel” bis “echtes Auto”.

• Ist Ihnen schlecht geworden? Pro Versuch jeweils funfstufige¨ 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 ubergeben.¨ Die Simulator Sickness2 tritt also auch in unserem Aufbau auf. Wir nahmen an, dass den Probanden in GTA grunds¨atzlich schlechter wird, als in NFS. Die Grunde¨ dafur¨ vermuteten wir in der umfangreicheren Simulation durch drei Ansichten und der unserer Meinung nach schlechteren Steuerung in GTA. Um das zu uberpr¨ ufen¨ fuhrten¨ wir einen zweiseitig, gepaarten T-Test durch. Unser Signi- fikanzniveau legten wir auf α = 0, 05 fest. Das Ergebnis ergab p = 0.03656. Damit ist das Ergebnis signifikant. Die seitlichen Ansichten gaben den Probanden mehr Ubersicht,¨ das wurde vorwie- gend positiv empfunden. Da allerdings der Sichtbereich dadurch komplett durch die Projektion abgedeckt ist und der Proband nichts mehr von der “echten” Realit¨at sieht, k¨onnte dies ein Grund fur¨ die erh¨ohte Ubelkeit¨ beim GTA-Versuch sein. Ein weiterer Kritikpunkt beim GTA-Versuch ist das Fahr- und vor allem Lenkverhal- ten. Insbesondere ¨altere Menschen und Menschen ohne Computerrennspielerfahrung hatten Probleme das Auto unter Kontrolle zu halten. Hier entdeckten wir eine Ver- z¨ogerung der Lenkubertragung¨ zur Software. Wir vermuten, dass entweder zu gut interpoliert wird oder die Ansteuerung des Lenkrades nicht latenzfrei funktioniert. Desweiteren bietet GTA keine dynamische Kraftruckmeldung¨ des Lenkrades, die Ruckstellfeder¨ hat also immer die gleiche Kraft unabh¨angig der aktuellen Geschwin- digkeit. Anhand der erstellten Daten vermuten wir, dass die Simulator Sickness mit dem Alter und der Erfahrung bezuglich¨ Computerrennspielen zusammenh¨angt. Wobei Alter und Erfahrung aller Wahrscheinlichkeit nach korrelieren. Einige Probanden fanden es st¨orend, 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.

2Eine durch T¨auschung der Sinnesorgane hervorgerufene Ubelkeit.¨ 5.1. Ergebnis 37

Abbildung 5.1: Alter der Probanden

Abbildung 5.2: Geschlecht der Pro- Abbildung 5.3: Probanden mit Erfah- banden rung in Computerrennspielen 38 5. Evaluierung

Abbildung 5.4: Die Probanden fahren Abbildung 5.5: Probanden mit Fuh-¨ vorwiegend bekannte Strecken. rerschein

Abbildung 5.6: Die meisten Proban- Abbildung 5.7: Nur wenige Proban- den fahren ohne Navigationsger¨at. den fahren viel Autobahn. 5.1. Ergebnis 39

Abbildung 5.8: Seit wievielen Jahren haben die Probanden einen Fuhrerschein¨

Abbildung 5.9: Durchschnittliche Fahrkilometer pro Monat 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 ¨ uberzeugt. Bei der Lenkung und dem Fahrverhalten hat NFS besser abgeschnitten. Abbildung 5.12: GTA hat mit der dritten Ansicht 42 5. Evaluierung

Abbildung 5.13: Die Sitzkiste wurde als uberwiegend¨ realistisch empfunden.

Abbildung 5.14: Bei GTA besteht erh¨ohte 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 Verfugung¨ stehenden Mitteln auf. Durch diese Arbeit entstand am CSL ein funktionsf¨ahiger Fahrsimulator, mit dem bereits Versuche durchgefuhrt¨ werden. Unter anderem stehen folgende Funktionalit¨aten zur Verfugung:¨

• Softwareumgebung auf Basis von GTA

– Grafikausgabe einer realistischen Umgebung – 5.1 Soundausgabe – große virtuelle Welt

• Ansteuerung uber¨ Spielelenkrad Logitech G25

• Drei Ansichten uber¨ Netzwerk

• Szenarioskriptbarkeit

Es gibt aber immer noch zahlreiche Verbesserungsm¨oglichkeiten:

• Da die Steuerung des Fahrzeugs einer der Hauptkritikpunkte der Probanden war, sollte versucht werden diese zu verbessern. Wir vermuten, dass die Len- kung zu tr¨age reagiert und deshalb schwer zu handhaben ist.

• Zus¨atzlich zu einer schneller reagierenden Lenkung w¨are Force-Feedback wun-¨ schenswert. Dies wurde¨ eine weitere Qualit¨atsverbesserung darstellen.

• Es sollte auch erm¨oglicht 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¨oglichkeit, diese Informationen zu verwenden. 44 6. Zusammenfassung und Ausblick

• Der in der Sitzkiste eingebaute Tachometer k¨onnte uber¨ eine Schnittstelle, z. B. USB, als Hardware in die Simulationsumgebung eingebunden werden. Dies wurde¨ gegenuber¨ der Bildschirmeinblendung den Realismus erh¨ohen, da die Geschwindigkeitsanzeige wie in einem echten Auto w¨are.

• Ein wichtiger Punkt ist die Einbindung von Verkehr. Es gab bereits erste Versuche, aufgezeichneten Verkehr zu verwenden. Dieser nimmt jedoch noch keine Rucksicht¨ auf andere Verkehrsteilnehmer. Ein autonomer Verkehr ist anzustreben.

• Ein grafischer Editor k¨onnte die Erstellung von Szenarien stark vereinfachen. Es k¨onnte z. B. innerhalb der Software zug¨anglich sein und die Positionierung und Identifizierung von Objekten vereinfachen und Skripte automatisch erstel- len. Literaturverzeichnis

[1] Autosim. http://www.autosim.no/.

[2] Fahrsimulationssoftware Silab. http://www.wivw.de/ ProdukteDienstleistungen/SILAB/index.php.de.

[3] GTA III - Grand Theft Auto 3. http://www.rockstargames.com/ grandtheftauto3/.

[4] GTA San Andreas: System Requirements. http://www.rockstargames.com/ sanandreas/pc/.

[5] Instructions on how to compile MTA yourself. http://code.google.com/p/ multitheftauto/wiki/HowToBuild.

[6] Known Issues: Does MTASA:DM work with v1.01 or v2.00 of GTA San An- dreas. 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] Moller,¨ Tomas und Eric Haines: Real-time rendering. Peters, 2. ed. Auf- lage, 2002. 46 Literaturverzeichnis

[18] Reinhold, Frieder: Studienarbeit: Aufbau eines Fahrsimulators - Schwer- punkt Hardware. Universit¨at Karlsruhe, 2009.