Realtidsvisualisering av ögonrörelser i simulator : utveckling och implementation

VTI notat 7-2009 Utgivningsår 2009

www.vti.se/publikationer

Realtidsvisualisering av ögonrörelser i simulator

Utveckling och implementation

Förord

Föreliggande projekt har genomförts under 2008 som uppsats vid Linköpings universitet av Mikael Nordenrot.

Handledare på VTI har varit Mikael Adlers, handledare och examinator på Linköpings universitet var Ingemar Ragnemalm. Projektets syfte var att visualisera förarens blickriktning i VTI:s avancerade körsimulator och rapporten beskriver hur ett sådant system kan implementeras och vilka problem som kan förekomma. I det implemen-terade systemet, Gaze Tracker, görs visualisering och detektering i realtid. För

registrering av ögonens rörelser samt position användes Smart Eye Pro. Gaze Tracker fungerar som en tilläggsmodul till VTI:s körsimulator.

Tack till alla på FTS (Fordonsteknik och simulering) för ett gott samarbete.

Jonas Jansson Enhetschef

Realtidsvisualisering av ögonrörelser i simulator

- Utveckling och implementation

Examensarbete utfört i Informationskodning av

Mikael Nordenrot

Realtidsvisualisering av ögonrörelser i simulator

- Utveckling och implementation

Examensarbete utfört i Informationskodning vid Linköpings tekniska högskola

av

Mikael Nordenrot

Handledare: Mikael Adlers, Ingemar Ragnemalm Examinator: Ingemar Ragnemalm

Presentationsdatum

08-12-10

Publiceringsdatum (elektronisk version)

Institution och avdelning Institutionen för systemteknik Department of Electrical Engineering

URL för elektronisk version

http://www.ep.liu.se

Publikationens titel

Realtidsvisualisering av ögonrörelser i simulator – Utveckling och implementation

Författare

Mikael Nordenrot

Sammanfattning

Denna rapport beskriver hur en förares ögonrörelser och blickriktning kan visualiseras i en simulator. Rapporten beskriver också hur ett sådant system kan implementeras och vilka problem som kan förekomma. I det implementerade systemet, Gaze Tracker, görs visualisering och detektering i realtid och för registrering av ögonens rörelser samt position användes Smart Eye Pro. Gaze Tracker fungerar som en tilläggsmodul till VTI:s körsimulator, Simulator III, och det är även denna simulator som använts vid de slutliga testerna för att utvärdera systemets prestanda. Testerna bedömdes som lyckade och visualiseringen av ögonrörelserna ansågs uppfylla de uppsatta målen.

Rapporten ger också läsaren en förståelse för hur människan använder och rör sina ögon och hur dessa rörelser kan registreras med olika tekniker. Tekniker som tas upp är kontaktlinser, elektro-okulografi (EOG) och video-okulografi (VOG).

Eftersom körsimulatorn på VTI är en central del i detta arbete ges läsaren också en övergripande förståelse för hur denna simulator är uppbyggd och vad som är möjligt att simulera med denna.

Antal sidor: 62

Nyckelord Språk

X Svenska

Annat (ange nedan)

Antal sidor 62 Typ av publikation Licentiatavhandling X Examensarbete C-uppsats D-uppsats Rapport

Annat (ange nedan)

ISBN (licentiatavhandling)

ISRN LiTH-ISY-EX-08/4012--SE

Serietitel (licentiatavhandling)

Abstract

This thesis describes how to visualize a driver's eye movements and gaze direction in a simulator. The thesis also describes how to implement such a system and what problems to expect. In the implemented system, Gaze Tracker, the visualization and detection is made in real-time and Smart Eye Pro was the system used to detect eye movements and eye position. Gaze Tracker works as an add-on application to the driving simulator of VTI, Simulator III, and this was also the simulator used in the final tests. These tests were considered to be successful and the visuali-zation was considered to fulfill the goal of this thesis.

This thesis also describes how a human uses his/her eyes and what kind of techniques possible to use for detection of these eye movements. Techniques mentioned in this thesis are contact lenses, electrooculography (EOG) and videooculography (VOG).

Because of the close usage of the driving simulator of VTI this thesis also gives a description of their latest simulator and what kind of simulations it can be used for.

Sammanfattning

Denna rapport beskriver hur en förares ögonrörelser och blickriktning kan visualiseras i en simu-lator. Rapporten beskriver också hur ett sådant system kan implementeras och vilka problem som kan förekomma. I det implementerade systemet, Gaze Tracker, görs visualisering och detekte-ring i realtid och för registredetekte-ring av ögonens rörelser samt position användes Smart Eye Pro. Gaze Tracker fungerar som en tilläggsmodul till VTI:s körsimulator, Simulator III, och det är även denna simulator som använts vid de slutliga testerna för att utvärdera systemets pre-standa. Testerna bedömdes som lyckade och visualiseringen av ögonrörelserna ansågs uppfylla de uppsatta målen.

Rapporten ger också läsaren en förståelse för hur människan använder och rör sina ögon och hur dessa rörelser kan registreras med olika tekniker. Tekniker som tas upp är kontaktlinser, elektro-okulografi (EOG) och video-elektro-okulografi (VOG).

Eftersom körsimulatorn på VTI är en central del i detta arbete ges läsaren också en övergripande förståelse för hur denna simulator är uppbyggd och vad som är möjligt att simulera med denna.

Förord

Jag skulle vilja tacka alla som på ett eller annat sätt ställt upp och hjälpt mig under arbetets gång. Ett särskilt tack till Martin Bergstrand, som också gjorde sitt examensarbete på VTI, för den trev-liga tiden på vårt gemensamma kontor. Att sitta tillsammans som vi gjorde i ett och samma kontor leder verkligen till många intressanta och roliga diskussioner. Inte bara diskussioner som berör det aktuella arbetet utan också vardagliga händelser som inträffar i ens liv. Jag vill också tacka min handledare Mikael Adlers som varit en stor tillgång vid tekniska frågor om simulatorns uppbyggnad och funktion. Dessutom vill jag tacka Mats Lidström och Laban Källgren för all mjukvarurelaterad support samt Tania Dukic för hennes stöd och intressanta åsikter under arbe-tets gång. Till sist vill jag också tacka min handledare på Liköpings Tekniska Högskola, Ingemar Ragnemalm, för all hjälp att slutföra denna rapport.

Innehåll

3.3 Smart Eye Pro 3.5 . . . .14

3.3.1 Kalibrering och koordinatsystem . . . .15

3.3.2 Utdata . . . .16 3.3.3 Liknande system . . . .17 4 VTI-simulatorn . . . .19 4.1 Simulator III . . . .19 4.1.1 Systemet . . . .21 4.2 Grafiksystemet. . . .22 4.3 Visual. . . .23 5 Problemidentifiering . . . .27 5.1 Noggrannhet . . . .27 5.1.1 Problemanalys. . . .27 5.1.2 Problemhantering . . . .28 5.2 Tidsförskjutningar . . . .28 5.2.1 Problemanalys. . . .28 5.2.2 Problemhantering . . . .29 5.3 Visualisering . . . .30 5.3.1 Problemanalys. . . .30 5.3.2 Problemhantering . . . .30 5.4 Överbelastning. . . .31 5.4.1 Problemanalys. . . .31 5.4.2 Problemhantering . . . .31 5.5 Kalibrering. . . .32 5.5.1 Problemanalys. . . .32

5.6.1 Problemanalys . . . 33 5.6.2 Problemhantering . . . 33 5.7 Diskussion . . . 33 6 Gaze Tracker . . . 35 6.1 Arkitektur. . . 35 6.1.1 Gaze Manager . . . 36 6.1.2 Smart Eye. . . 36 6.2 Gaze Items . . . 37 6.2.1 Användning av GazeItems . . . 38 6.3 Processen . . . 39 6.3.1 Deklarering . . . 40 6.3.2 Filtrering . . . 41 6.3.3 Detektering . . . 42 6.3.4 Visualisering . . . 43 6.4 Prestanda . . . 44 7 Slutsatser . . . 47 7.1 Resultat . . . 47 7.2 Vidareutveckling . . . 47

Figurer

Tredimensionell kub . . . .6

Människans horisontella synfält i jämförelse med hästens.. . . .7

Diagram över skärpan för olika vinklar från blickriktningen . . . .7

Saccader och fixationer växelvis. . . . .8

En fixation innehållande microsaccader, drift och tremor. . . .9

Magnetslinge-metoden. Silikonlins placerad på ögat. . . .12

Elektro-okulografi (EOG). Placering av elektroder. . . .13

De fyra purkinjereflektionerna. . . .14

