chroma key - linköping universityweber.itn.liu.se/~karlu20/courses/tnm094/reports/... · rapporten...

Linköpings universitet | Insitutionen för teknik och naturvetenskapKandidatarbete |Medieteknik

Vårterminen 2016 | LiU-ITN-TEK-G--16/013--SE

Chroma KeyAnvändarupplevelse med chroma keying i realtidför besökare till Visualiseringscenter C

Karin ReidarmanLovisa HasslerHenrik NilssonSimon HedlundCristoffer SärevallFilip KantedalAdrian Palmquist

Examinator: Karljohan Lundin Palmerius

Linköpings universitetSE-581 83 Linköping

013–28 10 00, www.liu.se

Sammanfattning

Rapporten beskriver ett projektarbete inom kursen Medietekniskt kandidatprojekt vid Linköpings uni-versitet. Målet med projektet är att utveckla en chroma key-station för Visualiseringscenter C i Norr-köping där besökarna till centret kan se sig själva i olika virtuella miljöer. Tillhörande stationen finnsen surfplatta där användarna kan ta skärmdumpar av den bild som producerats av stationen medansanvändaren står framför kameran. Användarna kan via plattan dela sin bild på sociala medier ellerhämta hem för privat bruk.

För att separera användaren av stationen från bakgrunden har Microsofts Kinect-kamera och Kinectsofficiella SDK, Software Development Kit använts. De virtuella miljöerna som användaren kan se sigsjälv i har skapats med hjälp av Urho3D som är ett grafik-API, Application Programming Interfa-ce. Kommunikationen mellan applikationen på surfplattan och datorn som driver Kinecten sker överwebsockets. Bilderna som tas lagras på molntjänsten Firebase.

Utvecklingen av stationen har planerats utifrån den agila utvecklingsmetoden scrum och de olikadelarna av systemet har utvecklats under så kallade sprints.

i

Innehåll

Sammanfattning i

Figurer v

Tabeller vi

Typografiska konventioner och ordlista vii

1 Inledning 11.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Relaterat arbete 32.1 Chroma Keying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Microsoft Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Realtidskommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Databaslösningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Tredjeparts API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Arbetssätt 103.1 Arbetsmetodiken scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Ansvarsområden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Rutiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1 Versionshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.2 Dokumentation av kod och dokument . . . . . . . . . . . . . . . . . . . . . 11

3.2.3 Kodgranskning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.4 Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Projekthantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

ii

INNEHÅLL iii

3.3.1 Planering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.2 Kravhantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.3 Kundkontakt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Metod 144.1 Systemarkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 Kinectprogrammet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.1 Hårdvara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.2 Utvecklingsplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.3 Chroma Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.4 Renderingsmotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.5 Boost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.6 OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Surfplatta och applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.1 Operativsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.2 Utvecklingsplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.3 Användargränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.4 Bildhantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 Webbgränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4.1 Administrativt webbgränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.2 Webbgränssnitt för användare . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.3 IP-konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.5 Kommunikation mellan systemdelar . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.5.1 Realtidskommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.5.2 Databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Resultat 235.1 Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2 Miljöerna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Resulterande systemutveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Analys och diskussion 296.1 Arbetssätt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2 Systemutveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.3 Teknik och utvecklingsverktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3.1 Chroma key station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3.2 Gränssnitt på surfplatta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.3.3 Hemsida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.3.4 Administrationsgränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

INNEHÅLL iv

6.4 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.5 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.6 Utvecklingsmöjligheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.7 Problem under arbetets gång . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7 Slutsatser 34

Litteraturförteckning 36

A UML diagram 38

B Involverade personer 39B.1 Projektgruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

B.2 Utomstående . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

C Gantt schema 41

Figurer

2.1 Exempel på den data från den infraröda projektorn och sensorn som analyseras avKinect SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Process för framtagning av skelettpunkter med Kinects SDK. Bild 1 visar en djupkartaav en person. Från denna djupkarta tas en bild över olika kroppsdelar fram(Bild 2).Från bild 2 tas positioner på olika ledpunker ut, vilka binds samman av linjer för attbygga ett skelett vilket visas i bild 3. . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 TCP/IP Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Flödesschema för PHP kommunikation . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1 Översiktlig systemarkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 Illustration över CIELAB-färgrymden . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Ett exempel på avståndsgränser i CIELAB-färgrymden . . . . . . . . . . . . . . . . 17

4.4 Gränssnittet för den administrativa hemsidan. . . . . . . . . . . . . . . . . . . . . . 20

4.5 Gränssnittet för hemsidan där användare hämtar sina bilder. . . . . . . . . . . . . . . 21

5.1 Stationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2 Startsidan i applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3 Vyn när användaren klickat på ”Ta bild” . . . . . . . . . . . . . . . . . . . . . . . . 25

5.4 Vyn när bilden tagits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.5 Vyn om användaren väljer att hämta bilden . . . . . . . . . . . . . . . . . . . . . . 26

5.6 Rymdmiljön . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.7 Havsmiljön . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.8 Kubmiljön . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

A.1 Aktivitetsdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

C.1 Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

v

Tabeller

1 Ordlista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

vi

Typografiska konventioner och ordlista

När engelska begrepp används skrivs de kursiverat. Förkortningar skrivs endast ut när de först intro-duceras. Det bifogas även en ordlista för ytterligare förståelse.

För att underlätta förståelse av förkortningar, engelska ord och systemutvecklingsspecifika ord bifogashär en ordlista, se Tabell 1.

Tabell 1: Ordlista

API “Application Programming Interface”, specifikation av hur appli-kationsprogram kan använda och kommunicera med en specifikprogramvara.

base64 en metod för att konvertera binära data till ASCII-tecken.

Box blur en metod för att skapa oskarpa bilder.

branch är inom versionshantering en modifierad kopia av huvudgrenensom tillåter att man kan jobba separat med olika funktioner.

chroma key Specialeffekt för att dölja vissa element, oftast bakgrund, i en bild.

fps “frames per second”, anger hur många bilder per sekund som spe-las upp.

IDE “Integrated Development Enviroment”, utvecklingsmiljö för pro-grammerare.

inkrement en körklar version av den slutgiltiga, men ej färdiga, produkten.

motion capture olika tekniker för att spela in rörelser från människor/djur och ap-plicera dessa på datorgenererade modeller.

orphan branch är en branch som saknar huvudgren.

pixel shader program för att beräkna perceptionen av djup och färger i digitala3D-bilder.

scrum agil systemutvecklingsmodell.

scrum master coach för de övriga projektmedlemmarna.

SDK “Software Development Kit”, en uppsättning utvecklingsverktygför mjukvaruutvecklare att bygga applikationer.

sprint arbetsperiod på 3-30 dagar då specifika tasks utförs.

Fortsättning på nästa sida

vii

TYPOGRAFISKA KONVENTIONER OCH ORDLISTA viii

Tabell 1 – Fortsättning från föregående sida

story en större uppgift eller funktion i ett system som jobbas med underen sprint.

task en mindre uppgift som är en del av en story.

TCP “Transmission control protocol”, ett protokoll för att överföra datamellan två enheter i ett nätverk. Relativt pålitlig på grund av sinfelkontrollering, men kan också bli långsam av samma anledning.

TCP/IP “Transmission control protocol/Internet protocol”, en vanlig ar-kitektur för kommunikation via nätverk. Innehåller 4-5 kommu-nikationslager. Används för internet och kan också användas pålokala nätverk.

UDP “User diagram protocol”, ett protokoll för att överföra data mel-lan enheter i ett nätverk. Opålitlig på grund av sin frånvaro avfelhantering, men är ett snabbt protokoll av samma anledning.

Body tracking Att följa en persons rörelser med en kamera över tid.

Kapitel 1

Inledning

Under detta projekt har ett system till en station (i fortsättningen benämnt chroma key-stationen) påVisualiseringscenter C utvecklats. På stationen kan en användare i realtid se sig själv i intressantamiljöer genom att personen ställer sig framför en kamera mot en enfärgad bakgrund. Med olika rö-relser som registreras av kameran kan användaren även interagera med bakgrunden. För att ändrainställningar på chroma key-stationen finns det en surfplatta där användaren kan byta miljö samt sparabilder på sig själv. Målgruppen för projektet är barn och av den anledningen har systemet ett tydligtoch intuitivt gränssnitt.

1.1 Bakgrund

TV-spel, applikationer och annan skärminteraktion är idag vardag för många människor. Spel användsför att underhålla såväl vuxna som barn, människor i alla åldrar gillar att leka med teknik. En populärteknik som ofta används inom film är så kallad chroma key compositing, vilket går ut på att utnyttjaskillnader i färg för att maskera bort antingen en bakgrund eller ett objekt i scenen. Att enbart synas påen skärm med statisk bakgrund är däremot inget nytt. När Visualiseringscenter C i Norrköping villeförbättra sin chroma key-station var det därför ett naturligt steg att gå från att endast visa en bakgrundtill att göra om det till en interaktiv miljö. Samtidigt lever vi i ett samhälle där sociala medier har enallt större roll. Människor vill inte bara uppleva saker, utan också berätta för andra vad de har upplevt.Detta görs främst via sociala medier som Facebook, Instagram och Twitter. Denna vilja att synas ochdela med sig av upplevelser utnyttjas av företag för marknadsföring. Att erbjuda lättanvända tjänsterför att uppmuntra kunder att dela med sig av till exempel bilder till omvärlden är ett smart drag för attsynas som företag.

1.2 Syfte

Syftet med projektet är att utveckla en chroma key-station till Visualiseringscenter C. Stationen skadels underhålla besökare men också ge dem möjlighet att dela sin upplevelse via sociala medier föratt marknadsföra visualiseringscentret.

1.3 Frågeställning

• Hur kan kvalitén på maskningen av användaren i interaktionsmiljön förbättras jämfört medmaskningen i de exempelprogram som finns i Kinect SDK?

1

KAPITEL 1. INLEDNING 2

• För att projektets arbetsgång ska vara effektiv krävs det att delar som ska göras inte är beroendeav delar som inte gjorts. För att undvika detta problem är det viktigt att lokalisera flaskhalsar.Vad är detta projektets mest kritiska flaskhalsar?

• För att barn i åldrarna 5-10 år ska kunna använda stationen är det viktigt att de förstår hurmenyer och program fungerar. Hur utformas systemets användargränssnitt för att det ska varapå bästa sätt anpassat till tänkt målgrupp?

1.4 Avgränsningar

Projektet är avgränsat till att programmet är beroende av operativsystemet Windows eftersom Kinectsofficiella SDK valdes. En annan avgränsning som gjorts är att delningsfunktionen är begränsad tillFacebook samt att kunna ladda ner bilden lokalt till sin enhet. Eftersom målgruppen i detta projekt ärbarn i de yngre åldrarna måste gruppen även ha i åtanke att systemet ska vara tillräckligt intuitivt fördessa.