Placering av Smart Eyes kameror och IR-lampor i bilen. . . .15

Profilpunkter i Smart Eye Pro 3.5.. . . .15

Kalibreringsplattans placering i bilen med de olika axlarna.. . . .16

Tobii T60/T120 Eye Tracker . . . .17

Ett enkelt FaceLAB system. . . . .18

Simulator III med personbil. . . .19

Rörelser för kraftsimulering i körsimulator. . . . .20

Signalflödet i Simulator III med Smart Eye. . . .21

Grafiksystemet . . . .22

Exempel på hur omgivning visas för en förare med hjälp av Visual. . . .23

SRH-koordinater . . . .24

Klassdiagram för de olika objekten. . . . .25

Tidsfördöjningar i systemet . . . .29

Gaze Trackers uppbyggnad. . . . .35

Gaze Trackers flöde. . . . .39

XML-kod med tre gaze-element.. . . .41

Geometrisk tolkning av vibrationsfiltret.. . . .42

Tabeller

Riktvärden på Gaze Tracker-systemets prestanda. . . . .45 Specifikation för två olika PC-datorer som använts vid prestandamätningar. . . . . .45

K

I

NLEDNING

1.1 Bakgrund

Simulatorer har länge haft en viktig och avgörande roll för utvecklingen och forskningen på fordon och farkoster. Inom flygindustrin insåg man detta tidigt och redan i början på 1900-talet byggdes de första flygsimu-latorerna. Dessa var visserligen väldigt enkla och bestod av en flygplans-kropp som ställdes mot vinden och hade väldigt begränsad rörelsefrihet. Fordonsindustrin var dock inte sena att inse fördelarna med simulatorer men eftersom hjulbaserade fordon ställer högre krav på realistiska rörel-sekrafter, dröjde det ett bra tag innan utvecklingen tog fart inom den branschen.

Idag finns det en mängd olika varianter av simulatorer och deras använd-ningsområde är minst lika mångfaldigt. Den senaste tidens snabba tek-niska utveckling har också bidragit till att det idag är möjligt att för mindre företag och organisationer att utveckla sina egna simulatorer. VTI, Statens väg- och transportforskningsinstitut, som länge har varit bland de främsta inom körsimulatorer, lanserade sin första simulator år 1984. Idag har de sin tredje körsimulator i drift och denna kan bl.a. användas till att simulera körningar med personbil, lastbil och tåg.

1.2 Syfte

VTI har sen i slutet på 90-talet bedrivit forskning om förares ögonrörel-ser. Under årens lopp har en mängd olika studier gjorts där man bl a stu-derat förarens ögonaktivitet vid olika trafiksituationer och vid t ex trötthet eller drogpåverkan. Man har också gjort undersökningar på hur förarens blickmönster förändras i olika trafiksituationer och hur perso-nen uppfattar diverse teknisk utrustning. Det sistnämnda har blivit allt mer intressant på senare tid då antalet tekniska hjälpmedel i förarkabi-nen blivit allt fler.

Flertalet av de gjorda testerna har dock enbart riktat sig mot stora eller få fasta områden i bilen som exempelvis ut genom framrutan, instrumentpa-nelen och backspeglar. Syftet med detta arbete är att kunna utöka dessa undersökningar till att även innefatta föremål och händelser som utspelar sig i simuleringen. Systemet skall i realtid kunna identifiera var och på vad som föraren tittar i den simulerade miljön och samtidigt visualisera detta på ett överskådligt sätt.

1.3 Mål

Mitt mål med detta arbete är att med hjälp av utdata från ett system för ögonrörelsedetektering, utveckla en modul till VTI:s grafikmotor Visual. Modulen ska i realtid visualisera förarens blickriktning på en separat dator kopplad till simulatorns nätverk. Utöver detta kommer även ett san-nolikhetsvärde, baserat på förarens blickriktning, kontinuerligt att beräk-nas och visas för de olika föremålen som definierats i miljön. Exempel på intressanta föremål kan vara skyltar, andra fordon, personer och djur.

1.4 Avgränsningar

Ett externt system, Smart Eye Pro 3.5, kommer att vara monterat i körsi-mulatorn och användas för detektering och generering av ögonrörelse-data. Användningen av detta system är redan fastställt av VTI och därför kommer inte en undersökning om andra liknande system kan ge bättre resultat att genomföras som en del av detta arbete.

Eftersom VTI:s grafikmotor Visual är utvecklad i Visual Studio 2005 och skriven i C++ kommer även detta arbete använda sig av denna utvecklingsmiljö och detta programmeringsspråk.

1.5 Disposition

Denna rapport börjar med ett inledande kapitel och beskriver arbetets bakgrund, syfte, mål och avgränsningar. Rapporten innehåller därefter tre introducerande och teoretiska kapitel. I kapitel 2 ges en kort introduktion till människans öga. Här beskrivs ögats olika rörelser och hur dessa används vid normalt seende. Kapitel 3 beskriver olika tekniker som idag finns tillgängliga och används för att detektera ögonrörelser. Kapitlet beskriver också Smart Eye Pro 3.5, som är det system som använts i detta arbete. Kapitel 4 är det sista introducerande kapitlet och beskriver VTI-simulatorns konstruktion och uppbyggnad. Här beskrivs också olika tekniker som en simulator kan använda sig av för att simulera olika rörel-ser eller händelseförlopp för hjulgående fordon.

I kapitel 5 identifieras och beskrivs de olika delproblem som har upp-kommit under arbetets gång. Till varje delproblem beskrivs också en eller flera valda lösningar som använts i den slutliga implementationen. Sist i kapitlet ges en kort diskussion om andra mindre problem som dis-kuterats och provats under arbets gång.

I kapitel 6 beskrivs Gaze Tracker. Detta är det slutgiltiga systemet och målet med arbetet. Kapitlet beskriver systemets arkitektur med dess ingå-ende moduler samt processen som modulerna arbetar efter. Kapitlet tar även upp olika prestandamätningar på det implementerade systemet. Kapitel 7 är det sista kapitlet och presenterar resultatet av det implemen-terade systemet. Här ges också förslag på olika förbättringar som kan göras på Gaze Tracker vid en eventuell vidareutveckling.

K

M

ÄNNISKANS

ÖGA

I över 100 år har det gjorts studier och bedrivits forskning om hur våra ögon fungerar och används för att tolka vår omgivning. I detta kapitel introduceras läsaren till hur människans öga fungerar och hur det används för att tolka sin omgivning.

2.1 Historik

En av de första att bedriva studier om människans öga var H. von Helm-holtz. I en av hans mest kända publikationer, Handbuch der Physiologi-schen Optik (Handbook of Physiological Optics) [1], nämner han att ögat kontinuerligt flackar omkring inom synfältet. På så sätt kan betraktaren uppfatta omgivningen i sin helhet och identifiera var de intressanta områden finns. A. T. Duchowski klassar detta sätt att söka av sin omgiv-ning som en av de två huvuddelarna i hur man använder den visuella uppmärksamheten [2]. Han gav beteendet metaforen “var" och syftade till att man försöker hitta just var de intressanta områden i ens synfältet finns.

Den andra huvuddelen kallar Duchowski för "vad" och har sin grund i W. James teorier [3]. James hävdade att den visuella uppmärksamheten är besläktad med en persons förväntningar och tankar. Han menade att man med tanken kan påverka vad man ser och i viss mån även hur man ser det. För att förklara detta använde sig W. James bl a av tredimensio-nella figurer. I Figur 2.1 illustreras en sådan figur i form av en kub. Per-spektivet på kuben är till en början inte helt uppenbart och man kan till och med ha svårt att se vad det föreställer vid en hastig anblick. När man väl har fått bilden klar för sig, är det dock mycket enkelt att återskapa föremålet vid en senare anblick. Vilken vridningen som betraktaren ser kuben i är också något som helt kan styras och påverkas av ens tankar.

Genom att tänka sig kuben på ena eller andra vridningen kan kuben upp-fattas olika.

Figur 2.1 Tredimensionell kub

W. James "vad”-del riktar sig främst åt de utvalda intressanta områdena och hur dessa uppfattas av betraktaren. Men den har också en effekt på sökmönstret, "var", vilket A. L. Yarbus och även senare D. Norton och L. Stark kom fram till [4][5]. Yarbus kom med hjälp av sin studie fram till att en personers sökmönster på en given bild förändrades eller påver-kades beroende på de frågor som han ställde till försökspersonen. Norton och Stark som byggde vidare på Yarbus undersökningar, kom fram till att även utan ledande frågor så tenderade folk att fixera sin blick på vissa särskilda områden i en bild.