Kapitel 2

Relaterat arbete

Systemet använder sig av två tekniker för att maska ut bakgrunden. Dels används skillnaden i färgmellan personen i scenen och en enfärgad bakgrund. Dels beräknas avståndet till olika delar i scenenvarpå en maskning sker beroende på djupet. Båda teknikerna tillsammans kallas Chroma Keying ifortsättningen av denna rapport. I detta kapitel beskrivs dessa tekniker och de andra tekniker somberör projektet för att ge ökad förståelse för hur projektet implementerats.

2.1 Chroma Keying

Chroma keying är en teknik som används för att dölja objekt i en scen. Detta används ofta för attmöjliggöra visning av en bakgrund i en scen som i verkligheten inte finns där. Tekniken går ut på attklippa ut delar av en bild och lägga in dessa delar i en ny bild.

2.1.1 Microsoft Kinect

Kameran som används till systemet är Microsoft Kinect 2.0. En Kinect innehåller en mängd avan-cerade sensorer; färg, ljud och en infraröd projektor med en tillhörande sensor för att kunna beräknadjup. Det är framför allt egenskaperna i Kinectens hård- och mjukvara som möjliggör att få djupdatasom gör den unik och det har skapats mycket intressant forskning och projekt på olika nivåer medkameran som grund.

Funktionaliteten för att kunna få djupinformation i bilden fungerar, något förenklat, genom att deninfraröda projektorn, som består av en infraröd laser, emitterar ljus som först passerar ett diffraktions-gitter och delar upp strålen i 512 horisontella och 424 vertikala punkter. Dessa punkter träffar sedanobjekten i scenen. Den infraröda sensorn, som har samma upplösning som projektorn, plockar uppdet ljus som skickas ut från projektorn.

I samband med Kinectens lansering släppte Microsoft ett SDK, Software Development Kit för att hjäl-pa utvecklare använda deras produkt. SDK:t ger möjligheten att få ut mer av datan från djupsensorni Kinecten. Företaget PrimeSense, som ligger bakom tekniken har inte publicerat alla detaljer för hurdatan som sensorn registrerar analyseras, men det är känt att tekniken är baserad på den så kalladeStructured light principle [1]. Structured light principle är en relativt gammal princip som i korta draggår ut på att projicera ett känt möster på en yta och sedan analysera hur detta mönster deformeras ochpå så sätt veta vilket djup respektive punkt har [2]. I Figur 2.1 finns ett exempel på hur den datafrån den infraröda projectorn och sensorn ser ut innan den analyseras av Kinect SDK för att få utdjupdatan.

3

KAPITEL 2. RELATERAT ARBETE 4

Figur 2.1: Exempel på den data från den infraröda projektorn och sensorn som analyseras av KinectSDK

Kinecten kombinerar denna teknik med två andra klassiska metoder för att kunna bestämma djup ien bild, nämligen djup från fokus och djup från stereo. När djup bestäms från fokus analyseras hurfokuserad bilden är på olika ställen och desto suddigare bilden blir desto större djup är det. Kinectenanvänder den här tekniken genom att använda en speciell astigmatisk lins som gör att de punkternasom projiceras får olika former beroende på vilket avstånd från kameran de befinner sig på. Denandra tekniken, djup från stereo används ofta genom att använda två kameror på olika positioner ochanalyserar hur mycket bilderna skiljer sig från varandra. Punkter som befinner sig längre bort frånkameran kommer ha större avstånd från varandra i dessa två bilder, och med hjälp av detta avståndkan avståndet från kameran till punkten avgöras med matematiska beräkningar. I Kinecten användsskillnaden mellan den infraröda projektorns och sensorns positioner.

En annan funktionalitet hos SDK:t är att det kan ta fram skelettpunker som visar hur en person framförkameran rör sig i tre dimensioner vilket görs i två steg, dessa steg är visualiserade i Figur 2.2. Först tasen djupkarta fram med hjälp av djupsensorn. Utifrån djupkartan beräknar Kinectprogrammet positio-ner på olika kroppsdelar med en algoritm som tagits fram genom maskininlärning från över 100 000träningsexempel[3]. Dessa träningsexempel är olika positioner en användare skulle kunna ha underanvändande av en Kinect som tagits fram med hjälp av motion capture. Med dessa exempel har enbeslutsskog tagits fram vilket är en mer sofistikerad version av ett beslutsträd som är en förutbestämdföljd av frågor som tar en till nya frågor beroende på svaret på föregående fråga. När beslutsskogenär klar har en bild med föreslagna positioner på kroppsdelar tagits fram. Utifrån bilden på kroppsde-lar tar Kinectprogrammet fram leder som sedan kopplas samman som ett skelett. Med hjälp av dettaskelett kan programmet spåra en användares rörelser i tre dimensioner och inkludera användaren ifysiksimuleringar. Detta ger stora möjligheter till olika interaktioner med objekt i scenen.


Figur 2.2: Process för framtagning av skelettpunkter med Kinects SDK. Bild 1 visar en djupkartaav en person. Från denna djupkarta tas en bild över olika kroppsdelar fram(Bild 2). Från bild 2 taspositioner på olika ledpunker ut, vilka binds samman av linjer för att bygga ett skelett vilket visas ibild 3.

Chroma Key med djupkamera

I Kinect SDK finns exempelprogram där Kinectens djupkamera används för att få konturerna påpersonen framför kameran. Metoden går ut på att välja ett intervall på det djup personen kan stå på ochavstånd utanför detta intervall klipps bort. Med denna metod behövs inte någon enfärgad bakgrundutan det går att använda programmet oavsett bakgrund så länge det finns tillräckligt avstånd bakomanvändaren. Denna metod innebär vissa begränsningar som gör det svårt att lyckas med chroma keyingav hög kvalitet.

Det största problemet med att Kinecten har både en djupsensor och en färgsensor ligger i att djupsen-sorns upplösning (512x424 pixlar) är betydligt lägre än färgsensorns (1920x1080 pixlar) och de tvåsensorerna sitter, av naturliga skäl, inte heller på exakt samma ställe. Detta problem innebär att omdjupsensorns data ska användas för att styra det som ska visas från färgsensorn måste djupsensornskoordinater mappas så att de överensstämmer med varandra. Denna mappning är en funktionalitetsom även den finns inbyggd i Kinect SDK, men på grund av den tidigare nämnda upplösningsskillna-den mellan sensorerna finns det vissa brister som är svåra att kringgå. En pixel från djupsensorn täckerett betydligt större område än en pixel från färgsensorn, vilket innebär att när det i chroma keyingenska tittas på om en individuell pixel i färgsensorn ska maskeras bort eller inte så fattar funktionen ettbeslut baserat på en approximation. Detta gör att kanterna runt personen ser lågupplösta och kantigaut samt att enstaka pixlar från bakgrunden kommer med, vilket ofta ger gröna kanter runt personensom klippts ut från bakgrunden.

Om personen som står framför kameran har ett objekt eller en kroppsdel framför sig uppstår ettproblem som har med kamerans utformning att göra. Även detta problem grundar sig i att sensorernaspositioner skiljer sig från varandra. Om den infraröda projektorn blockeras av någonting innan dennår fram till en kroppsdel som är tänkt att maskeras bort, kan det naturligvis inte heller beräknas djuppå denna position. Detta skulle inte vara ett problem om den infraröda sensorns position och synfältexakt skulle matcha färgsensorn, då skulle blockerade områden ändå inte uppfattas av färgsensorn.Det som händer i praktiken är att den infraröda ”skuggan” som uppstår blir ett problem när en chroma


keying ska göras eftersom ingen djupdata kan registreras på dessa positioner.

Chroma Key med färgkamera

Alternativet till att använda djupkameran är att använda färgkameran för att maskera bort bakgrunden.För att göra detta behövs en bakgrund i en enhetlig färg som kan klippas bort. Sedan tas ett färgprov avbakgrunden och varje pixels färgvärden jämförs med detta färgprov. Om pixelns färgvärden är inomett visst euklidiskt avstånd från bakgrundens färgvärden visas pixeln, i annat fall ersätts denna pixelmed den pixel som har motsvarande position i bakgrunden. Genom att använda färgkameran i sinchroma key kan tidigare nämnda infraröda ”skuggor” på personen undvikas om något objekt skullevara framför denne. Problemet med metoden är att beräkningar måste ske på varje enskild pixel ibilden vilket sänker programmets fps, frames per second. Ett annat problem med färgkameran uppstårifall personen framför kameran har liknande färg på kläderna som bakgrunden, eftersom färgkamerandå antar att det tillhör bakgrunden.

2.2 Realtidskommunikation

Det som huvudsakligen karaktäriserar realtidskommunikation är responstiden, alltså den tid det tarför signaler som skickas mellan olika komponenter i systemet. Denna responstid måste, om det skakunna definieras som realtidskommunikation, garanteras under en viss tid. Ofta handlar denna tid ommilli- eller microsekunder [4].

Om två enheter ska kunna upprätta en anslutning mellan varandra används vanligtvis protokollet TCP,Transmission Control Protocol. Detta tillåter en inbördes ström mellan dessa två enheter. Ett annatalternativ, om kommunikation inte nödvändigtvis måste ske mellan just två enheter, är att användaprotokollet UDP, User Diagram Protocol istället. En grundläggande skillnad mot TCP-protokolletär att UDP är ett så kallat förbindelselöst protokoll, alltså att ingen session mellan de ihopkoppladeenheterna upprättas. Detta innebär att sändande enhet inte kan garantera att paket når fram till önskadmottagare. Det kan också innebära att paket når fram, men i fel ordning. UDP är alltså ett enklare ochlättare protokoll än TCP [5].

TCP och UDP tillhör båda den vanligt förekommande TCP/IP-modellen, vilken är en modell för hurapplikationer ska kunna kommunicera med varandra. TCP/IP eller Transmission Control Protocol/In-ternet Protocol som det står för, liknar på många sätt OSI-modellen, vilket är en förkortning för OpenSystems Interconnection och är en rekommenderad standard sedan 1980 då ISO, International Or-ganization for Standardization valde modellen. Skillnaden mellan TCP/IP och OSI är att OSI är engenerisk, protokolloberoende standard, medan TCP/IP är en implementation av OSI. En annan storskillnad är att OSI har delats in i sju olika kommunikationslager, medan TCP/IP bygger på fyra ellerfem lager. I Figur 2.3 nedan presenteras de lager som används i respektive modell. TCP/IP är härbaserad på fyra lager.


Figur 2.3: TCP/IP Stack