En annan intressant studie gjordes av M. Posner m fl som också identi-fierade två olika typer av visuell uppmärksamhet som de kallade oriente-ring och detekteoriente-ring [6]. Dessa två typer kan liknas med de två tidigare nämnda huvuddelarna var respektive vad. Man kom också fram till att den orienterande typen sker parallellt i hela synfältet och bestämmer nästa fixation medan den detekterande sker seriellt för de olika fixatio-nerna var och en för sig.

Sammantaget ovanstående teorier kan den visuella uppmärksamheten förklaras som ett cykliskt förfarande. Duchowski kallar modellen för "bottom-up" och han beskriver den i tre steg. I det första steget skannas hela synfältet/bilden av i låg upplösning och intressanta områden väljs ut. Därefter kommer ett område dra till sig uppmärksamheten och ögonen riktar in sig på just detta område. I det sista steget granskas det utvalda området i hög upplösning för att sedan åter börja om på första steget och välja ut ett nytt intressant område. Detta förfarande upprepas ända tills synfältet eller bilden i fråga ändras eller tas bort.

2.2 Ögat

Människan har ett totalt synfält på ungefär 180º horisontellt och 130º vertikalt [7]. En stor del av detta område är endast synligt för ett öga i taget och räknas till periferin. Man uppskattar att det stereoskopiska syn-fältet, synligt för båda ögonen, till ungefär 90º [8]. Som en intressant iakttagelse kan vårat synfält jämföras med en häst vars synfält är på nästan 360º. (Se Figur 2.2)

Figur 2.2 Människans horisontella synfält i jämförelse med hästens.

I det stereoskopiska synfältet har man ytterligare en begränsning som beror på den visuella skärpan för ögat. Längst in i ögat finns nämligen en liten grop i näthinnan som kallas fovea eller centralgropen. Denna grop har som syfte är att ge människan en skarp syn i blickriktningen tack vare tätt packade receptorer. På grund av foveas lilla storlek avtar skärpan snabbt när man avviker från ögats blickriktning och vid ungefär 5º har den relativa skärpan i stort sett helt försvunnit [9]. (Se Figur 2.3)

Figur 2.3 Diagram över skärpan för olika vinklar från blickriktningen

människa häst Stereoskopiskt synfält Monoskopiskt synfält 0° 10° 20° 30° 20% 40% 60% 80% 100% 0% Relativ synskärpa

2.3 Ögats rörelser

Exakta siffror för hastigheter, tidsintervall och andra ögonrelaterade mät-värden i detta avsnitt är hämtade från Eye Movements and Vision om inget annat anges [4].

Det finns en mängd olika rörelser som ögat använder för att söka av en bild. För att göra dessa rörelser möjliga har ögat en konstruktion som ger den sex grader av frihet [2]. Ögat rör sig alltså både med translationer och med rotationer i ögonhålan. De translationer som förekommer är dock väldigt små och är egentligen en rörelse som enbart uppstår vid rotationer och som en följ av att ögat inte är fixerat i sin ögonlob. De rörelser som styr blickriktningen kan delas in i två olika kategorier, sac-cader och fixationer. En saccad kännetecknas med dess stora och snabba rörelse och används för att hastigt förflytta blicken mellan t ex två olika objekt. Den andra kategorin, fixationer, är saccadernas motsats och består av stillastående eller väldigt långsamma och små rörelser. Dessa rörelser uppkommer då ögat fokusera på ett och samma objekt. Figur 2.4 illustrerar hur dessa rörelse växlar och hur de två olika rörelserna sam-verkar för att bilda ett sökmönster.

Figur 2.4 Saccader och fixationer växelvis.

2.3.1 Saccader

En saccad är den rörelse som ögat använder sig av vid förflyttning mellan två olika områden i synfältet. Vanligtvis är denna förflyttning av ögats blickriktning mindre än 20º men det förekommer förflyttningar på upp till 45º. Vid större förflyttningar sker dessa som regel som en serie av saccader med väldigt korta stopp emellan. En saccad är en väldigt snabb rörelse som har en vinkelhastighet på 200-450º/s och varar i ungefär 10-150 ms. Det är också en av de få ögonrörelser som kan ses på en person med blotta ögat.

2.3.2 Fixationer

En fixation är när ögat låst blicken på ett mindre område eller föremål för

saccad

sigt är svårt att fastställa med ett exakt intervall då detta till stor del påverkas av vilken situation som personen i fråga befinner sig i. Man kan dock statistiskt uppskatta dem till att vid normalt seende vara mellan 150 ms och 600 ms och att de upptar ungefär 95 % av den totala syntiden. Man har också fått fram att storleken på det område som blicken fokuse-rar på oftast är mindre än 10 bågminuter i diameter [10]. (1 bågminut = 1/60 grad)

Figur 2.5 En fixation innehållande microsaccader, drift och tremor.

Varje fixation kan i sin tur delas in i tre mindre rörelser, microsaccader, drift och tremor. Hur dessa tre rörelser kan växla i en fixation illustreras i Figur 2.5. En microsaccad är precis som de stora saccaderna hastiga för-flyttningar av blicken men i detta fall är amplituden avsevärt mycket mindre. Amplituden variera mellan 1-25 bågminuter och har en varaktig-het på 10-20 ms. De andra två rörelserna, drift och tremor, förekommer ofta ihop men ter sig helt olika. Drift är en rörelse som får ögat att lång-samt vandra i en riktning medan tremor är en rörelse som kan tolkas som darrningar eller vibrationer. Tremor är också de minsta rörelserna som ögat gör och uppkommer som en effekt av ögats inre upplösning, d v s dess receptorer och uppbyggnad [7].

2.3.3 Följande fixation

En följande fixation är den rörelse som uppstår när ögat fixerar blicken på ett objekt i rörelse. För att objektet skall kunna följas med blicken och betraktaren bibehålla skärpan bör dess vinkelhastighet inte överstiga 200º/s.

Precis som för en vanlig fixation har en följande fixation också de tre mindre rörelserna, microsaccader, vandringar och darrningar. Men i en följande fixation kan dessutom små saccader förekomma. Dessa sacca-der uppkommer som mindre korrigeringar för att bibehålla blicken på objektet och är mer förekommande vid höga vinkelhastigheter.

fixation microsaccad drift & tremor saccad saccad

K

D

ETEKTERING

AV

ÖGONRÖRELSER

Att detektera och registrera en människas ögonrörelser har länge varit en fängslande uppgift för många forskare. I detta kapitel beskrivs olika tek-niker som kan användas vid studier om människans ögonrörelser. Sist i kapitlet ges också en beskriving av Smart Eye som är det system som använts i detta arbete.

3.1 Historik

De första studierna om människans ögonrörelser gjordes genom enbart direkta observationer och utan några speciellt konstruerade hjälpmedel. Först vid sekelskiftet, 1800/1900, konstruerades en primitiv kontaktlins som kunde placeras direkt på ögat [11]. På kontaktlinsen satt ett litet spröt som pekade i samma riktning som ögats blickriktning. Under 1900-talet tog utvecklingen av olika hjälpmedel fart och redan under 1920-1900-talet bedrev Buswell helt kontaktfria studier på ögats rörelser [12]. Vid Buswells studier användes riktat ljus vars reflexer spelades in på film för att kunna studeras i efterhand.

Idag har teknikerna förfinats en hel del och det finns nu en mängd olika sätt att studera ögats rörelser på. I takt med att teknikerna har blivit bättre, billigare och i vissa fall även enklare, har också användningsom-rådena blivit många fler. Idag görs inte bara studier på ögat i sig, utan även på det ögat tittar på. Sådana studier kan vara intressanta för datain-samling till statistiska analyser för t ex hemsidor, butikshyllor och reklam. Även system där blicken agerar som styrutrustning till t ex mus-pekaren i en dator förekommer idag.

3.2 Tekniker

Det finns idag främst tre olika kategorier av tekniker för att registrera ögats rörelser, kontaktlinser, elektro-okulografi (EOG) samt

video-okulo-grafi (VOG). Var och en har sina fördelar och nackdelar. Vilken teknik som en studie bör tillämpa beror helt på syftet med studien.

3.2.1 Kontaktlinser

Att registrera ögats rörelser med hjälp av olika kontaktlinser är allt som oftast en relativt omständig och kostsam process. De olika linserna eller anordningarna som monteras direkt på ögat kräver i många fall lokalbe-dövning och kan oftast endast användas en kort tid. En av de vanligaste teknikerna med kontaktlinser kallas för magnetslinge-metoden (Scleral

search coil) och bygger på magnetisk induktion.

Figur 3.1 Magnetslinge-metoden. Silikonlins placerad på ögat.