Det översta lagret i TCP/IP-modellen, applikationslagret ger olika applikationer möjlighet att nå ochkommunicera med tjänster längre ner i kedjan. Det kan exempelvis vara HTTP, Hypertext TransferProtocol som används för att överföra information på internet eller SMTP, Simple Mail Transfer Pro-tocol som används för att överföra mail. De tidigare diskuterade TCP- och UDP-protokollen tillhörtransportlagret som, lite förenklat, ansvarar för att meddelanden ska nå fram till rätt port. Att användaTCP här är som tidigare nämnt säkrare vad beträffar att meddelanden ska nå fram och i rätt ordning.Dock innebär den förbättrade säkerheten också, i förhållande till UDP-protokollet, en viss försämringi hastighet. Ett paket som har TCP eller UDP packat ner når sedan IP-lagret där det tas om hand ochskickas vidare till rätt IP-address. Det nedersta lagret, hårdvaru-lagret, är där meddelandet rent fysisktskickas, det kan vara med exempelvis WiFi eller Ethernet [6].

En teknik som utnyttjar det tidigare diskuterade TCP-protokollet och som är vanligt förekommandenär med kommuninikation i realtid mellan enheter är Websocket-protokollet. Websockets är huvud-sakligen baserat på TCP-protokollet, men för att göra det så kallade handskaket, alltså där de bådakommunicerande enheterna sätter parametrar för att kunna upprätta en korrekt anslutning, görs medhjälp av HTTP. HTTP verkar som tidigare nämnt applikationslagret och används mestadels för attöverföra informaton på internet. HTTP bygger på att en förfrågan skickas till en server som sedansvarar med att skicka den information som efterfrågas. Websocket-protokollet är som namnet antyderhuvudsakligen utformat för att enkelt kunna implementeras i webbläsare och webbservrar, men kananvändas i andra sammanhang också. För en socketserver som är avsedd att kommunicera med kli-enter på flera olika plattformar, kan websockets med fördel användas då implementation av klientkodblir väldigt enkel i webbläsare och dessutom kommer fungera bra på andra plattformar [7].

Vad gäller den rent fysiska anslutningen mellan enheterna måste samtliga kommunicerande enheter,i fallet TCP/IP, vara uppkopplade mot antingen samma nätverk för att kommunicera lokalt, eller tillinternet. Denna uppkoppling kan utgöras av trådlösa alternativ så som Bluetooth, WiFi eller trådbund-na alternativ, vanligtvis Ethernet. Det finns naturligvis en vinst i att välja trådbundet om en så säkeranslutning som möjligt är önskvärd, men detta är inte alltid en möjlighet om det till exempel saknasEthernet-port. Detta tillhör hårdvarulagret i TCP/IP-modellen, vilket alltså är vad som fysiskt ser tillatt information kan skickas och tas emot.

När en anslutning som möjliggör realtidskommunikation mellan enheterna är upprättad och det finnsmöjlighet att skicka paket krävs ytterligare protokoll för att få de inblandade mjukvarorna att tolka


den information som tas emot till relevant data som den kan göra någonting med. Protokollet måsteockså tillämpas när datan skickas, då i form av att den ska packas ner i en form som senare kanbearbetas när det kommer fram. Detta protokoll behöver nödvändigtvis inte vara något standardiserat,då dess utformande kan variera i komplexitet och utseende beroende på vilken kommunikation somär avsedd att göras. Det kan i de enklaste fall vara exempelvis ett värde som som ska skickas ochpresenteras på mottagarens skärm, vilket egentligen inte kräver något protokoll alls, utan snarare baraatt det meddelande som tas emot skickas direkt till den funktion som skriver ut värdet. Om däremotdet behövs göras flera olika handlingar beroende på vad som skickas kan protokollets utseende varabetydligt mer intrikat.

2.3 Databaslösningar

För att kunna lagra och skicka information över internet är en databas ett vedertaget alternativ. Vid valav databas är det viktigt att ta hänsyn till vilken typ av data som ska lagras och vilka krav på säkerhetsom måste finnas på databasen. [8]

2.3.1 PHP

PHP är ett skriptspråk som används till bland annat kommunikation med databaser. Språket fungerarsom ett filter mellan klient och databasen där skripten tar in data, behandlar den och i textformatskickar vidare informationen, se Figur 2.4. PHP kan köras på flera olika plattformar (Windows, Linux,Mac OS etc.) och det är kompatibelt med nästan alla servrar som existerar idag (Apache, IIS, etc.).[8] Det är ett säkert språk att skriva kommunikationskod i eftersom klienten inte kan se koden. Attkoden inte går att se försvårar för användare att kunna visa eller ändra information på databasen utantillåtelse. [9]

Figur 2.4: Flödesschema för PHP kommunikation

2.3.2 JavaScript

JavaScript kan också användas för att skicka eller hämta information. Nackdelen är att här går allkod att läsa för vem som helst. Det finns dock API, Application Program Interface, som skapar säkerkommunikation mellan klient och server. Koden som utvecklaren skriver för att ansluta och kommuni-cera är så kallad client-side code som vid anslutning skickar vidare informationen till back-end script.Dessa behandlar informationen och avgör om den ska få påverka eller hämta data från databasen [10].Firebase, AWS Mobile Hub och Google Cloud Storage är exempel på sådana API [11].


2.4 Tredjeparts API

Utanför lärandets syfte är det dumt att återuppfinna hjulet. Finns det färdigutvecklad programvara föratt utföra uppgifter som kommer att behövas är det en god idé att bygga vidare ifrån den grunden.Vid 3D programmering finns det många återkommande problem där lösningen är samma oberoendeav vad användaren tänker programmera. Exempelvis hur en bild renderas ut utifrån en virtuell kameramed perspektiv. Även rotation, translation och skalning använder sig av operationer som alltid ärdesamma. Då kan det vara bra att använda sig av ett tredjeparts API [12].

Kapitel 3

Arbetssätt

I detta avsnitt beskrivs det hur arbetet sett ut under projektet med arbetsmetodik, rutiner och projekt-hantering.

3.1 Arbetsmetodiken scrum

Planeringen av projektet har utgått ifrån utvecklingsmetoden scrum. I början av projektet sattes pro-jektets Product Backlog upp under ett möte med kunden. Backlogen består av stories som exempelviskunde vara ”Som besökare vill jag kunna ta en bild av skärmen med hjälp av en surfplatta”. För attinleda varje sprint har gruppen hållt ett planeringsmöte, Sprint Planning, där ett antal punkter gemen-samt diskuterats, enligt en mall som gjordes i början av projektet. Under detta möte delades tasks ut igruppen för att nå sprintens mål. Ett exempel på ett task kan vara ”Ladda upp den tagna bilden på Fi-rebase”. Under projektets gång har rollen som Scrum Master roterat bland gruppens medlemmar, ochden nya Scrum Mastern har valts under dessa inledningsmöten. Om ingen anmäler sig som frivillig tillatt vara Scrum Master lottas den rollen ut bland de personer som ännu inte innehaft rollen. Förutomdetta har gruppen under mötet huvudsakligen tagit beslut om vilka uppgifter som ska bearbetas underkommande sprint, och även fördelat vissa av dessa uppgifter mellan gruppens medlemmar.

Under sprintens gång har varje dag inletts med ett kort möte, Daily Scrum, där respektive medlem kortnämnt vad de gjort under föregående dag, samt vad som planerats att göra under nuvarande dag. Omnågon är klar med sin uppgift tilldelas den personen en ny uppgift, utefter vad som är högst prioriterat.

Varje sprint har sedan avslutats med ett utvärderingsmöte. Utvärderingsmötena har verkat som ensammanslagning av Sprint review, som utvärderar resultatet av sprinten, och Sprint retrospective, därgruppens arbete och rutiner utvärderas. Under detta möte kollar gruppen att samtliga mål som sattesupp under inledningsmötet har klarats av. Om ett eller flera mål ej har uppfyllts undersöker gruppenvarför, och modifierar nästkommande sprint utefter detta. Här har även ändringar av rutiner gjorts vidbehov.

Arbetet har nästintill uteslutande skett genom att gruppen träffats under planerade tider då varje per-son arbetar individuellt eller i par med den uppgift som har tilldelats. Jämfört med att alla utför sinenskilda uppgift på eget initiativ förenklar det diskussion, vilket leder till ökad produktivitet eftersomeventuella hinder kan överkommas snabbare.

10

KAPITEL 3. ARBETSSÄTT 11

3.1.1 Ansvarsområden

Förutom rollen som Scrum Master har ett antal andra ansvarsområden fördelats inom gruppen. Föratt minska förvirring för kunden gällande kontakt har en av dessa roller varit kontaktansvarig, somvarit ansvarig för att maila kunden de gånger gruppen har varit i behov av det samt verkat som kom-munikationslänk mellan kunden och projektgruppen under tiden mellan kundmötena. På grund av attökad kommunikation med kunden krävdes inom olika områden utökades senare kundkontakten tilltvå ansvariga. Ett annat ansvarsområde har varit testansvarig, som ansvarat för att tester sker kon-tinuerligt. När någon har gjort klart sin del har den testansvarige sett till att de nya funktioner somimplementerats har testats av en annan gruppmedlem, dels för att se till att de fungerar korrekt, menäven för att säkerställa att de är tillräckligt väldokumenterade. Förutom detta ser den testansvarigeäven till att övriga tester sker när det behövs.

Under projektets gång har det varit viktigt för gruppen att det finns någonstans att sitta och arbetaostört. På grund av detta har ansvar för att boka salar fördelats mellan gruppens medlemmar, där varjeperson har haft ansvar för att boka en sal till ett särskilt tillfälle.

För att ha en strukturerad form på de uppgifter som ska klaras av under sprinten har gruppen använt sigav Trello, därmed kändes det naturligt att ha någon som ansvarar för att den är uppdaterad. Rollen somTrello-ansvarig har roterat mellan gruppmedlemmar men bedömdes sedan som överflödig. Rollensom Scrum Master har roterat efter varje sprint.

3.2 Rutiner

Under projektet har vissa rutiner följts för att förenkla arbetet med versionshantering, dokumentation,kodgranskning och testning.

3.2.1 Versionshantering

För versionshantering har Git använts. För att dela koden mellan alla gruppmedlemmar har Githubnyttjats där arbetets huvuddelar, androidapplikation, hemsidor, chroma key med kinect, 3D-miljöeroch kod för socketserver, delats upp i så kallade orphan branches, separerade grenar. Allt eftersom deolika komponenterna blivit färdigställda har de delarna som arbetar beroende av varandra, till exempelsocketserver, Kinectmaskning och 3D-miljöer, förts ihop till ett projekt som kallas Kinektprojektet därett körbart program, Kinectprogrammet, byggs med hjälp av CMake. CMake är ett plattforms- ochkompilatoroberoende byggverktyg som används för att bygga mjukvaruprogram från C++ källkod[13]. Utifrån Kinectprojektet har sedan ytterligare branches skapats för mer detaljerat arbete med deolika miljöerna och tillägg av mindre funktioner.

3.2.2 Dokumentation av kod och dokument

Koddokumentation har skett löpande under projektet och säkerställts vid kodgranskning.

Dokumentation av möten, scheman, samt delning av bild- och textfiler har skett med hjälp av moln-lagringstjänsten Google Drive. Det har skett löpande under projektets gång och alla medlemmar harhaft tillgång till alla dokument för att kunna hålla sig uppdaterade och för att kunna gå tillbaka till vadsom sagts på varje möte.

Den detaljerade planeringen av uppgifter har skötts via Trello och vem som arbetat med vad harbestämts på dagliga morgonmöten.


Allmän kommunikation samt delning av länkar och resurser har skett via kommunikationsverktygetSlack.

3.2.3 Kodgranskning

Kodgranskning har skett kontinuerligt under projektets gång. Till en början var tanken att den skulleske under veckans sista arbetspass. Sedan gick det över till att vara varje persons eget ansvar att se tillatt någon annan i gruppen granskade den kod som personen skrivit då den är färdigställd.

Granskningen har i första hand gått ut på att säkerställa kodens läslighet med fokus på att det finnskommentarer, att variabelnamn är förståeliga samt att de konventioner som satts har följts. Konven-tionerna har varit Google Style guide [14] samt den konvention som Urho3D använt i sina exempel[15].

3.2.4 Testning

Planen var att systemtestning skulle påbörjas i ett relativt tidigt skede när hela systemet var uppsattpå Visualiserinscentret med den dator som var tänkt för stationen. På så vis är alla förutsättningar rättfrån början och inga ändringar av hårdvara behöver göras på systemet baserat på utrustning som intenödvändigtvis stämmer för den station som systemet ska användas på.

De tester som planerades göras har utformades efter kundens QA, quality assurance krav. Tanken varatt köra systemet och kolla resultatet vid olika extremfall. Systemet planerades sättas igång och sedanskulle strömmen stängas av vid olika tillfällen i körningen. Sedan kollas resultatet när programmetstartas upp igen. De tillfällen när programmet ska stängas av är:

• När programmet står och väntar på en användare

• När inställningar för chroma-key ändras

• När användaren precis tagit en bild

De frågor som ska svaras på vid testningen är om programmet startar upp enligt kraven och hurmycket av det användaren höll på att göra som är kvar.

3.3 Projekthantering

I detta avsnitt beskrivs arbetet med planering och arbetet kring kundens krav.

3.3.1 Planering

I sprint 0 skapades nedanstående tidsplanering. Under projektets gång har vissa delar behövts juste-ras men detta är hur vi ursprungligen uppskattade projektets genomförande. För en mer översiktligplanering, se bilaga C.

Sprint 0: v.5-7, planering och strukturering av projektet. Projektplan skrivs. Sätta sig in i viktigatekniska delar. Första kundmötet ska ske.

Sprint 1: v.8-10 Uppstartmöte måndag 9.00. I sprintens slut ska en kinectkamera kunna användas påsamma sätt som chroma-key installationen fungerar nu på Visualiseringscentret. Det vill säga, det ska


finnas statiska bakgrunder. Samma som finns från början. Avstämningsmöte på eftermiddagen den11:e februari.

Sprint 2: v.11-13 Uppstartmöte den 14:e februari. I sprintens slut ska en app finnas som är koppladtill systemet. I appen ska användaren kunna byta bakgrund och ta en bild och dela den. Det ska intefokuseras något på designen av appen, endast funktionalitet. Avstämningsmöte den 1:a April.

Sprint 3: v.14-17 Uppstartmöte den 4:e. I sprintens slut ska det finnas en ny bakrund med interaktionoch animerade objekt. Avstämningsmöte den 29:e April.

Sprint 4: v.18-19 Uppstartmöte den 2:a Maj. I sprintens slut ska det finnas en slutlig design för appen.Avstämningsmöte den 13:e maj.

Sprint 5: v.20-22 Uppstartmöte den 16:e maj. I slutet av sprinten ska det finnas flera bakgrunder medtillhörande animerade objekt och interaktion. Avstämningsmöte och slutlig överlämning av systemetden 3:e juni.

Tester ska ske med målgruppsbarn ca v.11-12 och v.16. Appen och systemet ska testas av vuxna ca v.18-19.

Projektrapport ska skrivas simultant med projektet. Allt som den ska innehålla ska finnas klart den12:e maj. Den kan förbättras fram till den 2:a juni.

Opponeringsrapport ska skrivas under v.20.

3.3.2 Kravhantering

Vid första mötet med kunden sattes ett antal krav upp som systemet skulle behöva klara av.

• Bildkvalitén på stationen ska förbättras.

• Det ska vara möjligt att ta bilder, och även förmedla dessa bilder via sociala medier.

• Systemet ska vara tillräckligt stabilt för att kunna fungera felfritt under visualiseringscentretsöppettider. Det ska även klara av strömavbrott.

Mer konkreta uppgifter strukturerades utefter dessa krav, och anordnades sedan efter prioritet i enlista. Förutom dessa krav har gruppen haft frihet att ta egna beslut gällande miljöer, och diverselösningar på problem. Fokus har därmed lagts på att få igång ett system som uppfyller ovanståendetre krav, och därefter börja implementera olika miljöer med interaktion för att göra systemet merunderhållande för användare.

3.3.3 Kundkontakt

Projektgruppen har haft två ansvariga för kundkontakt. Uppgifterna har främst rört sig om mailkontaktmed kunden för att boka in möten samt uppföljning efter mötena, men även inkluderat att skrivaprioriteringslistor som kunden använt för att formulera sina krav och mål till projektgruppen. Det haräven ingått bland uppgifterna att se till att alla i projektgruppen är förberedda och informerade införmötet samt se till att eventuella frågor från gruppmedlemmar till kunden skrivs ner på förhand och tasupp på mötet.

Kapitel 4

Metod

För att systemet ska innehålla den funktionalitet som kunden kräver har ett antal komponenter be-hövts införskaffas. För att först och främst få fram en miljö som användaren kan se sig själv i behövsen Kinect, en dator som kör Kinectprogrammet, samt en projektor. Eftersom systemet även ska till-handahålla en simpel metod för att ta bilder och sedan kunna hämta hem dessa bilder behövs även ensurfplatta, som hanterar bildtagandet samt gör det enkelt för användare att byta mellan de miljöer somfinns i systemet. För att användare sedan ska kunna hämta hem dessa bilder utanför Visualiserings-center C behövs en databas, där dessa kan lagras.

4.1 Systemarkitektur

I Figur 4.1 visas projektets systemarkitektur. Kinectprogrammet styrs av en applikation på surfplattandär kommunikationen sker via websockets. Applikationen styr vilken bakgrund som ska användas avkinectprogramet och kan hämta en bild av användaren. Denna bild sparas sedan i Firebase där använ-darhemsidan sedan kan hämta samtliga bilder som tagits. I Firebase sparas också datorns IP-adresssom kan hämtas av applikationen på surfplattan samt adminhemsidan som även den kommunicerarmed Kinectprogrammet genom websockets.

Figur 4.1: Översiktlig systemarkitektur

14

KAPITEL 4. METOD 15

4.2 Kinectprogrammet

Kinectprogrammet körs på en dator som är kopplad till en projektor. Detta program tar in data frånKinecten och ger en bildström av chroma-key:ade bilder.

4.2.1 Hårdvara

Som kamerasensor valde vi att använda Microsoft Kinect 2.0 då den innehåller störst funktionalitetutöver RGB-sensorn (Red Green Blue), som i sig är jämförbar med exempelvis en webbkamera. Ki-nectens djupkamera möjliggör interaktivitet på ett helt annat sätt än om valet hade fallit på att användaen webbkamera.

Programmets funktionalitet ställer också vissa krav på den hårdvara som det ska köras på. För Kinec-ten krävs först och främst en USB 3.0-port, vilken är direkt nödvändig för att Kinecten överhuvudtagetska fungera. Eftersom programmet behandlar en hel del interaktioner och 3D-grafik är både en rela-tivt modern centralprocessor och framförallt grafikprocessor att föredra. Den dator som valet föll påuppfyller dessa kriterier. Det är en stationär dator med USB 3.0, grafikprocessorn NVIDIA GeForceGTX 580 och centralprocessorn AMD Phenom(tm) II X4 955 Processor 3.20 GHz, vilka tillsam-mans klarar att köra programmet utan problem.

4.2.2 Utvecklingsplattform

För att kunna utveckla med Kinect finns en rad olika SDKs och bibliotek, men för att undvika problemoch buggar i så stor utsträckning som möjligt valde vi Microsofts officiella Kinect SDK. Detta SDKkräver att utvecklarna använder operativssystemet Windows 10 och Microsoft egna IDE, IntegratedDevelopment Environment Visual Studio.

4.2.3 Chroma Key

I vår Chroma keying-lösning har vi använt två olika metoder. För att sköta huvudparten av maskningenanvändes Kinectens djupsensor. Som tidigare nämnt i kapitel 2 finns det en stor begränsning i attdjupsensorn i Kinecten har en betydligt lägre upplösning än RGB-sensorn (512x424 mot 1920x1080)pixlar. Används en obearbetad signal från djupsensorn som enda maskningsinput blir konsekvensenatt konturerna på de maskade objekten blir kantiga och hackiga. Vår lösning på det här problemet blevatt använda djupsensorn för att ta bort de största delarna av bakgrunden och att använda en green-screen och maska bort de resterande pixlarna med avstånd i färgrymden. För att undvika kantigakonturer på områden där färgmaskningen inte behövdes tillämpas box blur-metoden [18] på bildenfrån djupsensorn för att mjuka ut den. Box blur är beräkningsmässigt resurskrävande, då den för varjeenskild pixel tar ett medelvärdet från en omkringliggande kvadrat med godtycklig sidlängd. I ekvation4.1 visas hur detta går till för en exempelpixel, där kvadraten för oskärpa är valt till 3x3 pixlar därcenterpixeln är den aktuella. Värdet från alla pixlar adderas och divideras sedan med antalet elementi kvadraten, i detta fall 9. Denna metod liknar Gaussian blur-algoritmen med skillnaden att Gaussianblur beräknas först en kärna från centerpixeln för hur mycket varje pixel i kvadraten ska viktas.

KAPITEL 4. METOD 16

1 1 1

1 1 1

1 1 1

∗ 1/9 (4.1)