Vid magnetslinge-metoden används en kontaktlins, innehållande två kop-parslingor, som placeras direkt på ögat (Se Figur 3.1). Försökspersonen placeras därefter med ögat i ett svagt magnetfält. Genom att mäta den spänning som uppstår via induktion i de två kopparslingorna, kan ögats rörelser registreras och beräknas. Genom att dessutom ändra magnetfäl-tets styrka, kan ögats eller spolarnas position bestämmas. Metoden ger en väldigt noggrann och högupplöst registrering av ögats rörelser och är en av de få teknikerna som kan registrera ögats minsta rörelser så som tremor och microsaccader. [2]

3.2.2 Elektro-okulografi (EOG)

Med elektro-okulografi (EOG) utnyttjar man ögats elektromagnetiska egenskaper och läser av variationer i den elektriska potentialen som uppstår då ögat rör sig. Förenklat kan ögat liknas med ett batteri med en pluspol ut genom ögat och en minuspol in bakom ögat. När ögat rör sig i någon riktning påverkar detta dess elektomagnetiska fält och genom att placera elektroder på vardera sida om ögat, kan dessa förändringar regist-reras och mätas (Se Figur 3.2). Den ena elektroden registrerar en högre

potential och den motstående en lägre potential. Variationerna i potentia-len kan sedan användas till att beräkna en blickriktning.

Figur 3.2 Elektro-okulografi (EOG). Placering av elektroder.

Teknikens stora fördel är att den är enkel och inte påverkas om personen bär glasögon eller kontaktlinser. Den stör inte heller försöks-personens syn eftersom inget främmande föremål måste appliceras på ögat. Dessvärre påverkas den lätt av variationer i elektrodernas omgiv-ning som t ex olika muskelrörelser i ansiktet. Tekniken har dessutom väldigt dålig noggrannhet på den uträknade blickriktningen. [2]

3.2.3 Video-okulografi (VOG)

Video-okulografi (VOG) är idag en väldigt utbredd och använd teknik och innebär att man med hjälp av videokameror eller andra liknande optiska sensorer registrerar ögats olika rörelser. Under årens lopp har det utvecklats en mängd olika metoder för att med bildbehandling erhålla en så exakt beräknad blickriktning som möjligt. Lokalisering av ögats natur-liga delar, så som pupill eller den kontrastrika kanten mellan iris och ögonvitan, är vanligt förekommande och kallas pupilldetektering respek-tive limbusdetektering. Limbusdetektering ger en något sämre noggrann-het för dess vertikala rörelser eftersom den övre kanten mellan ögonvitan och iris ofta kan vara delvis eller helt dold under ögonlocken. Pupillde-tektering ger samma noggrannhet för både vertikala och horisontella rörelser men kanten mellan pupill och iris är oftast svårare att detektera. [2]

För att ytterligare öka dessa två metoders precision är det vanligt att man utnyttjar ögats reflekterande egenskap. Med hjälp av externa ljuskällor kan fyra reflektioner skapas i ögat. Reflektioner kan sedan lokaliseras på ögat och utnyttjas i beräkningarna för att erhålla blickriktningen. De fyra

olika reflektionerna kallas för purkinjereflektioner och uppstår som en följd av ögats konstruktion. (Se Figur 3.3)

Figur 3.3 De fyra purkinjereflektionerna

En väldigt stor fördel med VOG är att den möjliggör registrering av en persons ögonrörelser utan att denne behöver komma i direkt kontakt med någon utrustning. System som använder sig av VOG på detta sätt kallas för remote eller kontaktfria system och finns i flertal olika varianter. I motsats till kontaktfria system finns de huvudmonterade VOG systemen. Dessa ger inte försökspersonen samma rörelsefrihet men upplösningen på ögat och noggrannheten på blickriktningen kan bli betydligt högre.

3.3 Smart Eye Pro 3.5

Smart Eye Pro 3.5 är ett system som möjliggör kontaktfri detektering av en persons ögonrörelser. Systemet körs på en standard PC och använder sig av kameror samt limbusdetektering för att registrera ögonens rörelser och position, (se avsnitt 3.2.3). Systemet kan ha 2-6 kameror och har en maximal samplingsfrekvens på 60 Hz. Utöver ögonens position och rörelser kan systemet även detektera hur pass slutna ögonlocken är samt huvudets position och rörelser. [13]

Systemet som använts i detta arbete är utrustat med tre kameror och två IR-lampor. De tre kamerorna är placerade framför föraren på bilens instrumentpanel (Se Figur 3.4). De två IR-lamporna är placerade på de två yttre kamerorna på vardera sida om ratten. Samtliga kameror är dess-utom utrustade med ett IR-filter, vilket tillsammans med IR-lamporna

inkommande ljusstråle 1 2 3 4 purkinjereflektioner

gör att systemet blir mer tolerant mot variationer i omgivningens normala ljussättning.

Figur 3.4 Placering av Smart Eyes kameror och IR-lampor i bilen.

3.3.1 Kalibrering och koordinatsystem

Innan utdata kan erhållas från Smart Eye måste samtliga kameror kali-breras och varje användare måste skapa en egen profil. Dessutom måste man definera ett koordinatsystem som ska gälla för systemets utdata. Vid kalibrering av kamerorna används en särskilt medföljande kalibrerings-platta. Plattan består av 54 svart-vita rutor vars storlekar är känt av Smart Eye. Genom att hålla plattan framför kamerorna kan systemet beräkna respektive kameras position och vinkel i förhållande till varandra. När kamerorna väl är kalibrerade kan en profil skapas. Detta görs genom att använda ett antal olika kamerabilder, tagna på ansiktet i olika vinklar. I dessa bilder markeras sedan tydliga kännetecken så som mungipor, ögon-bryn och näsborrar, (Se Figur 3.5). Punkterna bygger till slut upp en intern modell av användarens ansikte och som sedan används vid drift för att lokalisera position och riktning för huvud och ögon.

För att kunna använda Smart Eyes utdata till ett externt system är det viktigt att veta hur dess koordinatsystem förhåller sig till den fysiska omgivningen. Det finns därför tre olika sätt att definera detta koordinat-system på. Det första går ut på att man genom respektive kamera marke-rar ett antal noggrant utmätta punkter/koordinater i ett känt koordinatsystem. Utifrån dessa punkter kan systemet själv räkna ut res-pektive kameras position och vinkel. Koordinatsystemet som erhålls i SmartEye blir det samma som för de använda punkterna. I det andra alternativet placerar SmartEye sitt origo i en bestämd kamera. Z-axeln pekar i samma riktning som den valda kameran och xy-planet blir paral-lellt med kamerans bildplan. Det tredje och sista alternativet använder sig av den tidigare nämda kalibreringsplattan. Genom att placera plattan framför kamerorna kan Smart Eye automatiskt beräkna ett koordinatsys-tem. Origos position blir i detta koordinatsystem i kalibreringsplattans mittpunkt, z-axeln pekandes ut från plattan och xy-planet parallellt med plattan (Se Figur 3.6). Denna metod är också den som använts i detta arbete.

Figur 3.6 Kalibreringsplattans placering i bilen med de olika axlarna.

3.3.2 Utdata

Smart Eye kan beräkna huvudets och ögonens position samt riktning och skicka detta som utdata. Till dessa utdata kan dessutom ett kvalitets-värde beräknas. Värdet talar om tillförlitligheten på tillhörande data och kan vara användbart av andra system för verifiering av dess kvalite. Utöver detta kan man dessutom erhålla ett mått på hur mycket öga som är synligt. Varje utdata kan även stämplas med en tidsstämpel och bild-nummer. Användaren ges också valmöjligheten att spara ner de önskade utdata direkt till en fil på datorn eller få den skickad över ett nätverk via antingen UDP eller TCP. Den totala tidsfördröjningen på utdata uppges till att vara maximalt 50 ms. [13]

Eftersom SmartEye är ett komplext system med många rörliga delar finns det en mängd olika faktorer som kan påverka noggrannheten och

position, vinkel och fokus kan ha stor inverkan på utdata. Andra orsaker som också påverkar systemet är storleken på försökspersonens huvudrö-relser. Då ansiktet vrids bort från en eller flera kameror minskar syste-mets noggrannhet. Under optimala förhållanden uppges dock systemet ha en noggrannhet på upp till en grad [13].

3.3.3 Liknande system