Att köra box blur i realtid på CPU:n är långsamt även för moderna processorer med små kvadrater.För att kunna köra den i realtid har framförallt två stora optimeringar genomförts. Det första är attutföra box blur-beräkningarna på grafikprocessorn, detta ökar fps:en till en acceptabel nivå. Det andrasom optimering som gjorts går ut på att utföra box blur-metoden i två renderingspassar, vilka bådaapplicerar box blur endiminsionellt. I den första appliceras box blur horisontellt vars utdata bearbe-tas igen av det andra renderingspasset vertikalt. Denna metod innebär att ett liknande resultat fås medbetydligt färre beräkningar. Om box blur-kvadraten exempelvis är 6x6 pixlar stor så blir antalet beräk-ningar per pixel 6x6=36 och om bilden är, som i vårt fall, 1280x720 sker 36x1280x720 = 33177600beräkningar mot de 12x1280x720 = 11059200 som krävs för box blur i två renderingspassar. Dennametod diskuteras även av Wojciech Jarosz i Fast Image Convolutions Fast Image Convolutions.

När området från djupsensorn där beräkningar i färgrymden ska ske på är identifierat ska algoritmensom maskar bort oönskade områden ur bilden köras. Här finns en mängd olika metoder med olika pre-standa och kvalitet att välja mellan, valet blir en balans och viktning mellan önskad prestanda och denkvalitet som eftersträvas. Vi valde att konvertera all färgdata från RGB till CIELAB-färgrymden [16]och maska bort värden baserat på två euklidiska avståndsgränser. I CIELAB defineras färgrymden,precis som i RGB, med tre koordinater, L*, a* och b*, som motsvaras av:

• L* motsvarar ljusintensiteten i färgen,

• a* på den positiva axeln motsvarar mängden rött eller magenta i färgen och på den negativaaxeln mängden grönt.

• b* motsvarar på den positiva axeln mängden gult och på den negativa axeln mängden blått.

Figur 4.2 visar hur CIELAB-färgrymden fungerar grafiskt.

Figur 4.2: Illustration över CIELAB-färgrymden

Avståndsberäkningarna går till enligt ekvation 4.2.

KAPITEL 4. METOD 17

distance =√

(refa − clra)2 + (refb − clrb)2 (4.2)

Här motsvarar refa och refb a*- och b*-värdena från den inställda referensfärg som ska maskasbort. clra och clrb motsvarar a*- och b*-värdena i den aktuella samplingen som den ska testas mot.Som synes ignoreras L*-komponenten, alltså ljusintensiteten i avståndsberäkningen, detta innebär attendast färgens värden avgör huruvida en pixel ska vara kvar eller inte, detta gör systemet mindrekänsligt för exempelvis skuggor och intensitetsskillnader på bakgrunden. Under projektets gång haräven andra RGB- och HSV-färgrymden testats, men CIELAB har gett bäst resultat.

För att undvika en skarp kant mellan det som maskas bort och det som är kvar valdes att istället föratt ha ett euklidiskt avståndsvärde som varje pixel jämförs mot istället två värden, vilket ger en mjukövergång och får maskningen att smälta in bättre i bakgrunden. Avståndsvärdena utgörs av en yttreoch en inre gräns, där alla färger som placeras innanför gränsen behåller sin fulla opacitet medan defärger som placeras mellan de två gränserna interpoleras linjärt mellan 0-1 och de färger som hamnarhelt utanför tas bort. Avståndsgränserna förtydligas i Figur 4.3 och går till enligt ekvation 4.2.

Figur 4.3: Ett exempel på avståndsgränser i CIELAB-färgrymden

α = (distance− inner)/(outer − inner) (4.3)

α är i det här fallet den resulterade opaciteten på RGB-sensorns data, inner är den inre radien ochouter är den yttre. Om gränserna ligger för långt ifrån varandra blir gränsen väldigt mjuk och resul-tatet ser onaturligt ut, därför är det viktigt att hålla gränserna nära varandra för ett så naturligt resultatsom möjligt.

Då det grundläggande grafik-API:t som används i projektet är Direct3D valde vi, för att ytterligare ökaprestandan hos systemet, att placera ovanstående algoritm i pixel shadern vilken är en del av Direct3Dshader-system där färger för varje enskild pixel räknas ut. Fördelen med det är att prestandan blirbetydligt bättre då beräkningarna körs på grafikprocessorn istället för på centralprocessorn, vilken ärden som hanterar större delen av programmet. Grafikprocessorn kan hantera beräkningar av dennatyp på ett betydligt snabbare sätt än vad centralprocessorn kan.

För att hitta en bra referens gäller det att hitta en färg som på ett bra sätt representerar hela detområde man avser att maska på. Det kan bli problem om bakgrunden exempelvis är ljussatt ojämntsätt vilket gör att färgen kan skilja sig mycket beroende på vilket område som analyseras. För att lösa

KAPITEL 4. METOD 18

dessa problem valde vi att istället för att använda oss av endast en generell maskningsfärg för helaområdet att istället låta användaren från administrationsgränssnittet kunna välja att ta en referensbild.Med denna metod kommer istället för att det euklidiska avståndet mäts från samma referensfärg isamtliga pixlar så kommer istället varje pixel ha en individuell maskningsfärg som bättre matcharbakgrunden. Ett potentiellt problem med den här metoden är att om det finns brus i bilden när den taseller om kameran flyttas med någon centimeter så matchar inte referensbilden bra längre. Lösningenpå detta problemet blev att använda den tidigare beskrivna box blur-algoritmen även här, vilket göratt refernsbilden blir betydligt mindre känslig.

Användningen av referensbild till trots upptäckte vi att hitta en bakgrundsfärg som tydligt sticker utfrån det som ska maskas bort fortfarande var viktigt. Vi valde att använda oss av en grön tygduk, ellergreen screen som fungerade färgmässigt. Dessutom är en tygduk betydligt mattare än exempelvis enväggfärg som vi också övervägde, vilket gör att man lättare undviker ojämn belysning över området.

4.2.4 Renderingsmotor

För att rendera den 3D-grafik som programmet innehåller fattades tidigt ett beslut om att inte direktanvända ett lågnivå-API som OpenGL eller Direct3D. Istället valde vi att leta efter ett högnivå-APIsom har implementerat någon av dessa två med andra färdiga funktioner för att snabbt kunna skapaoch rendera 3D-grafik.

Det finns en uppsjö av olika spel- och renderingsmotorer som har den funktionalitet vi efterfrågade,men valet föll tillslut på en motor vid namn Urho3D. Urho3D är en 2D- och 3D-spelmotor imple-menterad i bland annat C++ [15]. Urho är gratis och öppen att användas för alla. Den är bland annatinspirerad av renderingsmotorer som OGRE, men till skillnad från OGRE är Urho nyare och har intekommit upp i de enorma mängder kod och funktioner som OGRE har, och är inte alltför väl doku-menterat. Då detta projekt krävt relativt enkla grafik- och spelfunktioner var Urho därför ett bättrealternativ då det är betydligt mer avskalat än OGRE och mer nischat mot de funktioner som dettaprojekt krävde, t.ex. interaktivitet och spel.

Att Urho3D byggs med CMake har lett till att vårat master-projekt, som nyttjar många funktionerfrån Urho3D, också har behövt byggas med CMake under arbetets gång. CMake stödjer byggande avprojektfiler till Visual Studio och i detta fall specifikt till 64-bitars versionen av Visual Studio 2015.

Vi använder Urho3D för våra bakgrunder och till att skapa interaktiva objekt i de olika scenerna.Urho bidrar med färdig fysik och enkla medel för att läsa in 3D-modeller med såväl texturer somanimationer.

För att få interaktion mellan användaren och objekt i scenen läggs de skelettpunker som fås av KinectsSDK, se Kapitel 2, in som ett objekt i Urho3D.

4.2.5 Boost

Boost är en samling bibliotek för C++ som är genomarbetat och väldokumenterat[17]. Dessa bibliotekhar bland annat använts till att starta en websocket-server och för att spara inställningar i XML-filer.

4.2.6 OpenSSL

OpenSSL är ett bibliotek utvecklat för säker kommunikation[19], i detta fall används det för att säkraupp kommunikationen mellan kinectprogram, surfplatta och administrationsgränssnittet.

KAPITEL 4. METOD 19

4.3 Surfplatta och applikation

För att styra Kinectprogremmet utvecklas en applikation till en surfplatta, på vilken användare kanstyra vilka bilder som ska visas och om man vill ta och spara bilder av sig själv i en virtuell miljö.

4.3.1 Operativsystem

Kundens krav på att användaren ska kunna tillgodose sig med bilder från skärmen ledde till att ettgränssnitt för den funktionen behövde utformas. Användarvänligheten blev en viktig aspekt att tahänsyn till och med det i åtanke föll det naturliga valet på en surfplatta med pekskärm för att han-tera denna funktion. Kravet på surfplattan var att dess operativssystem skulle vara Android då det ärkompatibelt med Windows, samt åtminstone version 5.0 för att garantera att all funktionalitet skullefungera.

4.3.2 Utvecklingsplattform

Applikationen till surfplattan är utvecklad i Android Studio, som är en öppen utvecklingsmiljö förJava och speciellt inriktad till utveckling av applikationer till Android. Det är den mest vedertagnautvecklingsmiljön för Android.

4.3.3 Användargränssnitt

Användargränssnittet ger användaren möjlighet att ändra bakgrundsmiljö till chroma key-skärmensamt välja om en bild ska tas. De finns tre miljöer att välja mellan och de uppdateras i realtid mellanappen och datorn via socketservern. Varje bakgrund representeras med en tryckbar bild. Dessa bildertar upp det mesta av appens bildyta eftersom det är den största funktionaliteten för appen. Dessutomär de valda att vara stora eftersom applikationen ska gå att användas av barn vars finmotorik inte ärperfekt.

4.3.4 Bildhantering

Skulle användaren välja att ta en bild kommer det startas en nedräkning på surfplattan som förberederanvändaren på att ett foto tas. När nedräkningen är färdig meddelar applikationen Kinectprogrammetsom tar en skärmavbild. Denna bildinformation omvandlar Kinectprogrammet sedan till en base64-sträng. Den strängen skickas till Android-applikationen som presenterar bilden för användaren ochger valet att låta användaren hämta eller slänga bilden. Om bilden slängs kan användaren fortsät-ta interagera med miljöerna eller ta en ny bild. Om bilden sparas kommunicerar applikationen medFirebase och skickar upp base64-strängen tillsammans med en tidsstämpel till databasen. I applika-tionen kommer en kort kodsträng och en QR-kod genereras som båda presenteras för användaren.Användaren kan använda sig av någon av koderna för att komma åt sin bilder via användarhemsidan.

4.4 Webbgränssnitt

I systemet finns två tillhörande hemsidor, en för administrativa funktioner och en där användare avsystemet kan hämta och dela de bilder de tar med surfplattan. Det finns även en sida som kommerligga lokalt på samma dator som Kinectprogrammet körs på.

KAPITEL 4. METOD 20

4.4.1 Administrativt webbgränssnitt

Den administrativa hemsidan, som visas i Figur 4.4, är till för att personalen på VisualiseringscenterC ska kunna ändra de parametrar som används av systemets chroma key. Det kan vara nödvändigtom de skulle flytta på stationen. Det är möjligt att modifiera gränsen som bestämmer om pixlar skamaskeras eller inte, samt intervallet som ska maskeras bort av djupkameran. Hemsidan är koppladtill Kinectprogrammet med websockets och gör det möjligt för en administratör att i realtid se hurändringar påverkar maskningen och sedan spara dessa ändringar. På hemsidan går det även att väljaatt återgå till de ursprungliga inställningarna eller låta programmet kalibreras automatiskt.

Figur 4.4: Gränssnittet för den administrativa hemsidan.

4.4.2 Webbgränssnitt för användare

För att användare ska komma åt sina bilder måste de navigera till en användarhemsida, vars startsidakan ses i Figur 4.5. Användarhemsidan består av ett fält där användaren kan skriva in sin bildspe-cifika kod som denne fått från Android-applikationen. Hemsidan kommunicerar med Firebase ochkontrollerar om koden finns i databasen. Om en användare har en giltig kod tolkas den tillhörande ba-se64-strängen om till en PNG-fil som presenteras för användaren. Denna bild kan användaren sedanladda ner eller dela på Facebook. För att enkelt kunna skapa en dynamisk och mobilanpassad sidaanvänds ramverket Bootstrap.

KAPITEL 4. METOD 21

Figur 4.5: Gränssnittet för hemsidan där användare hämtar sina bilder.

4.4.3 IP-konfiguration

Då all kommunikation med Kinectprogrammet sker genom websockets behöver de delar av systemetsom ska skapa en kontakt med programmet veta vilken lokal IP-adress datorn har. IP-adressen liggerpå Firebase där den hämtas av övriga kommunikatörer. För att säkerställa att det ligger rätt IP-adresskörs en webbsida lokalt på datorn som jämför datorns IP med den som ligger på Firebase, skulle dessaskilja sig laddas nya IP-adressen upp istället för den gamla.

4.5 Kommunikation mellan systemdelar

Kommunikationen inom systemet kan delas upp i två delar. Dels är det realtidskommunikationensom är tänkt att ansvara för allting som kommunicerar med Kinectprogrammet och dels är det denkommunikation som sker mot vår databas, vilket alltså är bilder som laddas upp från Android-appenoch hämtas från webbgränssnittet för användare.

4.5.1 Realtidskommunikation

Då det är många olika enheter och system som ska kunna kommunicera med varandra beslutades detatt använda TCP/IP-arkitekturen, alltså att kommunicera över ett gemensamt nätverk. Av säkerhets-skäl och för att ingen av den kommunikation som sker behöver göras på avstånd beslutades ocksåatt det gemensamma nätverket inte skulle vara internet, utan istället ett lokalt nätverk. För att kunnakommunicera med TCP/IP krävs naturligtvis att en kommunicerande enhet är ansluten till det nätverkdär kommunikationen är avsedd att göras på. Denna anslutning görs vanligtvis trådlöst via Wi-Fi ellertrådbundet via Ethernet, vilket är möjligt på alla de kommunicerande enheter som systemet innehåller.

För att upprätta en snabb kommunikation mellan enheterna används vanligtvis något form av Socket-protokoll. Då en av de kommunicerande systemen är en hemsida, valde vi att använda Websocket-protokollet vilket numera är implementerat i de flesta moderna webbläsare. Websocket-protokollet ärinte heller begränsat till bara webbläsare, utan går relativt enkelt att implementera även på våra andrasystem. Serverkoden körs i Kinectprogrammet, då det är genom detta all kommunikation behöver gå.

KAPITEL 4. METOD 22

För att bearbeta de signaler som skickas mellan enheterna och Kinectprogrammet byggde gruppenupp ett eget protokoll för hur meddelandena ska tolkas. Då kommunikationen är relativt enkel, ärockså protokollet därefter; vi bygger upp de meddelanden som skickas i två delar. Den första delen äralltid ett heltal som talar om vad det är för meddelandetyp, det kan till exempel vara att byta bakgrundeller bild skickas. Den andra delen innehåller tillhörande data till den första delen, exempelvis vilkenbakgrund som ska bytas till eller base64-kodad bilddata från en bild som tagits. De två meddelandenasepareras alltid av ett semikolon.

4.5.2 Databas

Den databaslösning som används är Firebase. Firebase är en plattformsoberoende molnlagringstjänst.Tjänsten erbjuder ett färdigt API för både JavaScript och Java vilket implementerats för användarhem-sidan respektive Android-applikationen. I databasen lagras alla bildfiler som base64-strängar tillsam-mans med koden som genererats och dagens datum. För att begränsa mängden data som lagras och påså vis minska på kostnaderna rensas databasen på gamla bilder. Detta görs med hjälp av en funktioni applikationen som jämför dagens datum med varje bilds tillhörande tidsstämpel. Funktionen körsvarje gång applikationen startas om. För att enkelt uppdatera datorns aktuella IP-adress laddas ävendenna upp till databasen. När Android-applikationen startas hämtas IP-adressen från databasen så attwebsocket-kommunikationen kan upprättas.

Av säkerhetsskäl används Firebase Custom Authentication som i sin tur använder sig av JSON WebTokens. Detta gör så att endast enheter som autentiserat sig mot Firebase har tillstånd att skriva tilldatabasen.

Kapitel 5

Resultat

Det slutliga resultatet av projektet är en station som har de delar presenterade i metod. När en an-vändare anländer till chroma key-stationen kommer en scen alltid visas och användaren kan direktinteragera med de objekt som finns i scenen. Det krävs alltså ingenting för att börja använda syste-met. Systemet startar automatiskt när datorn startas. En bild på hur stationen ser ut visas i Figur 5.1.Användaren står mellan en grön bakrund och en kinectkamera som är placerad under projektorskär-men. I taket sitter en projektor som återger den chroma-key:ade bilden. Vid sidan av stationen stårsurfplattan.

Figur 5.1: Stationen

23

KAPITEL 5. RESULTAT 24

5.1 Applikationen

Surfplattan kan användas av användaren själv eller någon som står brevid för att byta mellan miljöernaeller för att ta en bild av scenen och personen. Startvyn i applikationen på surfplattan visar tre styc-ken miljöer som användaren kan trycka på, se Figur 5.2. När användaren klickar på en av miljöernaskickas information till Kinectprogrammet om att programmet ska byta till den bakgrunden. Förutomdetta innehåller applikationens startsida en cirkulär knapp med en kamerasymbol på och texten ”Tabild”. När den trycks så startar en nedräkning på 5 sekunder, se Figur 5.3, och sedan tas en bild viaKinectprogrammet. Användaren får då välja om denna bild ska behållas eller slängas, se Figur 5.4.Behålls bilden laddar Kinectprogrammet upp bilden på Firebase och användaren får en personlig kodvia en textsträng eller en QR-kod, se Figur 5.5. Användaren kan sedan använda denna kod för attkomma åt sin bild via användarhemsidan. Applikationen startas automatiskt när surfplattan sätts på,och det finns därefter inget sätt att ta sig ur applikationen.

Figur 5.2: Startsidan i applikation


Figur 5.3: Vyn när användaren klickat på ”Ta bild”

Figur 5.4: Vyn när bilden tagits


Figur 5.5: Vyn om användaren väljer att hämta bilden

5.2 Miljöerna

Det finns tre olika miljöer som användaren kan välja mellan. Asteroiderna i rymdmiljön, se Figur 5.6,rör sig i bakgrunden, bubblorna i havsmiljön, se Figur 5.7, rör också på sig och kan även spräckas omanvändaren rör sin hand vid bubblorna. Även marken i kubmiljön, se Figur 5.8, ändras när användarenrör sig i bilden.

Figur 5.6: Rymdmiljön


Figur 5.7: Havsmiljön

Figur 5.8: Kubmiljön

5.3 Resulterande systemutveckling

Resultatet av systemutvecklingen utfördes till stora delar som planerat. Struktur på möten har varitdensamma genom hela projektet och det har hållits planeringsmöten, utvärderingsmöten och dagliga


möten som planerat. De bedöms ha fungerat bra och bidragit till en ökad struktur och formalitet förarbetet. Tack vare att en agil utvecklingsmetod valdes gjordes diverse omstruktureringar i planeringtidigt vilket gjorde att projektet avancerade arbetet snabbt i början.

Ett ansvarsområde som ändrades från den ursprungliga planen var Trello-ansvarig, eftersom det an-sågs vara ett överflödigt ansvarsområde då Trello uppdaterades av de mindre arbetsgrupper som bilda-des under varje sprint. Istället tillkom mindre ansvarsområden såsom bokningsansvarig för sal vilketvar ett behov som upptäcktes under projektets gång. Övriga ansvarsområden har skötts enligt plane-ringen.

Testning av systemet har varit den största avvikelsen från planeringen. Anledningen till att system-tester och även användartester inte lyckades genomföras som planerat var att tiden för installationunderskattades kraftigt och inte genomfördes i praktiken förrän sista sprinten.

Rutiner för kodgranskning har också varit ett moment som inte följts. Trots att det fanns en planoch struktur för detta har den ignorerats av samtliga Scrum Mastrar och gruppmedlemmar underprojektets gång. Det kan poängteras att kodgranskning har gjorts, vilket resulterat i refaktoreringaroch korrigeringar, dock har granskningen inte skett enligt planen och det har i resulterat i att vissadelar av kod inte granskats lika noggrant som andra. Framförallt i slutet av projektet då mycket tidgick åt till att färdigställa installationen bortprioriterades kodgranskning.

Under avsnitt 6.2 analyseras mer ingående anledningar som lett till problem samt vad som hade kunnatgöras bättre inom systemutveckling om projektet genomförts igen.

Kapitel 6

Analys och diskussion

I detta avsnitt diskuteras projektets resultat, dess utvecklingsmöjligheter och projektets påverkan uti-från etiska perspektiv.

6.1 Arbetssätt

De tillvägagångssätt som under projektets gång använts för att få in behövd funktionalitet har i mångafall diskuterats gentemot andra lösningar som skulle löst samma problem. Ofta när ett problem harbehövts lösas har den metod som först använts för att implementera lösningen modifierats, då gruppenhoppats på en effektivare eller snyggare lösning via en annan metod. Exempelvis har ett antal olikametoder för maskningen implementerats, där olika färgrymder har använts för att undersöka mask-ningens kvalité samt hur beräkningstunga olika lösningar blir för systemet. Att använda CIELABsom färgrymd var en tanke som tidigt uppstod, men ett antal metoder implementerades med and-ra färgrymder efter detta, eftersom CIELAB var alltför beräkningstungt för programmet. Lösningenåtergick sedan till att använda sig av CIELAB när relaterade beräkningar utfördes på grafikprocessornistället för centralprocessorn, då detta gjorde bildens fps acceptabel samtidigt som kvalitén blev bättreän med övriga färgrymder.