Att registrera huvudrörelser och ögonrörelser med VOG är idag en väldigt populär teknik. Utöver Smart Eye finns det idag ett flertal andra mer eller mindre avancerade system. I stort sett alla dessa system bygger på samma grunder och tekniker som beskrivs i avsnitt 3.2.3. Dessutom varierar deras sammansättning av hårdvara endast marginellt. Man kan dock dela in deras fokuseringar på två olika kategorier. Den första kate-gorin är system som har som avsikt att beräkna en blickpunkt i ett givet plan som t ex en dataskärm. Dessa system kräver allt som oftast inte mer än tre kameror och försökspersonen vrider huvudet endast marginellt. System av denna kategorin kan bl a användas till analytiska studier eller som styrutrustning. Tobii är ett exempel på ett sådant system och består av datorskärm med en eller flera inbyggda kameror (Se Figur 3.7) [14]. Systemet utvecklas av Tobii Technology. Det lokaliserar användarens huvud och ögon samt beräknar var på skärmen personen tittar. Systemet kan användas av såväl forskare som lekmän och det finns även varianter för funktionshindrade som då med blicken kan styra en dator.

Figur 3.7 Tobii T60/T120 Eye Tracker

Den andra kategorin är system där man vill veta ögats exakta position och blickriktning i en 3-dimensionell miljö. Till denna kategorin räknas bl a Smart Eye och FaceLAB [15]. FaceLAB är ett system som är väldigt snarlikt Smart Eye och består precis som Smart Eye av två eller fler kameror samt en vanlig persondator, (Se Figur 3.8). FaceLAB bygger på i stort sett samma tekniker som Smart Eye och därmed likvärdig

pre-standa. Systemet utvecklas av Seeing Machines och bedrivs med nära samarbete med många biltillverkare och forskningsinstitut världen över.

Figur 3.8 Ett enkelt FaceLAB system.

Smart Eye Pro har trots många andra alternativ varit det enda system som använts för att detektera ögonrörelser i detta arbete. Detta eftersom VTI redan innan detta arbete påbörjades valt Smart Eye och integrerat det med deras simulator.

K

VTI-

SIMULATORN

VTI, Statens väg- och transportforskningsinstitut, har sedan deras första simulator stod färdig 1984 varit kända och respekterade i hela världen för deras banbrytande och högteknologiska körsimulatorer. Idag är de inne på sin tredje simulator, Simulator III. I detta kapitel beskrivs funktionen och uppbyggnaden av Simulator III.

4.1 Simulator III

Med Simulator III kan man på ett enkelt och säkert sätt studera allt från förarbeteenden till diverse teknisk utrustning, (Se Figur 4.1). Dessa studier kan dessutom spelas upp i en uppsjö av olika scenarion och miljöer och på så sätt utsätta försökspersonerna för likvärdiga situationer upprepade gånger. Dess moduluppbyggnad möjliggör också att olika typer av fordon, så som tåg, bil och lastbil, kan simuleras i en och samma simulator. [16]

För att på så trovärdigt sätt som möjligt återspegla ett hjulgående fordon måste en mängd olika rörelser och accelerationer simuleras (Se Figur 4.2). Dessa kan delas in i två olika grupper. Den första gruppen har till avsikt att simulera fordonets rörelser i förhållande till underlaget. På VTI görs detta med hjälp av ett vibrationsbord som kan få bilen att kränga i ±6º och tippa i ±3º. Bordet gör det också möjligt att förflytta bilen ±6 cm i vertikal och longitudinell ledd i förhållande till skärmarna. Den andra gruppen av rörelser har som syfte att simulera de accelerationer som en förare känner av vid exempelvis ett filbyte eller en inbromsning. Detta kan simuleras på två olika sätt.

Figur 4.2 Rörelser för kraftsimulering i körsimulator.

En lösning är att luta hela simulatorn och på så sätt utnyttja gravitatio-nen för att simulera en horisontell kraft. Denna teknik är väldigt enkel och kräver inte så stort utrymme men har en stor nackdel vad gäller rea-lismen. En människas balanssinne känner till viss del av denna lutning trots att hela omgivningen i form av skärm och kaross roteras med.

Det andra alternativet är att bokstavligen förflytta hela simulatorn i det horisontella planet, s k linjär förflyttning. Detta skapar horisontella krafter som för föraren känns väldigt realistiska och naturliga. Det finns dock en nackdel även med detta system och det är när det gäller att simu-lera långvariga accesimu-lerationer. Som exempel kan vi ta en bil som ska accelerera från 0 till 100 km/h. Detta skulle kräva en väldigt lång hori-sontell förflyttning av simulatorn och en sådan förflyttning finns det oftast inte utrymme för. Därför lämpar sig dessa system bara till att simu-lera kortvariga krafter.

Simulator III utnyttjar en kombination av dessa två lösningar. Den linjära förflyttningen används oftast till att simulera krafter i sidled, vid t.ex. fil-byten och hastiga väjningar, medan för att simulera långvariga krafter så

tive framåt. Den linjära sidoförflyttningen går även att ändra till att simu-lera krafter i färdriktningen om detta skulle vara mer önskvärt. En egen konstruktion där hela simulatorn roteras 90º i det horisontella planet gör detta möjligt. [16]

4.1.1 Systemet

Simulator III innehåller ett antal delsystem som vart och ett har egna ansvarsområden och uppgifter. Enkelt förklarat består simulatorn av ett huvudsystem och fyra mindre system (Se Figur 4.3). Varje delsystem representeras av en eller flera datorer som alla är sammankopplade över ett och samma nätverk.

Huvudsystemet består av en vanlig dator, Simuleringsdatorn, vars uppgift är att styra och samordna hela simuleringen efter definierat sce-nario. Datorn lagrar även en fordonsmodell för det simulerade fordonet och en rörelsealgoritm som används vid beräkning av nya tillstånd och händelser.

För att Simuleringsdatorn ska kunna styra och beräkna simuleringen måste huvudsystemet känna till det simulerade fordonets aktuella rörel-ser. Detta erhålls från ett av de mindre delsystemen. Detta system består av en specialbyggd dator som registrerar fordonets signaler som exem-pelvis rattens läge, hastighet och blinkers. Signalerna tolkas och skickas till Simuleringsdatorn via nätverket. Att signalerna skickas via nätverket gör det också möjligt att enkelt lägga till fler delsystem och låta dessa generera insignaler till huvudsystemet. I detta arbeta utnyttjades denna möjlighet för att länka samma Smart Eye-systemet med simulatorn.

Simuleringsdatorn genererar i sin tur olika utsignaler som tas om hand i de tre återstående delsystemen för rörelse, ljud och grafik. I dessa tre system spelas simuleringsförloppet och de olika händelserna upp för föraren som i sin tur kan skapa nya insignaler genom sina handlingar.

Figur 4.3 Signalflödet i Simulator III med Smart Eye. Simulerings-Rörelse Ljud Grafik Smart Eye datorn Fordonets signaler Insignaler Utsignaler

Detta arbeta berör i stort sett endast Grafiksystemet och därför kommer de andra systemen inte att beskrivas mer i detalj i denna rapport.

4.2 Grafiksystemet

Grafiksystemet i Figur 4.3 har som namnet antyder hand om den gra-fiska biten i simulatorn och beräknar utgående från simuleringsförloppet vad som ska visas på duken och i backspeglarna. Systemet består i själva verket av ett flertal mindre enheter som körs parallellt. (Se Figur 4.4) För att möjliggöra detta har VTI utvecklat en egen grafikmotor som kallas

Visual och körs parallellt på separata datorer, även kallat kanaler. Dessa

kanaler visualiserar den simulerade miljön i samtliga backspeglar och på en svängd duk framför fordonet. För varje backspegel används en kanal och till synfältet framåt används tre kanaler på vardera drygt 40º. Dessa tre kanaler överlappar varandra något för att undvika glapp i bilden samt göra övergången så mjuk som möjligt. Totalt resulterar detta i ett synfält framåt för föraren på ungefär 120º. Eftersom duken i Simulator III är svängd istället för veckad som tre plana dukar, kan inte bilden projiceras på vanligt vis utan en förvrängning måste göras. Till detta används en separat enhet som beskär och skalar om de tre kanalerna så att bilden kan projiceras på duken utan att se onaturlig ut.

Figur 4.4 Grafiksystemet

Som tidigare nämt är Visual en grafikmotor som är utvecklad av VTI själva. Denna motor körs på samtliga datorer som på ett eller annat sätt ska visualisera den grafiska miljön. Därför kommer även visualiseringen av ögonrörelser i detta arbeta kräva ett nära sammarbete med Visual för att fungera. Skalning Visual Bild 1 Bild 2 Bild 3 Backspegel 1 Backspegel 2 Backspegel 3 Dator 1 Dator 2 Dator 3 Dator 4 Dator 5 Dator 6 datorn Simulerings-Signaler från