De flesta metoder som systemet i nuläget använder för att fungera korrekt har på samma sätt som ovandiskuterats inom gruppen, och implementerats jämsides andra metoder som sedan har jämförts medvarandra. Detta har resulterat i att de flesta metoder som används fungerar effektivt, och att systemetär väl optimerat.

6.2 Systemutveckling

Att arbeta agilt har gett många fördelar till gruppen för att kunna ändra på rutiner som troddes fungerabra i teorin men som inte fungerade i praktiken. Ett viktigt beslut som togs tidigt var att påbörjaarbetet med android-applikationens funktionalitet och design i ett tidigt skede. Det var något som tillen början planerades ha låg prioritet, men som sedan påbörjades ändå då det annars blev för mångagruppmedlemmar på samma högprioriterade uppgift, vilket resulterade i ineffektivt arbete. Genomatt bredda arbetsuppgifterna tidigt avancerade projektet väldigt snabbt i början. Att sysselsätta allamedlemmar med effektivt arbete, som man vet måste göras förr eller senare, bör prioriteras högre änatt färdigställa en högprioriterad uppgift om man märker att fler medlemmar ger ett ineffektivt arbete.

Att ha roterande ansvarsområden, då framförallt rollen som Scrum Master har varit både positivt ochnegativt. Fördelen är att fler gruppmedlemmar har fått känna på rollen och att fler synsätt har fått ta

29

KAPITEL 6. ANALYS OCH DISKUSSION 30

en ledande roll i utvecklingen. Nackdelen har dock varit att ingen riktigt hunnit mogna i rollen medtiden. Troligtvis var det detta som gjorde att det aldrig betonades att följa de rutiner som satts förkodgranskning då det lätt kunde ses som nästa eller kanske till och med föregående Scrum Mastersuppgift att göra eller ha gjort det. Det kan dock också poängteras att ingen i gruppen önskade varaScrum Master så valet att rotera kan ha varit en bättre lösning än att tvinga någon som inte känt sigbekväm i rollen att vara det genom hela projektet. Det ideala hade varit om en medlem känt sig manadatt vara det genom hela projektets gång då det ger mindre utrymme för att uppgifter ses som någonannans jobb.

En annan roll som varit delad har varit kundkontakten. Kundkontakten bedöms ha varit bra underprojektets gång. Något som dock ställde till problem var att fokus hos hela projektgruppen låg påmjukvaruutvecklingen. I möten med kund lades stor vikt vid kundens önskemål och krav, men helatiden med stort fokus på systemet som mjukvara. Även om krav på utrustning såsom Kinect, datoroch surfplatta framfördes så tidigt som möjligt till kunden var det ytterligare utrustning som pro-jektgruppen förbisett att beställa, såsom grönskärm och ställ till surfplattan. Detta gjorde att när detnärmade sig för installation var det många frågor som dök upp och både utrustningskrav och diversepraktikaliteter var tvungna att lösas. Vissa saker som projektgruppen antog att kunden hade snabbalösningar för visade sig ta längre tid än väntat att få ordning på. Ett exempel på det var datorn somkunden sa fanns tillgänglig från början, men när det väl var dags för gruppen att använda den tog detöver en vecka för kunden att ha den färdig med rätt operativsystem - samt att det då visade sig attUSB-portar inte fungerade. Kunden antog att det var projektgruppens uppgift att montera allt på platsoch projektgruppen hade antagit att kunden redan hade rutiner för sådant, och hade förväntat sig merhjälp med detta än vad som erbjöds. Oväntade arbetsuppgifter som uppstod var alltifrån att kolla uppbäst alternativ mellan målarfärg och tyg till grönskärmen till att lösa vart strömförsörjningen för surf-plattan ska ske på plats. Bara en sådan sak som att fixa fram material för att rikta om de strålkastaresom redan fanns på plats var en för gruppen oförutsedd uppgift som på samma gång var självklar ochnödvändig för projektet.

Problemen med att installationen blev förskjuten kan spåras tillbaka till att en tydlig dialog saknadesmed kunden angående vems uppgift flera av monteringsmomenten var. Oavsett vems uppgift mon-teringen var borde projektgruppen ändå ha förutsett att monteringen i sig kan ta tid. Hade projektetgjorts om idag rekommenderas en tydligare planering från projektgruppens sida av montering ochkanske även ge kunden en deadline för när de ska ha utrustningen tillhanda. En intressant aspekt i dethär projektet är att det är projektgruppen som varit mer benägen att få projektet klart i tid till deadlinepå grund av projektredovisning snarare än kunden, som inte själva hade en deadline för när de ville hasystemet färdigt. I företagsvärlden kan det antas vara tvärtom i de flesta fall, det vill säga att deadlinestyrs mer av kundens behov än projektgruppens.

6.3 Teknik och utvecklingsverktyg

Under projektet har flera olika tekniker använts. Här diskuteras olika problem och lösningar medteknikerna under projektets gång

6.3.1 Chroma key station

Att arbeta med Kinect har medfört fördelar såväl som nackdelar. En av de största nackdelarna medKinect är att man begränsar sig till Windows som operativsystem. I gruppen löstes det genom attinstallera Windows på externa hårddiskar vilket fungerade men det var något som förbrukade enmängd arbetstimmar som kunde spenderats bättre. Fördelar med Kinect är bland annat den inbyggda


IR-kamera tillsammans med Windows egna Kinect SDK. IR-kameran gör det möjligt att läsa bådefärg och djup vilket öppnar upp för möjligheten att filtrera inte enbart på färgen. Kinect SDK förserutvecklare med färdiga funktioner för exempelvis body tracking, färg- och djupmaskning. Detta gördet både lättare och utvidgar möjligheterna för interaktiv programmering.

Vid installationen av stationen på visualiseringscentret löste vi bakgrunden med tyg istället för färgsom det hade varit innan. Detta medför att det blir dyrare att ersätta vid slitage men det blir inte likamycket reflektioner mot tyg som en målad vägg.

Valet att använda Urho3D som spelmotor har fungerat bra. Den är avskalad jämfört med liknandemotorer men har önskad funktionalitet. Nackdelen är att Urho3D är nytt och dokumentationen varunder projektets gång bristfällig. Detta vägs delvis upp av att man snabbt får svar på olika forum menhar ändå varit ett problem som kostat tid. Motorn har potential och när det hunnit växa och förbättratdokumentationen kan det bli riktigt bra.

6.3.2 Gränssnitt på surfplatta

Kommunikationen med websockets mellan surfplattan och Kinectprogrammet fungerar bra. Teknikenvaldes för att undvika att surfplattan behövde vara kopplad till datorn via en kabel. Det sker inga tids-förskjutningar utan ändringarna sker momentant. Därför har ingen annan metod för kommunikationbehövts implementerats.

6.3.3 Hemsida

Vid delning av bild till Facebook är det nu inte en bild som delas direkt utan en länk. Länken ledertill visualiseringscentrets hemsida där bilden laddas in från databasen. Detta leder till att en bild somär delad inte får rensas från databasen. Om bilen hade gått att dela genom direkt uppladdning tillFacebook hade detta problem undvikits men pga. att bilderna sparades i base64-format försvåradesdetta och ingen lösning hittades förutom delning utav en länk.

6.3.4 Administrationsgränssnitt

Administrationsgränssnittet är en enkel hemsida där det stora är kommunikationen med Kinectpro-grammet. Kommunikationen precis som för surfplattan sker genom websockets. För enkelhetens skullhar både administrationsgränssnittet och surfplattan kommunicerat via samma server för att sedan lå-ta Kinectprogrammet sortera mellan de meddelanden som kommer. När administrationsgränssnittetintroducerades till systemet uppkom en del buggar men utöver det har websockets fungerat bra. Real-tidkommunikationen fungerar dels bra för administratörerna men har också förenklat testning då mandirekt ser hur chroma-keyingen förändras när dess parametrar ändras i realtid.

6.4 Resultat

Gruppens initiala plan var att uppfylla kraven som kunden hade, och även få in interaktiva objekt iscenerna. Dessa krav har uppfyllts, och kunden har under möten verkat nöjd med det arbete som ut-förts. Interaktion har också implementerats, och därmed har resultatet blivit det som gruppen planerat.Alltså har syftet med projektet uppfyllts utan att ha utelämnat någon del.


6.5 Arbetet i ett vidare sammanhang

Det finns en del etiska aspekter som man bör ha i åtanke när man jobbar med projektet. Det handlarfrämst om lagring av personuppgifter, bilder och eventuellt missbruk av de bilder som tas.

Det system som utvecklats tillåter användarna att ta bilder på sig själva när de befinner sig i miljön.Dessa bilder lagras sedan på en databas för att användaren själv ska kunna hämta hem sin bild ellerlägga upp den på Facebook. Bilderna som sparas lagras inte mer än en månad om inte användaren väl-jer att dela bilden på Facebook, då sparas bilden längre så att länken som delades ska kunna användasunder en längre tid. Användaren behöver aldrig ange några personliga uppgifter, såsom mejladresseller Facebook-lösenord, för att använda de funktionerna.

Den personliga integriteten hos besökarna kan också diskuteras. Kameran som finns på stationensparar aldrig någon video utan det som kameran filmar hanteras i realtid och återges på skärmenframför användaren. De bilder som kan tas görs av besökaren själv. Det är alltså deras eget val att taen bild och föreviga tillfället. Ingen användare kommer ovetandes att sparas i bild eller videoform.

Troligtvis finns det inget hinder för att systemet kan missbrukas till viss del. Opassande bilder medanvändare som gör obscena gester, kanske till och med tar nakenbilder, är något som är möjligt,om än troligtvis väldigt ovanligt då bilden tas på en förhållandevis offentlig plats. Det kan dockvara ett argument för att t.ex. inte ha ett album på kundens hemsida med användarnas senaste bildereftersom kunden, Visualiseringscenter, då är den som delar bilden på nätet istället för besökaren.Dessutom skulle ett sådant album eventuellt gå emot tidigare nämnda principer om den personligaintegriteten. Om kunden vill ha en logotyp på bilderna för marknadsföring kan det även vara bra attnämna möjligheten till missbruk och låta kunden göra en egen bedömning av riskerna och fördelarmed att associeras med bilderna deras besökare tar.

6.6 Utvecklingsmöjligheter

Om det hade funnits mer tid eller arbetskraft över hade projektet kunna utvecklats på olika sätt. Enidé som fanns i början av projektet var att förbättra den administrativa hemsidan till att även göradet möjligt för personal på Visualiseringscenter C att modifiera miljöer. Detta skulle i sådant fall skegenom att personalen kan välja att byta ut en bakgrund, samt kunna placera ut de animerade modellersom finns på valfri plats i scenen. Detta skulle inte medföra att personalen kan lägga till nya modeller,men eftersom det möjliggör många kombinationer av bakgrunder och modeller skulle det bli mervariation för besökare, och återkommande besökare skulle kunna uppleva nya miljöer varje gång deär där.