4.3 Visual

Grafikmotorn Visual är den applikation som beräknar och visualiserar den simulerade omgivningen för föraren (Se Figur 4.5). För att kunna göra detta måste förarens position i den simulerade världen vara känd. Till sin hjälp använder sig Visual av tre olika koordinatsystem vilka till-sammans gör det möjligt att beräkna var föraren befinner sig i förhål-lande till sin omgivning. Två av dessa koordinatsystem är helt vanliga system som använder sig av x, y och z för att ange en position. Dessa är båda linjära och ortogonala koordinatsystem och det första kallas för Open GL-koordinater (GLmap). Systemet är baserat på standard Open GL-koordinater med x- och y-axeln i skärmens plan (höger respektive upp) och z-axeln pekar ut ur skärmen (bak). GLmap är ett världskoordi-natsystem och används för globala koordinater innan utritning.

Figur 4.5 Exempel på hur omgivning visas för en förare med hjälp av Visual.

Som komplettering till GLmap har man dessutom ytterligare ett system som kallas för Wxyz. Precis som GLmap är detta system också linjärt och ortogonalt men istället avsett för att användas som lokala koordinater för objekten. Till skillnad från Open GL-koordinater är detta system definie-rat med x-axeln som framåt (in i skärmen), y-axeln till vänster och z-axeln pekar uppåt.

Det tredje och sista koordinatsystemet är det system som används vid själva skapandet av en vägsträcka. Detta koordinatsystem kallas för väg-koordinater eller srh-väg-koordinater. Koordinatsystemet är varken linjärt eller ortogonalt, utan baseras istället på vägens kurvatur. S-variabeln motsvarar sträckan i vägens riktning medan r-variabeln motsvarar

för-flyttning i sidled vinkelrätt mot s-axeln (Se Figur 4.6). H-axeln är den enda axel som är konstant och pekar alltid uppåt i samma riktning som y-axeln i standard Open GL-koordinater. Fördelen med att använda srh-koordinater istället för vanliga xyz-srh-koordinater är att samtliga objekt som placeras ut längs en vägsträcka automatiskt följer vägen vid en föränd-ring av dennes kurvatur. På så sätt kan en variationsrik miljö längs väg-banan skapas samtidigt som den enkelt kan återanvändas på andra vägar. Koordinatsystemet gör det dessutom möjligt att enkelt koppla samman en vägsträcka med en annan.

Figur 4.6 SRH-koordinater

Gemensamt för alla tre koordinatsystem är deras sätt att hantera objekts rotationer. Dessa görs med Euler-vinklar enligt principen med heading, pitch och roll. Detta innebär att samtliga rotationerna görs runt koordi-nataxlarna i en bestämd ordning. I Visual görs dessa i ordningen roll, pitch, heading, där roll är en rotation kring z-axeln, pitch en rotation kring x-axeln och heading en rotation kring y-axeln (Open GL-koordina-ter).

Längs en verklig vägsträcka kan det förekomma en mängd olika objekt som tillsammans med vägen och trafiken skapar en komplett miljö. Denna miljö vill man givetvis återskapa så realistiskt som möjligt i simu-latorn och till det krävs det en mängd olika modeller. I Visual finns det därför ett stort bibliotek att tillgå med skyltar, vägräcken, fordon, djur o s v. För att hantera dessa modeller använder sig Visual av objekt som kallas för basobjekt (BaseObject). Ett basobjekt består huvudsakligen av en referens till en modell i biblioteket och ett läge med en position samt de olika rotationerna. Dess position är inte bara angivet i srh-koordina-terna, utan även i Open GL-koordinater, vilket avsevärt underlättar och effektivisera utritandet av objekten. Basobjekten delas in i två katego-rier, statiska och dynamiska, (Se Figur 4.7).

Till den statiska kategorin räknas vanliga basobjekt och repeterbara objekt (RepeatObject). Dessa objekt har den egenskapen att deras läge i världen är konstant under en hel simulering. Ett repeterbart objekt är i

S

R S

par eller liknanden gör det betydligt enklare att skapa nya vägsträckor. Till den dynamiska kategorin räknas de dynamiska objekten (Dynamic) som i sin tur är uppdelad i två typer, animerade (MeshAnimationObject) och fordon (Vehicle). Dessa objekt har den egenskapen att deras position och rotation kan ändras under en simulering och på så sätt skapa rörelse i den simulerade miljön. De animerade objekten har dessutom egenskapen att deras utseende förändras med tiden och används bl a till att simulera en älg som går över vägen.

Figur 4.7 Klassdiagram för de olika objekten.

För att definiera hur en omgivning längs en vägsträcka ska se ut används XML-filer. I dessa filer kan användaren ange de olika objekten som element och deras egenskaper som t ex srh-koordinater och synlighet som attribut. XML-filerna kan dessutom kopplas samman i en trädstruk-tur genom att istället för ett objekt ange en annan xml-fil som ett ele-ment. Detta möjliggör enkel och effektiv återanvändning av redan skapade kombinationer med objekt.

Vid uppstart av Visual läses XML-filerna in och genererar en motsva-rande och skräddarsydd scengraf för hela miljön. Tack vare utnyttjandet av srh-koordinatsystemet kan scengrafen hållas väldigt enkel och s-värdet används fördelaktigt vid beräkningen om objekts synlighet. Ett siktavstånd relativt det simulerade fordonets positionen jämförs med varje objekts s-värden och avgör om objektet är synligt eller ej.

De dynamiska objekten inkluderas dock inte i scengrafen utan sköts istäl-let av en separat hanterare (VehicleMgr). Denna hanterare ser till att de dynamiska objektens läge uppdateras kontinuerligt och läggs till eller tas bort vid rätt tillfälle. Eftersom det är Simuleringsdatorn och inte Visual som styr simuleringen måste denna information erhållas via nätverket. Till sin hjälp har därför Visual en separat tråd som lyssnar av nätverks-trafiken (sker med UDP) och tar emot denna information från Simule-ringsdatorn. Informationen är uppdelad i olika paket och innehåller all nödvändig data som Visual behöver för att kunna visualisera det simule-rade förloppet.

BaseObject

Dynamic RepeatObject

Vehicle MeshAnimationObject

Genom att använda Visual som en grund och istället implementera själva visualiseringen av ögonrörelser som en tilläggsmodul till Visual undviks mycket dubbelt arbete. Viktiga funktioner som den grafiska upprit-ningen och kommunikation till Simuleringsdatorn finns redan implemen-terat i Visual. Dessutom kan paketen som Visual erhåller enkelt utökats till att även innehålla ögonrörelsedata från Smart Eye.

K

P

ROBLEMIDENTIFIERING

För att uppnå det utsatta målet med tillägsmodulen måste mindre och mer lätthanterliga delproblem identifieras. I detta kapitel beskrivs de sex delproblem som identifierades och bedömdes ha en stor inverkan på utvecklingen av det slutgiltiga systemet och dess prestanda. Till varje delproblem presenteras också en eller flera lösningar och hur respektive problem valdes att hanteras. Sist i kapitlet ges också en kort diskussion om andra idéer och lösningar som provats under arbetets gång och bidra-git till systemets slutgiltiga design.

5.1 Noggrannhet

Ett av de mest betydande delproblemen är att bibehålla en så hög nog-grannhet som möjligt på Smart Eyes utdata genom hela systemet. Felak-tig data kan resultera i en missvisande visualisering och orsaka fel som annars kan vara svåra att se som användare. Dessutom kan felen resul-tera i felaktiga sannolikhetsvärden för föremål (se avsnitt 6.3.3).

5.1.1 Problemanalys

Det finns två moment som som är särskilt kritiska och har en stor inver-kan på noggrannheten. Det första momentet är själva transformeringen från Smart Eyes koordinatsystem (se avsnitt 3.3.1) till den simulerade miljöns koordinatsystem (se avsnitt 4.3). Förhållandet mellan dessa två koordinatsystem är inte konstant då simulatorns vibrationsbord används (se avsnitt 4.1). Vibrationsbordet simulerar små rörelser och gör att bilen förflyttar sig i förhållande till den simulerade miljön. Dessa små förflytt-ningar kan inte erhållas från simulatorn och eftersom Smart Eye-syste-met är monterat i bilen, kommer dessa förflyttningar orsaka såväl translationsfel som rotationsfel vid transformering. En annan sak som också påverkar Smart Eyes koordinatsystem är kalibreringarna. Dessa kan skilja sig något från kalibrering till kalibrering och förändra det av Smart Eye använda koordinatsystemet.