Ett alternativ vid fortsatt arbete med projektet skulle vara att även implementera enklare spel, vilkettroligtvis skulle vara mer underhållande för besökare. Eftersom Kinect kan spåra upp till 6 personersskelett samtidigt, och även två personers handrörelser, skulle spel med flera spelare kunna implemen-teras. Det största problemet med att implementera ett spel är att det är svårt att få det lika intuitivt somde miljöer som finns för tillfället, eftersom det kan vara svårt att veta vad målet i spelet är utan att fåen beskrivning av det innan.

Varje Kinect har en inbyggd mikrofon. När mikrofonen uppfattar ljud kan Kinect känna igen specifikaord via taligenkänning. Detta är en del av Kinect som under projektets gång har varit helt oberörd, somvid ett fortsatt arbete med projektet skulle kunna användas för att få in en helt ny typ av funktionaliteti olika miljöer. Eftersom Kinect dessutom kan lokalisera ljudets horisontella position i förhållandetill Kinecten är det enkelt att ignorera allt ljud som kommer från andra områden än där användarenbefinner sig. Om inte detta hade varit möjligt hade mikrofonen varit oanvändbar, med tanke på denhöga nivå av bakgrundsbrus som kan uppstå vid företag med många besökare.


6.7 Problem under arbetets gång

Under projektets gång har gruppen stött på en del oväntade problem som tagit upp onödig tid. Ef-tersom stora delar av projektet använder sig av olika programvaror och bibliotek har dessa behövtsinstalleras och inkluderats, och det finns många små saker som kan gå fel på vägen. Detta har märktsav under projektets gång, då det vid ett antal tillfällen uppstått problem eftersom någon har missat ettsteg någonstans under installationen. När någon har fått ett av dessa problem har det oftast varit oklartvarför det uppstått, och det har därmed tagit gått åt onödigt mycket tid till felsökning.

Kapitel 7

Slutsatser

Vid projektets start sattes frågeställningar upp. Här besvaras dessa utifrån erfarenheter från projektetsgång.

• Hur kan kvalitén på maskningen av användaren i interaktionsmiljön förbättras jämfört medmaskningen i de exempelprogram som finns i Kinect SDK?

I de exempelprogram som fanns användes enbart data från djupkameran för att få fram en maskning avanvändaren. En sådan lösning ger hål i användaren om det skulle finnas något framför användaren ochpå grund av skillnader i upplösning på färg- och djupkamera uppstår hackiga kanter på maskningen.En lösning som gör att både hålen och kanterna undviks är att ställa användaren framför en enfärgadbakgrund och klippa bort alla pixlar som har samma färg som bakgrunden.

• För att projektets arbetsgång ska vara effektiv krävs det att delar som ska göras inte är beroendeav delar som inte gjorts. För att undvika detta problem är det viktigt att lokalisera flaskhalsar.Vad är detta projektets mest kritiska flaskhalsar?

I början av projektet förutspåddes kommunikationen mellan systemets delar som en flaskhals. Därförbörjade arbetet med websockets tidigt, redan innan de kommunicerande delarna varit klara. Projektethar bestått av många olika delar och för att undvika förlorad effektivitet utvecklades alla delar mereller mindre parallellt. På så vis har det undvikits att gruppen varit beroende av att en del ska varithelt klart innan arbetet på nästa del påbörjats. Här har alltså inte riktlinjerna för sprintsen följts tillfullo. En oförutsedd flaskhals visade sig vara installationen och monteringen av systemet. Även omdetta i sig inte hindrat gruppen från att vara sysselsatt med förbättringar resulterade detta i uteblivnaanvändartester och kraftigt förskjutna systemtester.

• För att barn i åldrarna 5-10 år ska kunna använda stationen är det viktigt att de förstår hurmenyer och program fungerar. Hur utformas systemets användargränssnitt för att det ska varapå bästa sätt anpassat till tänkt målgrupp?

Den viktigaste med designen av systemets gränssnitt är att målgruppen direkt ska förstå hur systemetanvänds. Därför har det valts att helt hålla menyval och inställningar borta från projektorskärmen ochha allt sådant på surfplattan. På så vis kan en användare i målgruppen direkt ställa framför kameranoch börja använda systemet. Systemet går alltså att använda utan att användaren till en början ens vetom att surfplattan finns på sidan.

När surfplattan sedan upptäcks av användaren är användargränssnittet uppbyggt så att det går atttesta sig fram till vad funktionerna gör. Ett barn i målgruppen ska inte behöva läsa instruktioner eller

34

KAPITEL 7. SLUTSATSER 35

analysera symboler för att förstå vad som händer när de trycker på skärmen. Därför består nästan helagränssnittet av tryckbara bilder som gör att projektorbildens bakgrund ändras. När ett barn trycker påskärmen ser de att bakgrunden ändras och de kan trycka och välja så mycket de vill.

Litteraturförteckning

[1] John MacCormick, How does the Kinect work?, Dickinson College, hämtad: 2016-05-09http://users.dickinson.edu/ jmac/selected-talks/kinect.pdf

[2] Wenjun Zeng & Zhengyou Zhang, Microsoft Kinect Sensor and Its Effect, hämtad: 2016-06-08http://research.microsoft.com/pubs/179157/Microsoft%20Kinect%20Sensor%20and%20Its%20Effect%20-%20IEEE%20MM%202012.pdf

[3] Real-Time Human Pose Recognition in Parts from Single Depth Images, Microsoft ResearchCambridge & Xbox Incubation, hämtad 2016-05-09http://research.microsoft.com/pubs/145347/BodyPartRecognition.pdf

[4] Kang G. Shin & Parameswaran Ramanathan, Real-Time Computing: A New Discipline of Com-puter Science and Engineering, 1994-01-01, hämtad: 2016-05-09https://kabru.eecs.umich.edu/papers/publications/1994/ramanathan-shin-ieee-proceedings.pdf

[5] Techwrites future, UDP - User Datagram Protocol, IPv6.com, 2008, hämtad: 2016-05-09http://ipv6.com/articles/general/User-Datagram-Protocol.htm

[6] Microsoft staff, TCP/IP Protocol Architecture, Microsoft, hämtad: 2016-05-09https://technet.microsoft.com/en-us/library/cc958821.aspx

[7] Anders Carlsson, Using websockets in native iOS and Android apps, Elabs.se, 2014-02-12, häm-tad: 2016-05-09http://www.elabs.se/blog/66-using-websockets-in-native-ios-and-android-apps

[8] W3School Staff, PHP 5 tutorial, W3School, 1999-2016, hämtad: 2016-05-09http://www.w3schools.com/php/

[9] Steve Suehring & Janet Valade, How PHP Works, For Dummies, 2012-04-01, hämtad: 2016-05-09http://www.makeuseof.com/tag/what-is-javascript-how-works/

[10] Firebase Staff, Web Quickstart, Firebase, 2012-2016, hämtad: 2016-05-09https://www.firebase.com/docs/web/quickstart.html

[11] Kishin Manglani, Top 5 Parse Alternatives, RAYWENDERLICH, 2016-02-11, hämtad: 2016-05-09https://www.raywenderlich.com/126098/top-5-parse-alternatives

[12] Cheung Tam, When Third-Party APIs Will (and Won’t) Benefit Your Business, Program-mableWeb, 2016-02-11, hämtad: 2016-05-09http://goo.gl/cyQW8A

[13] Kitware Inc., CMake overview, hämtad: 2016-05-05https://cmake.org/overview/

36

LITTERATURFÖRTECKNING 37

[14] Google, Google Style guide, hämtad: 2016-02-20https://github.com/google/styleguide

[15] Urho3D developers, About Urho3D, hämtad: 2016-05-05http://urho3d.github.io/

[16] Adrian Ford & Alan Roberts, Colour Space Conversions, Poynton.com, 1998-08-11, hämtad:2016-05-09,http://www.poynton.com/PDFs/coloureq.pdf

[17] Boost, Boost C++ Libraries, hämtad: 2016-05-09http://www.boost.org/

[18] Wojciech Jarosz, Fast Image Convolutions Fast Image Convolutions, 2001, hämtad: 2016-06-01http://web.archive.org/web/20060718054020/http://www.acm.uiuc.edu/siggraph/workshops/wjarosz_convolution_2001.pdf

[19] OpenSSL Software Foundation, OpenSSL, 2015, hämtad: 2016-05-09https://www.openssl.org/

Bilaga A

UML diagram

Figur A.1: Aktivitetsdiagram

38

Bilaga B

Involverade personer

B.1 Projektgruppen

Karin ReidarmanVarit med och skapat administrationshemsidan och kommunikationen mellan denna och Kinectpro-grammet. Har också implementerat designen på androidapplikationen. Haft rollen som Scrum Masterunder sprint 4.

Lovisa HasslerFrämst suttit med implementaion av Urho3D i Kinectprogrammet. Även grundläggande funktionaliteti appen, samt varit kundkontakt. Scrum Master under sprint 5.

Henrik NilssonMestadels arbetat med Kinectprogrammet, samt säkerheten kring applikationen. Även arbetat småttmed Urho3D. Haft rollen som Scrum Master under sprint 3.

Simon HedlundAndroid: Programmerade grunden för applikationen med fragments. Hemsida: Slutförde design ochdynamik på hemsida. Programmerade även funktionalitet för bilddelning och nedladdning av bilder.Kinect: Programmerat partikelsystem med interaktion. Haft rollen som kundkontakt och Scrum Mas-ter under sprint 1.

Cristoffer SärevallFrämst arbetat med Kinectprogrammet, det administrativa gränssnittet och kommunikation mellandessa.

Filip KantedalKinectprogrammet: Webbsocketserver, implementerat Kinect SDK och Urho3D och en del Chromakeying-funktionalitet. Android-applikation: främst med Websocket och UI-programmering. Admin-gränssnit: UI och uppkoppling mot Websocketserver.

Adrian PalmquistUtvecklat Android-applikationen och implementerat Firebase samt viss Websocket-funktionalitet idenna. Har även jobbat med hemsidan och animerat en 3D-modell till en scen. Haft rollen som ScrumMaster under sprint 2.

39

BILAGA B. INVOLVERADE PERSONER 40

B.2 Utomstående

Karljohan Lundin PalmeriusKund till projektet och examinator i kursen TNM094.

Andreas AnglesjöKund och kontakt på Visualiseringscentret C.

Katarina SperlingInvolverad i början av projektet när kraven utformades.

Anna ÖstInvolverad i slutet av projektet med godkännande av resultat.

Bilaga C

Gantt schema

Figur C.1: Gantt

41

chroma key - linköping universityweber.itn.liu.se/~karlu20/courses/tnm094/reports/... · rapporten...

Documents