Det andra momentet som kan orsaka noggrannhetsfel är vid filtreringen av signalerna (se avsnitt 6.3.2). Fel som uppkommer här kan variera väldigt mycket beroende på respektive filters filtervärden. Olämpliga eller rent av felaktiga filtervärden kan filtrera bort korrekta data och ge upphov till stora noggrannhetsfel.

5.1.2 Problemhantering

För att hantera och representera de fel och avvikelser som kan upp-komma vid transformering och filtrering av Smart Eye-data, implemente-rades systemet med en variabel med namnet GazeError. Variabeln är en felmarginal som användaren dynamiskt kan ställa in och anger hur många grader som systemets mottagna och behandlade blickriktning kan avvika från den verkliga. Vid detekteringen och beräkningen för att avgöra om en förare tittar på eller vid sidan om ett föremål kan felmargi-nalen användas för att definiera en gråzon. I denna gråzon kan föremål som är väldigt nära blickriktningen upptäckas och ge systemet en möjlig-het att behandla dessa separat. Hur systemet utnyttjar detta beskrivs i avsnitt 6.3.3.

För att undvika variationer på Smart Eyes koordinatsystem mellan de olika kalibreringarna konstruerades också en särskild rigg till Smart Eyes kalibreringsplatta. Riggens konstruktion gjorde det möjligt att enkelt placera plattan på i stort sett samma position och vinkel mellan de olika kalibreringarna.

5.2 Tidsförskjutningar

Ett delproblem som är svårt att göra något åt i ett realtidssystem är de tidsförskjutningar som förekommer mellan systemets ingående delar. Med tidsförskjutning avses i detta fall den tidsskillnad som bildas mellan Smart Eye-data och simulatordata.

5.2.1 Problemanalys

Det finns främst två typer av tidsförskjutningar att reflektera över här, rörliga och fasta. Den rörliga tidsförskjutningen orsakas av filtervärden som t ex filtrens fönsterstorlek och kan därför variera beroende på valda värden (se avsnitt 6.3.2). De fasta tidsförskjutningarna är däremot i stort sett konstanta och uppkommer som en effekt av simulatorns sekventiella förlopp.

För att kunna uppskatta den fasta tidsförskjutning är man tvungen att addera samtliga tidsfördröjningar under en hel cykel. Med en cykel

och slås samman med ett nytt tillstånd. Tidigare tester på simulatorn, gjorda av VTI själva, har visat att det förekommer en tidsfördröjning på 40-50 ms från det att ett tillstånd sätts tills det att bilden visas på skär-marna. Eftersom det är denna bild som föraren tittar på blir man tvungen att addera dessa 50 ms med den tidsfördröjning som uppstår i Smart Eye-systemet. Enligt specifikationerna är även denna på upp till 50 ms. Detta resulterar i att den totala fasta tidsförskjutningen kan bli så stor som 100 ms (Se Figur 5.1). För att erhålla den totala tidsförskjutningen för hela systemet måste man dessutom addera den rörliga.

Figur 5.1 Tidsfördöjningar i systemet

5.2.2 Problemhantering

Tidsförskjutningarna som uppstår i simulatorn är väldigt svåra att behandla på ett smidigt sätt. I dagsläget finns det ingen gemensam klocka som kan användas i simulatorns alla ingående delar och tidsstämpla dess data. Systemet tvingas istället att jämföra Smart Eye-data med aktuell simulatordata som kan skilja sig från den som visades för föraren då Smart Eye gjorde sin avläsning.

För att få en förståelse och insikt i hur detta påverkar systemet under körning kan man teoretiskt skapa ett värsta scenario där denna tidsför-skjutning har som störst inverkan på systemet. Man vill alltså veta när och var som den simulerade miljön förändras för föraren som mest. Man inser enkelt att höga hastigheter bidrar till större förändringar av den simulerade miljön än vad låga hastigheter gör. Man inser också att objekt som är nära eller rakt ut på sidorna rör sig i avsevärt högre vinkelhastig-heter än objekt långt bort eller rakt fram.

Ett västa scenario för systemet blir därför då det simulerade fordonet rör sig i hög hastighet samtidigt som föraren tittar på ett föremål som befin-ner sig nära och vid sidan. Om föremålet dessutom är ett mötande fordon som rör sig i motsatt riktning blir felet och inverkan ännu större på grund av den ökade hastigheten mellan förare och objekt.

En särskild kompensering för fel orsakade av tidsförskjutningar ansågs dock inte vara nödvändig i denna första version av systemet. Tidsperio-den för scenariot ovan bedömdes vara extremt kort, samt totalt uppta en

40-50 ms

< 50 ms Smart Eye

Simulerings-datorn

väldigt liten del av den totala blicktiden under körning. Därför ansågs felet inte vara stort och det kunde istället inkluderas i felmarginalen som nämndes i avsnitt 5.1. Användaren bör dock ha kännedom om felets före-komst och i vilka situationer som det visar sig.

5.3 Visualisering

Vid visualiseringenav blickriktningen är det viktigt att denna görs på ett sätt som underlättar för användaren och presenterar informationen på ett enkelt och tydligt sätt.

5.3.1 Problemanalys

Förarens blickriktning som erhålls från Smart Eye kan komma att avvika från den egentliga blickriktningen och ge upphov till så väl små vibratio-ner som hastiga och stora förflyttningar. Dessa avvikelser gör det svårt för användaren att följa förarens blick och bör om möjligt dämpas eller helt filtreras bort. De filtreringar och dämpningar som görs bör också visualiseras för användaren för att ge en medvetenhet om hur de påver-kar beräkningarna.

5.3.2 Problemhantering

Som utgångspunkt till hur visualiseringen skulle se ut, användes en film-sekvens hämtad från ett arbete av Walter Piechulla [17]. I detta arbete undersökte W. Piechulla möjligheterna för användning av moderna eyetracking system i körsimulatorer och med vilken noggrannhet som kan uppnås med dessa. Precis som i detta arbete användes Smart Eye för att registera ögonrörelserna. I filmsekvensen kunde man se att W. Piechullas system visade hela den simulerade miljön ur förarens perspek-tiv. Detta ansågs till en början vara en mycket bra och tydlig lösning som också implementerades i systemet. Det visade sig dock att denna lösning inte var tillräcklig för simulatorn på VTI. Synfältet i VTI:s simulator är väldigt långsmalt med ett totalt horisontellt synfält på 120º. Att visa hela synfältet på en vanlig datorskärm resulterar i en väldigt låg upplösning på de olika objekten i miljön. Därför implementeras systemet med ett synfält som istället följer förarens huvudrörelser. På så sätt kunde visua-liseringen göras på en skärm med rimliga proportioner och ändå täcka hela simulatorns synfält (se avsnitt 6.3.4). Vid valet av dessa proportio-nerna kan dessutom människans visuella egenskaper vägas in (se avsnitt 2.2 och 2.3).

För att visualisera förarens blick använde W. Piechulla en röd punkt. Punkten markerade var i vyn som föraren fixerade sin blick. Eftersom

punkten inte visades under den tid som ingen fixation kunde bestämmas. Denna egenskap tillsammans med att punkten hoppade väldigt snabbt gjorde det svårt att följa förarens blick. För att underlätta detta för använ-daren, implementerades systemet med ett filtreringssteg (se avsnitt 6.3.2). Vid filtrering av ögonrörelser används ofta ett medianvärde. Denna filtrering bibehåller ögats hastiga rörelser på ett skonsamt sätt, samtidigt som det filtrerar bort variationer och mätfel. Vid implemente-ring av systemet valdes trots detta att filtrera med ett aritmetiskt medel-värde. Det aritmetiska medelvärdets effekt på ögonrörelser blir att saccader visualiseras mjukare och aningens långsammare. De mjukare rörelserna ansågs göra det lättare för användaren att följa förarens blick. Filtreringen har dock en stor nackdel. Om användaren angett ett allt för stort fönster för filtret kan detta leda till förlust av korta fixationer.

Visualiseringen av de föremål som identifierats som möjliga mål för blicken, gjordes i W. Piechullas system med en textremsa. Textremsan var placerad uppe i skärmens vänstra hörn och visades för varje fixation. Nackdelen med denna lösning var att man som användare inte hann läsa vilket eller vilka föremål som identifierades. Användaren tenderade att följa förarens blick i miljön istället för att läsa texten. En bättre lösning vore att direkt i miljön markera de identifierade föremålen. Systemet implementerades därför med en utritningsprocess för varje föremåls omslutande volym som möjliggjorde detta. För eventuell loggning av data implementerades även en textbaserad visning på de identifierade föremålen (se avsnitt 6.3.4).

5.4 Överbelastning

Eftersom systemet är ett realtidssystem som dynamiskt ska visualisera en förares blickriktning är det av stor vikt att systemet inte blir överbelastat och en låg uppdateringsfrekvens erhålls. En sådan överbelastning kan exempelvis uppkomma då det definierats många föremål på en och samma vägsträcka.

5.4.1 Problemanalys

En låg uppdateringsfrekvensen kan leda till förlust av blickdata och att kritiska fixationer på föremål missas helt eller delvis av systemet. Det kan också leda till att själva visualiseringen för användaren inte fungerar som planerat.

5.4.2 Problemhantering

Överbelastning för systemet är mest troligt att uppkomma då det tvingas utföra sina beräkningar på för många föremål. Gränsen för hur många

föremål som systemet klarar av är helt beroende på prestanda på den dator som systemet körs på. Denna prestanda kommer troligtvis ökas med tiden och därför implementerades ingen maxgräns för hur många föremål som får deklareras i ett och samma intervall. Istället implemente-rades systemet för att uppnå en så hög maxgräns som möjligt. För att uppnå detta använder sig systemet av selektiv sortering samt separation av statiska och dynamiska föremål, (se avsnitt 6.3.3). Den selektiva sor-teringen räknar snabbt ut vilka föremål som för tillfället är inom synhåll och begränsar antalet för vidare beräkningar. Separationen mellan de två olika typerna av föremål gör att systemet snabbt och enkelt vet vilka som behöver uppdateras från bildruta till bildruta.

5.5 Kalibrering

Vid användning av system som Smart Eye Pro kan det förekomma fel som helt eller delvis beror på felaktiga kalibreringar. Dessa fel kan vara svåra att upptäcka och orsaka stora felberäkningar.

5.5.1 Problemanalys

En felaktig kalibrering av Smart Eye Pro kan påverka det definierade koordinatsystemet i bilen (se avsnitt 3.3.1). Koordinatsystemets origo och axlar kan variera mellan kalibreringarna samt påverkas av vilken kalibreringsmetod som används. Även om samma kalibreringsmetod används kan smärre förändringar av koordinatsystemet förekomma. Det kan därför tänkas bli nödvändigt att kompensera mot dessa avvikelser. Ett försök som genomfördes i början av arbetets gång, där en försöksper-son tittade på nio noggrant utmätta punkter, visade att Smart Eye tende-rade att förvränga dess utdata något. D v s blickriktningen registretende-rades fortfarande inom ett litet och samlat område men avvek från det exakta och verkliga värdet. Avvikelse blev också större då huvudet vreds bort från en eller flera kameror och var av varierande storlek för olika Smart Eye profiler.

5.5.2 Problemhantering

För att hantera olika positioner av Smart Eyes origo i förhållande till bilen anges denna position i en setup-fil, (Se Appendix A). Positionen läses in vid programmets uppstart och används som utgångsläge. Detta läge är dessutom implementerat för att kunna ändras när som helst under körning eller efter en omkalibrering av Smart Eye, (Se Appendix B). Fel och avvikelser i ögondata som helt orsakats av Smart Eyes

kalibre-specifikationer och uppmätta och angivna i de specificerade koordinat-systemen.

5.6 Flexibilitet

Då det inte existerar ett liknande system som är offentligt och redan beprövat vad gäller utformning och funktionalitet, ställer detta stora krav på att systemet är flexibelt. Ett flexibelt system ger användaren möjlig-het att prova sig fram till vilka inställningar som är bäst för den aktuella simuleringen.

5.6.1 Problemanalys

Med flexibelt system avses i detta sammanhang att systemet är definie-rat med ett tydligt och minimalt gränssnitt mot Visual, samt att interna variabler enkelt kan ändras av användaren. Det senare är också av intresse för att kunna ta reda på vilka egenskaper på systemet som är önskvärda och vilka värden som är rimliga. En annan viktig egenskap som bör gälla för systemet berör de föremål som är av intresse inför en studie. Dessa ska enkelt kunna väljas och ändras efter behov och önske-mål.

5.6.2 Problemhantering

Flexibiliteten i systemet är i största del baserad på möjligheten att ändra de interna variablerna. Så gott som samtliga variabler har fått denna möj-lighet vilket gör att systemets funktionalitet i stort sett helt kan bestäm-mas av användaren. Vid uppstart initieras samtliga variabler med fördefinerade värden som dock enkelt kan omdefinieras av användaren i en textbaserad setup fil, (Se Appendix A). Även vid drift kan de flesta inställningar ändras med enkla knapptryckningar.

Själva deklareringen av de föremål som är av intresse görs med Visuals redan befintliga XML-kod. Här kan även de olika föremålens egenska-per bestämmas med en rad olika attribut, (se avsnitt 6.3.1).

5.7 Diskussion

Innan den slutgiltiga implementationen fastslogs, diskuterades många andra intressanta idéer och lösningar. Detta gällde inte bara de problem som är listade ovan utan även idéer kring andra mindre problem diskute-rades.

En av de tidigaste idéerna som också provades berörde själva visualise-ringen av blickriktningen. Till en början skulle blickriktningen visas som

en enkel stråle eller linje i världen. Linjen utökades snabbt till att istället vara en lång smal kon med sin spets i ögonens position. Tanken var att konen skulle symbolisera och visa det område där föraren troligen tit-tade. Lösningen visade sig dock vara väldigt otydlig i en tredimensionell miljö. Placeringen av betraktarens kamera hade en allt för stor inverkan på detta och en mängd olika placeringar fick provas. Vissa placeringar fick betraktade föremål att försvinna ut ur bild, medan andra helt enkelt blev svårtolkade. Konen kunde dessutom täcka mer än ett föremål åt gången och det gick inte att avgöra vilket av föremålen som föraren tittade på. Utöver lösningen med konen diskuterades även ett tvådimen-sionellt alternativ. Lösningen gick ut på att visa fordonet och vägen sett uppifrån och visualisera blicken med en linje från fordonet. Detta ansågs vara en allt för enkel lösning och ingen implementering gjordes.

Ett annat problem som också är värt att nämna är beräkningen av ett föremåls sannolikhetsvärde. Detta kan beräknas på en mängd olika sätt och i det slutgiltiga systemet baseras värdet enbart på den aktuella blick-riktningen. Under utvecklingen väcktes därför en idé om att istället beräkna värdet över en viss tidsperiod. Genom att låta tiden påverka hur högt föremålets sannolikhetsvärde blev kunde föremål som detekterats under en längre tid få högre värde än andra. Idén går hand i hand med många olika teorier för fixationsanalys och eventuellt kan någon av dessa användas. Nackdelen med dessa teorier är att de allt som oftast inte är konstruerade för realtidssystem. Därför ansågs en utveckling av en sådan algoritm allt för komplext och utanför ramarna för arbetet. Endast mindre försök till en sådan beräkning gjordes, men dock utan lyckat resultat. Om man bortser från problemet med tidsförskjutningar anses samtliga problem som listas här i kapitel 5 hanterats på ett tillfredsställande sätt och implementerats i det slutgiltiga systemet, Gaze Tracker.

K

G

AZE

T

RACKER

För att länka samman Smart Eyes utdata med den simulerade miljön och sedan visualisera hur, var och på vad en förare tittar, utvecklades och implementerades Gaze Tracker. I detta kapitel beskrivs systemets arki-tektur och de olika modulernas ansvarsområden. Kapitlet beskriver också den process som Gaze Tracker arbetar efter för att möjliggöra den slut-liga visualiseringen av förarens blick.

6.1 Arkitektur

Gaze Tracker är inte ett separat och fristående program utan konstruerat som en tilläggsmodul till VTI:s grafikmotor Visual (se avsnitt 4.2). Sys-temet bygger på en enkel konstruktion och består endast av två moduler,

Gaze Manager och Smart Eye samt en objekthierarki, Gaze Items (Se

Figur 6.1). Modulerna har tydligt definierade gränssnitt och med klart separerade uppgifter i systemet. Gaze Manager-modulen är den modul som styr och kontrollerar hela systemet under körning. All kommunika-tion mellan Visual och Gaze Tracker sker genom denna modul. Modulen är också ansvarig för vad som ska visualiseras på skärmen. Vid visualise-ringen tar den hjälp av Smart Eye-modulen vars uppgift inte bara är han-tering av Smart Eyes data utan också visualiseringen av denna data. I objekthierarkin Gaze Items, representeras de olika föremål som använda-ren anser vara intressanta i sin aktuella studie. Det är för vart och ett av dessa föremål som ett värde relativt blicken ska beräknas.

Figur 6.1 Gaze Trackers uppbyggnad.

Gaze Manager Smart Eye Gaze Items Visual Gaze Tracker