Hur är det att vara en robot?

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

Vårterminen 2017 | LIU-IDA/LITH-EX-G--17/040--SE

Hur är det att vara en robot?

What is it like to be a bot?

Robin Christensen, Jacob Lundberg,

Ylva Lundegård, Emil Segerbäck, Patrik Sletmo,

Teo Tiefenbacher, Jon Vik, David Wajngot

Handledare : Rikard Nordin Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

c

Robin Christensen, Jacob Lundberg, Ylva Lundegård, Emil Segerbäck, Patrik Sletmo, Teo Tiefenbacher, Jon Vik, David Wajngot

Sammanfattning

N¨ar b˚ade robotar och VR utvecklas i rask takt ¨ar det sp¨annande att se vad f¨or anv¨andningsomr˚aden de kan utnyttjas inom. I det h¨ar projektet har ett gr¨anssnitt mellan VR och robot utvecklats, med m˚alet att kunna bedriva forskning inom kognitionsvetenskap. Projektet har utf¨orts av ˚atta studenter p˚a

Link¨opings universitet i form av ett kandidatarbete. Projektet och denna rapport ¨amnar att besvara om slutprodukten fungerar tillr¨ackligt bra f¨or att

kunna bedriva kognitionsvetenskaplig forskning, vilka erfarenheter som kan erh˚allas fr˚an projektet, huruvida en systemanatomi kan underst¨odja arbetet och vilka mjukvarul¨osningar som kan utnyttjas generellt f¨or att bidra till en

h˚allbar utveckling och om dessa ¨ar applicerbara p˚a detta projekt. Slutprodukten anses av projektgruppen och best¨allaren ha tillr¨acklig funktionalitet f¨or att bedriva viss kognitionsvetenskaplig forskning. M˚anga ov¨arderliga erfarenheter har erh˚allits, framf¨or allt hur kommunikation anv¨ands

f¨or arbete inom en projektgrupp med uppdelade ansvarsomr˚aden. ¨Aven erfarenheter kring kravhantering och versionhantering av bin¨ara filer har erh˚allits. En systemanatomi kan ge st¨od p˚a olika s¨att under ett projekt som detta. Flera metoder kan utnyttjas f¨or att bidra till h˚allbar utveckling, men

arbetet som kr¨avs ¨ar inte v¨art att utf¨ora i ett projekt av denna storlek. Projektgruppen ¨ar n¨ojd med sin insats och projektet i sin helhet. Det har varit

en oerh¨ort givande erfarenhet, och v˚ar f¨orhoppning ¨ar att best¨allare och n¨asta ˚ars studenter ska kunna utnyttja produkten och bygga vidare p˚a den. Vi hoppas ¨aven att l¨asare av rapporten ska njuta av l¨asningen och l¨ara sig n˚agot

F¨

orfattarnas tack

Vi skulle vilja tacka v˚ara kunder Sam Thellman och Mattias Arvola f¨or deras intresse och feedback under projektet samt v˚ar handledare Rikard Nordin f¨or

v¨agledningen han gett oss. Vi vill ¨aven tacka Tore Haglund och KVIT Conference f¨or att vi fick m¨ojligheten att st¨alla ut p˚a teknikm¨assan i

Projektidentitet

Projektgruppsnummer 3, 2017

Institutionen f¨or datavetenskap (IDA) vid Link¨opings universitet (LiU)

Namn Ansvar E-post

Robin Christensen (RC) Kvalitetssamordnare robch386@student.liu.se Jacob Lundberg (JL) Teamledare jaclu010@student.liu.se Ylva Lundeg˚ard (YL) Dokumentansvarig ylvlu780@student.liu.se Emil Segerb¨ack (ES) Arkitekt, konfigurationsansvarig emise935@student.liu.se Patrik Sletmo (PS) Utvecklingsledare patsl736@student.liu.se Teo Tiefenbacher (TT) VR-specialist teoti001@student.liu.se

Jon Vik (JV) Testledare jonvi039@student.liu.se

David Wajngot (DW) Analysansvarig davwa195@student.liu.se Kund: IDA - Institutionen f¨or datavetenskap, Link¨opings universitet

Kontakperson hos kund: Sam Thellman, 013-282410, sam.thellman@liu.se Mattias Arvola, 013-285703, mattias.arvola@liu.se

Definitioner

Asana

Asana ¨ar en webbaserad applikation f¨or att koordinera arbetslag i projekt. Choregraphe

Choregraphe ¨ar ett program f¨or att p˚a ett enkelt s¨att kunna animera Pepper i datorn.

CodeFactor

Ett verktyg f¨or kodgranskning som implementeras i ett GitHub-repo. Feature freeze

Feature freeze ¨ar en punkt i utvecklingsprocessen d˚a man slutar l¨agga till nya funktioner och ist¨allet satsar p˚a att fixa buggar.

Git

Git ¨ar ett program f¨or versionshantering. Git-LFS

Ett till¨agg till Git som underl¨attar versionshantering av stora filer genom att lagra dem utanf¨or Git-repot.

Git-repo

Den plats d¨ar alla filer som versionshanterats under Git lagras tillsammans med dess historik.

GitHub-repo

Ett Git-repo som lagras p˚a versionshanteringsplattformen GitHub. HTC Vive

Ett headset utvecklat av HTC och Valve Corporation med tillh¨orande handkon-troller som m¨ojligg¨or anv¨andning av VR.

IDA

Institutionen f¨or datavetenskap vid Link¨opings universitet. KVIT conference

KVIT ¨ar en ˚arlig konferens om kognitionsvetenskap och informationsteknik. Konferensen riktar sig fr¨amst mot studenter, f¨oretag och forskare, men ¨ar ¨oppen f¨or alla. Till konferensen tillh¨or ¨aven en teknologim¨assa. Temat f¨or m¨assan 2017 var “Extend our limits” (sv. Utvidga v˚ara gr¨anser).

Microsoft Visual studio

Visual Studio ¨ar en utvecklingsmilj¨o utvecklad av Microsoft. Visual Studio st¨odjer m˚anga spr˚ak, bland annat C#.

NAOqi OS

NAOqi ¨ar Peppers operativsystem. Det ¨ar utvecklat av Aldebaran Robotics och ¨

OpenCV

Open Computer Vision ¨ar ett kodbibliotek f¨or datorseende och maskinl¨arning som ¨ar sl¨appt som ¨oppen k¨allkod.

Pepper

Pepper ¨ar en robot tillverkad av f¨oretaget Aldebaran. Den ¨ar humanoid med huvud och armar, och f¨orflyttar sig med hj¨alp av hjul. Den ¨ar 120 cm l˚ang. Product owner

Den person som ¨ar projektets huvudintressent och ansvarar f¨or att prioritera en lista ¨over funktioner eller uppgifter i utvecklingsmetodiken Scrum.

Realtid

En responstid som ¨ar l¨agre ¨an 500 ms. Scrum master

En sorts coach som ser till att utvecklingsteamet f¨oljer processen som h¨or till utvecklingsmetodiken Scrum, och som ocks˚a hj¨alper teamet att prestera s˚a bra som m¨ojligt.

SDK

“Software Development Kit”. Ett utvecklingsverktyg f¨or utveckling mot ett spe-cifikt system.

shareLaTeX

ShareLaTeX ¨ar en webbaserad applikation f¨or att skriva i typs¨attningssystemet LaTeX.

Slack

Slack ¨ar ett chattverktyg d¨ar man kan dela in sina konversationer i olika kanaler. SteamVR

Speldistribueraren Steams kompletta system f¨or virtual reality som best˚ar av HTC Vive, handkontroller och ett system f¨or precis positionsbest¨amning. Leve-reras tillsammans med ett SDK som g˚ar att integrera med Unity.

Trello

Trello ¨ar en webbaserad applikation f¨or projektledning med m¨ojlighet att s¨atta flera gruppmedlemmar p˚a samma kort.

Unity

Unity ¨ar en spelmotor som anv¨ands f¨or att utveckla spel f¨or en rad olika platt-formar. Den programmeras i .NET-spr˚ak.

Unreal

Unreal ¨ar en spelmotor som anv¨ands f¨or att utveckla spel f¨or en rad olika platt-formar. Den programmeras i C++ eller ett grafiskt spr˚ak som kallas Blueprint. Virtual reality (VR)

Virtual reality ¨ar teknik som simulerar en virtuell milj¨o f¨or anv¨andaren och m¨ojligg¨or interaktion med denna simulering.

Wrapper

Ett omslutande kod-lager som inkapslar kod och g¨or att den kan anropas genom sig.

Inneh˚

all

I

Gemensam del

1

3.2.4 Microsoft Visual Studio . . . 5

3.2.5 HTC Vive . . . 6 3.2.6 Steam . . . 6 3.3 Programmeringsspr˚ak . . . 6 3.3.1 C# . . . 6 3.3.2 F# . . . 7 3.3.3 C++ . . . 7 3.4 Utvecklingsmetodik . . . 7 3.4.1 Scrum . . . 7 3.4.2 Kanban . . . 8

3.5 Aktiviteter f¨or att minska energi˚atg˚angen . . . 8

3.5.2 L˚agniv˚aprogrammering . . . 8

3.5.3 Polla mindre frekvent . . . 9

3.6 Systemanatomi . . . 9 4 Metod 10 4.1 F¨orstudie . . . 10 4.2 Projektorganisation . . . 10 4.2.1 M¨oten . . . 10 4.2.2 Gruppkontrakt . . . 10 4.2.3 Koordinering . . . 11 4.2.4 Roller . . . 11 4.3 Utvecklingsmetod . . . 12 4.3.1 Scrum . . . 12 4.3.2 Kanban . . . 13 4.3.3 Kodgranskning . . . 13 4.3.4 Testning . . . 13 4.4 Utvecklingsverktyg . . . 14

4.5 Insamling av reflektioner fr˚an KVIT Conference . . . 15

4.6 Metoder f¨or att f˚anga erfarenheter . . . 15

4.6.1 Granskning . . . 15 4.6.2 Iterationsutv¨arderingar . . . 15 4.6.3 Veckom¨oten . . . 16 5 Resultat 17 5.1 Systembeskrivning . . . 17 5.2 Systemanatomi . . . 18 5.3 Gemensamma erfarenheter . . . 20 5.3.1 Agil utveckling . . . 20

5.3.2 Distribution av bin¨ara filer . . . 20

5.3.3 Kravhantering . . . 20

5.3.4 Jobba i ett st¨orre projekt . . . 21

5.4 KVIT Conference . . . 21

5.5 Oversikt ¨¨ over individuella bidrag . . . 21

6 Diskussion 22 6.1 Systemet . . . 22 6.2 F¨orstudie . . . 23 6.3 Projektorganisation . . . 23 6.4 Utvecklingsmetodik . . . 24 6.5 Utvecklingsverktyg . . . 24

6.6 Insamling av reflektioner fr˚an KVIT Conference . . . 24

6.7 Metoder f¨or att f˚anga erfarenheter . . . 25

6.8 H˚allbar utveckling . . . 25

7 Slutsatser 27 7.1 Kan slutprodukten anv¨andas till forskning? . . . 27

7.2 Intressanta erfarenheter inf¨or framtida projekt . . . 27

7.3 Systemanatomi . . . 28

7.4 H˚allbar utveckling . . . 28

II

Individuella bidrag

29

A.1.1 Syfte . . . 29

A.1.2 Fr˚agest¨allning . . . 29

A.3 Teori . . . 30

A.3.1 Inneb¨orden av kodgranskning . . . 30

A.3.2 Syftet med kodgranskning . . . 30

A.3.3 Antal kodgranskare . . . 31

A.3.4 CodeFactor . . . 31

A.4 Metod . . . 32

A.5 Resultat . . . 32

A.5.1 Implementation . . . 32

A.5.2 Resultat fr˚an utv¨ardering . . . 33

A.6 Diskussion . . . 34

A.6.1 Unders¨okningen . . . 34

A.6.2 Kvalitetskostnad . . . 35

A.7 Slutsatser . . . 36

B Spatial n¨arvaro av Jacob Lundberg 37 B.1 Inledning . . . 37 B.1.1 Syfte . . . 37 B.1.2 Fr˚agest¨allning . . . 37 B.2 Bakgrund . . . 37 B.3 Teori . . . 37 B.3.1 Telepresence . . . 38 B.3.2 Spatial n¨arvaro . . . 38

B.3.3 Integrated Information Theory (IIT) . . . 39

B.3.4 Upplevelsekrav f¨or ett VR-headset . . . 40

B.4 Metod . . . 41

B.4.1 Systemet ur ett telepresence-perspektiv . . . 41

B.4.2 Anv¨andartester . . . 42

B.5.1 Systemet ur ett telepresence-perspektiv . . . 43 B.5.2 Anv¨andartester . . . 44 B.6 Diskussion . . . 45 B.6.1 Metod . . . 45 B.6.2 Resultat . . . 46 B.7 Slutsatser . . . 47

C Olyckor med robotar av Ylva Lundeg˚ard 49 C.1 Inledning . . . 49

C.1.1 Syfte . . . 49

C.1.2 Fr˚agest¨allning . . . 49

C.2 Bakgrund . . . 49

C.3 Teori . . . 49

C.3.1 Lagar kring olyckor med robotar . . . 50

C.3.2 Kulturell eftersl¨apning . . . 50

C.3.3 Etik och moral . . . 50

C.4 Metod . . . 50

C.4.1 Litteraturstudie . . . 50

C.4.2 Gruppunders¨okning . . . 50

C.5 Resultat . . . 51

C.6 Diskussion . . . 53

C.6.1 L¨arande av sin omgivning . . . 53

C.6.2 Utvecklarens ansvar . . . 54

C.6.3 Unders¨okningsresultat . . . 54

C.7 Slutsatser . . . 55

D Inverterad kinematik av Emil Segerb¨ack 56 D.1 Inledning . . . 56

D.1.1 Syfte . . . 56

D.1.2 Fr˚agest¨allning . . . 56

D.2 Bakgrund . . . 56

D.3 Teori . . . 56

D.3.1 Analytiska metoder f¨or inverterad kinematik . . . 57

D.3.2 Iterativa metoder f¨or inverterad kinematik . . . 57

D.4 Metod . . . 58

D.5 Resultat . . . 58

D.6 Diskussion . . . 60

D.7 Slutsatser . . . 61

E Studie av dokumentation ¨over byggprocesser i mjukvaruprojekt av Patrik Sletmo 62 E.1 Inledning . . . 62

E.1.1 Syfte . . . 62

E.1.2 Metoder och k¨allor . . . 62

E.1.3 Fr˚agest¨allning . . . 62

E.2 Bakgrund . . . 63

E.3 Teori . . . 63

E.4 Metod . . . 63

E.4.1 Insamling av tidigare projekt . . . 64

E.4.2 Identifiering av projektets egenskaper och tillg¨angliga do-kumentation . . . 64

E.4.3 F¨ors¨ok att kompilera de olika projekten efter deras speci-fikationer . . . 65

E.4.4 Unders¨okning via webbformul¨ar . . . 65

E.5 Resultat . . . 65

E.5.1 Insamling av tidigare projekt . . . 65

E.5.2 Identifiering av projektets egenskaper och tillg¨angliga do-kumentation . . . 66

E.5.3 F¨ors¨ok att kompilera de olika projekten efter deras

speci-fikationer . . . 66

E.5.4 Unders¨okning via webbformul¨ar . . . 69

E.6 Diskussion . . . 70

E.6.1 Resultat . . . 70

E.6.2 Metod . . . 71

E.7 Slutsatser . . . 72

F Virtual reality och cybersickness av Teo Tiefenbacher 73 F.1 Inledning . . . 73 F.1.1 Syfte . . . 73 F.1.2 Fr˚agest¨allning . . . 73 F.2 Teori . . . 73 F.2.1 Virtual Reality . . . 73 F.2.2 Cybersickness . . . 74 F.3 Metod . . . 74 F.4 Resultat . . . 74

F.4.1 Hur m¨ater man effekten av cybersickness . . . 75

F.4.2 Hur minskar man effekten av cybersickness . . . 76

F.5 Diskussion . . . 77

F.5.1 Metod . . . 77

F.5.2 Resultat . . . 77

F.6 Slutsatser . . . 78

G Etik av Jon Vik 79 G.1 Inledning . . . 79

G.2 Syfte . . . 79

G.3 Fr˚agest¨allning . . . 79

G.5 Teori . . . 80

G.5.1 Vad ¨ar etik och vad ¨ar skillnaden mellan moral? . . . 80

G.5.2 Normativ etik . . . 80

G.5.3 Till¨ampad etik . . . 80

G.5.4 Metaetik . . . 81 G.6 Metod . . . 81 G.7 Resultat . . . 81 G.7.1 Utilitarismen . . . 81 G.7.2 Dygdetik . . . 82 G.7.3 Kantiansk pliktetik . . . 82 G.7.4 Robotetik . . . 83 G.8 Diskussion . . . 84

G.8.1 Vad kan v˚ar robot bidra med? . . . 84

G.8.2 Vad s¨ager utilitarismen om utvecklande av n˚agot som inte direkt bidrar till att v¨arlden blir b¨attre? . . . 84

G.8.3 Vad s¨ager dygdetiken om utvecklande av n˚agot som inte direkt bidrar till att v¨arlden blir b¨attre? . . . 84

G.8.4 Vad s¨ager den kantianska pliktetiken om utvecklande av n˚agot som inte direkt bidrar till att v¨arlden blir b¨attre? . 84 G.9 Slutsatser . . . 85

H Kravhantering och kundrelationer i rollen som analysansvarig av David Wajngot 86 H.1 Inledning . . . 86 H.1.1 Syfte . . . 86 H.1.2 Fr˚agest¨allningar . . . 86 H.2 Bakgrund . . . 86 H.3 Teori . . . 87 H.3.1 Utvecklingsmetodik i mjukvaruprojekt . . . 87 H.3.2 Analysansvarig . . . 87

H.3.3 Kravhantering . . . 88 H.4 Metod . . . 89 H.5 Resultat . . . 89 H.5.1 Agil kravhantering . . . 89 H.5.2 Agil analysansvarig . . . 90 H.6 Diskussion . . . 91 H.6.1 Metod . . . 91 H.6.2 Resultat . . . 91 H.7 Slutsats . . . 92

H.7.1 Hur f¨orh˚aller sig kundrelationer till kravhantering i agila mjukvaruprojekt, och hur involveras analysansvarig i detta? 92 H.7.2 Hur skiljer sig analysansvariges roll mellan agil och icke-agil utvecklingsmetodik? . . . 92

Bilaga 1 Feedback fr˚an KVIT Conference 100 Bilaga 2 Resultat fr˚an unders¨okningen till “Studie av dokumen-tation ¨over byggprocesser i mjukvaruprojekt” 101 2.1 Fr˚agor som st¨alldes . . . 101

2.2 Svar . . . 102

Bilaga 3 Resultat fr˚an anv¨andartester fr˚an Del B 109 3.1 Fr˚agor . . . 109

Figurer

1 En Aldebaran Pepper-robot (bilden ¨ar h¨amtad fr˚an Wikimedia

Commons)[1] . . . 2

2 En skiss ¨over systemets delar . . . 17

3 Projektets systemanatomi . . . 19

4 Antal timmar som kr¨avs f¨or att l¨osa problem vid uppt¨ackt. [25] . 30 5 Oversikt av betyg i CodeFactor . . . .¨ 31

6 Resultat p˚a fr˚agan om p˚averkan . . . 33

7 Gruppens betyg p˚a CodeFactor . . . 34

8 En SSM enligt Wirths modell . . . 39

9 Resursanv¨andning under en bildruta . . . 44

10 Resultat av unders¨okning . . . 52

11 Resultat av unders¨okning . . . 52

12 Resultat av unders¨okning . . . 52

13 Resultat av unders¨okning . . . 53

14 Hur vinklarna m¨attes inuti Unity . . . 59

Tabeller

1 Olika kameror som ¨overv¨agdes av projektgruppen . . . 18

2 Insamlade tidigare projekt . . . 66

3 Egenskaper hos tidigare projekt . . . 66

Del I

Gemensam del

1

Inledning

I dagsl¨aget finns robotar i fabriker, p˚a v¨agarna och snart ¨aven i hemmen. ¨

Aven Virtual reality ¨ar en teknik p˚a uppg˚ang. P˚a senaste tiden har Oculus Rift, HTC Vive och VR-headset som anv¨ander mobilen lanserats och f˚att stor uppm¨arksamhet. I det h¨ar projektet har ett gr¨anssnitt mellan VR och robot utvecklats, med m˚alet att kunna bedriva forskning inom kognitionsvetenskap. Slutprodukten ska fungera s˚a att anv¨andaren kan koppla upp sig mot ett VR-system och d˚a kunna kontrollera en humanoid robots r¨orelser som speglas av anv¨andarens egna r¨orelser. Anv¨andaren ska ocks˚a kunna se via en kamera som ska ˚aterge robotens synf¨alt. Detta f¨or att kunna svara p˚a fr˚agan “Hur ¨ar det att vara en robot?”.

1.1

Syfte

Syftet med den h¨ar rapporten ¨ar att beskriva projektarbetets g˚ang, resultat, samt att sammanst¨alla och f˚anga upp de erfarenheter projektmedlemmarna f˚att under projektet och den mjukvaruutveckling som det best˚att av.

1.2

Fr˚

agest¨

allningar

1. Kan den f¨ardiga slutprodukten fungera tillr¨ackligt bra f¨or att kunna be-driva forskning inom kognitionsvetenskap?

2. Vilka erfarenheter kan dokumenteras fr˚an projektet som kan vara intres-santa f¨or framtida projekt?

3. Vilket st¨od kan man f˚a genom att skapa och f¨olja upp en systemanatomi? 4. Vad kan g¨oras mjukvarum¨assigt f¨or att spara energi f¨or en mer h˚allbar utveckling, och ¨ar det v¨art att implementera dessa l¨osningar p˚a detta projekt?

1.3

Avgr¨

ansningar

Det h¨ar arbetet avser endast utveckling mot VR-gr¨anssnittet HTC Vive och roboten av modell Pepper fr˚an f¨oretaget Aldebaran. Pepper kan ses i Figur 1. Projektgruppen har valt att avgr¨ansa utvecklingen till verktyget Unity, som

fr¨amst st¨odjer programspr˚aken C# och JavaScript. Utvecklingen har varit av-gr¨ansad till de SDK som tillhandah˚alls av Aldebaran i programspr˚aken C++, Python och Java.

Figur 1: En Aldebaran Pepper-robot (bilden ¨ar h¨amtad fr˚an Wikimedia Com-mons)[1]

2

Bakgrund

Projektet genomf¨ordes i kursen TDDD96, Kandidatprojekt i programvaruut-veckling. Syftet med kursen ¨ar att gruppmedlemmarna ska till¨ampa sina kun-skaper fr˚an tidigare kurser inom programmering, datalogi och datateknik f¨or att som grupp ta sig an en best¨allning fr˚an en extern kund och skapa v¨arde f¨or den. Projektgruppen bestod av 8 medlemmar som g˚att minst 5 terminer p˚a antingen Datateknik, eller p˚a Mjukvaruteknik p˚a Tekniska h¨ogskolan vid Link¨opings uni-versitet. Alla projektmedlemmarna har n˚agon form av erfarenhet av att jobba i projekt med andra studenter.

Projektgruppen fick ett urval av 23 stycken m¨ojliga projekt att ¨onska sig, vil-ket projektf¨orslaget “Hur ¨ar det att vara en robot?” fr˚an Sam Thellman och Mattias Arvola var ett. Thellman ¨ar doktorand vid Institutionen f¨or dataveten-skap (IDA) p˚a Link¨opings universitet (LiU) med inriktning p˚a interaktiva och kognitiva system. Arvola ¨ar universitetslektor vid IDA och docent i kognitions-vetenskap.

Thellman och Arvolas m˚al ¨ar att ta fram ett VR-gr¨anssnitt f¨or att g¨ora det m¨ojligt att kontrollera en humanoid robot och uppleva v¨arlden utifr˚an dennes perspektiv. Med hj¨alp av systemet vill Thellman och Arvola kunna bedriva socialpsykologisk forskning med fr˚agest¨allningen “Hur ¨ar det att vara en robot?” (eng. “What is it like to be a bot?”).

3

Teori

F¨or att b¨attre f¨orst˚a den h¨ar rapporten och vad som ligger till grund f¨or hur slutprodukten har utvecklats, beh¨over en del kunskaper om grundl¨aggande teori f¨or projektet erh˚allas. Teorin som ligger i grund f¨or den h¨ar rapporten ¨ar bl.a. virtual reality, relevanta programmeringsspr˚ak och utvecklingsverktyg. St¨orre projekt underl¨attas av en v¨al fungerande utvecklingsmetodik, och i det h¨ar projektet anv¨andes tv˚a utvecklingsmetodiker. F¨or att anpassa slutprodukten f¨or h˚allbar utveckling kunde ett antal ˚atg¨arder genomf¨oras, och f¨or det h¨ar projektet sticker ett f˚atal ut.

3.1

Virtual reality

Virtual reality ¨ar en id´e som funnits l¨ange, men som endast varit tillg¨anglig f¨or anv¨andning i hemmen de senaste ˚aren. Teknologin g˚ar ut p˚a att lura hj¨arnan till att tro det som visas i VR-headset ¨ar verklighet. M¨anniskan har djupseende, vilket representeras med hj¨alp av tv˚a sk¨armar i ett VR-headset d¨ar sk¨armarna ¨

ar uppdelade mellan ¨ogonen. Att man kan se sig omkring i VR sker tack vare en accelerometer, som h˚aller koll p˚a anv¨andarens huvudr¨orelser. [2] [3]

Id´en har funnits sen i mitten av 1900-talet, och p˚a den tiden handlade det om en st¨orre maskin, “Sensorama”. I dagsl¨aget best˚ar inte VR av en stor maskin, utan man har lyckats g¨ora det mer kompakt (VR-headset) likt m˚anga andra tekniker. Ut¨over HTC Vive, som anv¨andes i det h¨ar projektet, finns ¨aven motsvarigheter och liknelser i form av Oculus Rift och PlayStation VR. ¨Aven Google Cardboard och Samsung Gear VR kan l¨aggas till p˚a listan ¨over olika VR-headset, dock fungerar de tv˚a sistn¨amnda med hj¨alp av att man stoppar in en smartphone i respektive VR-headset. [2]

3.2

Utvecklingsverktyg

F¨or att utveckla v˚ar produkt har vi anv¨ant oss av flera olika utvecklingsverktyg. Dessa beskrivs mer ing˚aende i detta kapitel.

3.2.1 Unity

Unity ¨ar en spelmotor som utvecklas av Unity Technologies och st¨odjer m˚anga olika plattformar, bland annat Windows, Linux och macOS. Bland de funktio-ner som ¨ar inbyggda i Unity finns rendering, ljud/musik, fysikmotor och ani-mation. Ett projekt i Unity ¨ar byggt med hj¨alp av “Game Objects” som har upps¨attningar med komponenter. Dessa komponenter kan till exempel vara 3D-modeller eller skript skrivna i exempelvis C# som inneh˚aller det beteende man vill att objektet ska uppvisa. [4] [5]

3.2.2 Choregraphe

Choregraphe ¨ar ett multiplattformsprogram f¨or att styra, konfigurera eller simu-lera en av Aldebarans robotar. Programmet l˚ater anv¨andaren skapa avancerade beteenden utan att skriva en enda rad kod, samtidigt som man har m¨ojligheten att anv¨anda programmeringsspr˚aket Python f¨or samma ¨andam˚al. Choregraphe ¨

ar ocks˚a ett anv¨andbart verktyg n¨ar man ist¨allet anv¨ander sig av NAOqi SDK, d˚a Choregraphe simulerar roboten ¨over samma gr¨anssnitt. I programmet kan man d˚a se exakt hur roboten reagerar i en 3D-vy och beh¨over allts˚a inte tillg˚ang till en fysisk robot f¨or att utveckla mjukvara. [6]

3.2.3 NAOqi SDK

Aldebarans robot Pepper kan ut¨over Choregraphe kontrolleras med hj¨alp av NAOqi SDK som f¨oretaget tillhandah˚aller. SDK:t finns tillg¨angligt f¨or program-meringsspr˚aken Python, Java och C++, och laddas ner fr˚an SoftBank Robotics hemsida f¨or utvecklare. Genom att koppla ihop ett program med SDK:t kan man med programkod kontrollera robotarna ¨over ett tr˚adl¨ost n¨atverk och p˚a s˚a s¨att f˚a dem att g¨ora mer avancerade r¨orelser ¨an vad Choregraphe till˚ater samt f˚a ut information fr˚an robotens omgivning. [7] [8]

Med SDK:t kan man kontrollera i princip alla robotarnas r¨orelser och bete-enden. Det g˚ar att hantera alla inst¨allningar som gr¨anssnittet i Choregraphe tillhandah˚aller samt st¨anga av eller aktivera robotens alla specialfunktioner f¨or detektering av personer, objekt och m¨onster [9]. Det ¨ar fr˚an SDK:t ¨aven m¨ojligt att st¨anga av de s¨akerhetsfunktioner som hindrar robotarna fr˚an att skada sig sj¨alva och sin omgivning. [10] [11]

3.2.4 Microsoft Visual Studio

Microsoft Visual Studio ¨ar en utvecklingsmilj¨o som utvecklats av Microsoft och anv¨ands f¨or att utveckla mjukvara. Visual Studio inkluderar en kodredigera-re med st¨od f¨or bland annat kodkomplettering, syntaxf¨argning och omstruk-turering av kod. Utvecklingsmilj¨on tillhandah˚aller bakgrundskompilering, ¨aven kallat inkrementell kompilering som inneb¨ar att Visual Studio kompilerar i bak-grunden som namnet antyder. Detta g¨or att utvecklaren kan f˚a feedback under tiden som utvecklaren kodar. Feedbacken kan vara syntax- och kompileringsfel och markeras d˚a understruket med ett v˚agigt r¨ott streck. ¨Aven varningar kan utvecklaren f˚a feedback om som d˚a markeras med gr¨ont v˚agigt streck [12]. Visual Studio st¨odjer en m¨angd olika programmeringsspr˚ak som till exempel C++, C, C++/CLI och det spr˚aket som anv¨ands mest i det h¨ar projektet: C#.

3.2.5 HTC Vive

HTC Vive ¨ar en produkt framtagen i ett samarbete mellan HTC och Valve. F¨or att s˚a sm˚aningom utnyttja vad Steam har att erbjuda kring virtuell verklighet, m˚aste HTC Vive installeras i en lokal. Det kan man g¨ora genom att f¨olja en installationsguide p˚a hemsidan f¨or HTC Vive. [13]

Installationsprocessen kr¨aver att man laddar ner och k¨or mjukvara fr˚an Steam som hj¨alper till med montering och konfigurering av utrustningen. Denna mjuk-vara agerar sedan koppling mellan HTC Vive och systemet det anv¨ands till. Under monteringen beh¨over man ta h¨ansyn till flera saker. D¨aribland m˚aste tillr¨ackligt med tomt utrymme finnas, p˚a minst 2 x 1,5 meter. Basstationerna f˚ar h¨ogst vara 5 meter ifr˚an varandra. Ut¨over det ska en Link Box och Headset monteras och konfigureras enligt guide. [14]

3.2.6 Steam

Steam ¨ar en plattform f¨or underh˚allning, utgiven av Valve Corporation. Ut¨over spel och underh˚allning finns ¨aven verktyg som SteamVR. SteamVR ¨ar en platt-form f¨or exekvering och utveckling av VR-applikationer.

Innan man anv¨ander VR p˚a n˚agot s¨att, b¨or man se till att man har en dator som ¨ar tillr¨ackligt kraftfull f¨or att k¨ora VR. Det kan man enkelt kolla med hj¨alp av en applikation vid namn “SteamVR performance test”, som finns tillg¨anglig gratis att ladda ner p˚a Steam. [14]

F¨or att installera SteamVR beh¨ovs Steam-klienten, och f¨or att komma ˚at pro-dukterna p˚a marknaden beh¨ovs ett Steam-konto. N¨ar man har installerat Steam och skapat ett konto, kan man ladda ner och installera SteamVR och d¨arefter ladda ner och k¨ora applikationerna Room Setup och Tutorial. N¨ar detta ¨ar gjort ¨

ar VR-utrustningen konfigurerad och redo att anv¨andas. [14]

3.3

Programmeringsspr˚

ak

F¨or utvecklingen av projektet har vissa programmeringspr˚ak beh¨ovts anv¨andas. I denna del finns ¨oversiktliga beskrivningar av de programmeringsspr˚ak som har ¨

overv¨agts till projektet.

3.3.1 C#

C# ¨ar ett objektorienterat programmeringsspr˚ak. Bland annat m˚ asvinge-syn-taxen g¨or att n˚agon som kan C, C++ eller Java enkelt och snabbt kan l¨ara sig syntaxen f¨or C#. Programmeringsspr˚aket f¨orenklar saker som var komplicerade med C++, medan det st¨odjer saker som: “Nullable value types, enumerations, delegates, lambda expressions and direct memory access” [15].

P˚a grund av att C# ¨ar ett objektorienterat spr˚ak s˚a st¨odjer det koncept som inkapsling, arv och polymorfism. En klass inkapslar alla variabler och metoder. Den kan ocks˚a ¨arva fr˚an en f¨or¨alderklass samt implementera gr¨anssnitt [15].

3.3.2 F#

F# ¨ar ett starkt typat, multi-paradigm programmeringsspr˚ak. Spr˚aket ¨ar funk-tionellt, imperativt och objektorienterat. N˚agra intressanta egenskaper ¨ar f¨or det f¨orsta att spr˚aket st¨odjer m¨onstermatchning, det vill s¨aga n¨ar man ska matcha ett uttryck mot en m¨angd m¨onster. F¨or det andra s˚a anv¨ander den funktioner som v¨arden vilket g¨or att man enkelt kan manipulera funktioner. F¨or det tredje tillhandah˚aller F# funktionssammans¨attning [16].

3.3.3 C++

C++ ¨ar ett objektorienterat programmeringsspr˚ak och ¨ar en utbyggnad av C. C++ ¨ar ett spr˚ak p˚a mellanniv˚a, vilket betyder att programmeringsspr˚aket erbjuder egenskaper som b˚ade ¨ar l˚ag- och h¨ogniv˚aegenskaper. En stor positiv egenskap med spr˚aket ¨ar att C++ har en samling f¨ordefinierade klasser som ¨ar datatyper som kan instansieras om och om igen. En annan positiv egenskap ¨ar att C++ f¨orenklar skapande av klasser som skapas av anv¨andaren. C++ inne-fattar flera operationer som j¨amf¨orelser, aritmetik, bitmanipulation och logiska operationer. Andra n¨amnv¨arda koncept ¨ar att spr˚aket st¨odjer polymorfism, vir-tuella funktioner, templates, namespaces och pekare. [17]

3.4

Utvecklingsmetodik

I st¨orre mjukvaruprojekt kan man ta hj¨alp av en utvecklingsmetodik f¨or att effektivt organisera och f¨ora arbetet fram˚at. I det h¨ar projektet var tv˚a olika ut-vecklingsmetodiker aktuella, Scrum och Kanban. F¨or att utnyttja dessa beh¨ovs f¨orst˚aelse f¨or vad respektive metodik inneb¨ar.

3.4.1 Scrum

Scrum ¨ar en typ av agil utvecklingsmetodik. Enligt definitionen f¨or Scrum ¨ar den varken en process eller en teknik f¨or att bygga produkter, utan snarare ett ramverk vari processer och tekniker kan anv¨andas p˚a olika s¨att. Genom att anv¨anda Scrum blir det klart hur utvecklingen och produktledningen g˚ar, och det ¨ar m¨ojligt att f¨orb¨attra arbetet under projektets g˚ang. Det som mer ¨an s˚a bygger upp Scrum ¨ar Scrum-teamet, dess olika roller, event, artefakter och regler. Ut¨over detta kan Scrum allts˚a se ut p˚a olika s¨att, och det kan skilja mycket fr˚an projekt till projekt hur Scrum appliceras. [18]

3.4.2 Kanban

Kanban ¨ar en agil utvecklingsmetod som inspirerats fr˚an Toyotas produktions-system [19]. Kanban fokuserar p˚a att visualisera vad kunden s¨oker f¨or funktio-nalitet och vad som arbetas p˚a f¨or n¨arvarande i projektet. Visualiseringen sker ofta genom att placera s˚a kallade utvecklingsobjekt p˚a en tavla. Denna tavla har f˚att sitt namn fr˚an utvecklingsmetoden och kallas ofta f¨or en Kanban-tavla (eng. Kanban board). Ut¨over att illustrera processen f¨or utvecklingsmetoden uppmuntrar den ¨aven varje utvecklare till att sj¨alv v¨alja en uppgift att g¨ora, ist¨allet f¨or att en projektledare delegerar dennes arbetsuppgifter. [20]

3.5

Aktiviteter f¨

or att minska energi˚

atg˚

angen

I mjukvaruprojekt finns olika ˚atg¨arder som kan vidtas f¨or att genomf¨ora en h˚allbar utveckling. Dock ¨ar inte alla ˚atg¨arder t¨ankbara f¨or utvecklingen av slut-produkten i det h¨ar arbetet. I det h¨ar projektet ¨overv¨agdes m¨ojligheterna att minska klockfrekvens, nyttja l˚agniv˚aprogrammering och polla mindre frekvent.

3.5.1 Minska klockfrekvens

I de allra flesta processorerna nu f¨or tiden g˚ar det att minska klockfrekvensen och d¨armed ocks˚a prestandan. Resultatet av att minska klockfrekvensen ¨ar att det g˚ar f¨arre klockcykler per tidsenhet. D˚a klockfrekvensen minskas s˚a mins-kas ocks˚a str¨om˚atg˚angen, dels direkt av att det kr¨avs mindre str¨om, men det produceras ¨aven mindre v¨arme. Som resultat s˚a beh¨over fl¨akten som sitter p˚a processorn inte jobba lika intensivt vilket ¨aven det sparar str¨om. Fler f¨ordelar ¨

ar att h˚ardvaran h˚aller l¨angre, ¨okad stabilitet p˚a h˚ardvaran, l¨agre ljudniv˚a p˚a fl¨aktarna och ¨okad batteritid [21].

3.5.2 L˚agniv˚aprogrammering

Ett h¨ogniv˚aspr˚ak abstraherar m˚anga av datorns detaljer. Det kan vara detaljer som att spara v¨arden i minnet eller register. Som f¨oljd av detta s˚a blir koden mer portabel och enklare att anv¨anda sig av. Sj¨alva termen h¨og- och l˚agniv˚a ¨ar idag relativ. F¨orr i tiden klassades till exempel C som ett h¨ogniv˚aspr˚ak medan det idag klassas som l˚agniv˚a [21].

Det finns en del nackdelar med l˚agniv˚aspr˚ak. Programmen ¨ar oftast mycket sv˚arare att implementera eftersom programmeraren m˚aste h˚alla kolla p˚a s˚a m˚anga saker som till exempel minneshantering. Det kr¨avs dessutom en erfaren programmerare f¨or att effektivt skriva l˚agniv˚akod. N˚agot som ett h¨ogniv˚aspr˚ak kan ˚astadkomma i n˚agra rader kod brukar ofta ta v¨aldigt m˚anga fler rader kod att skriva i ett l˚agniv˚aspr˚ak [21].

utan ist¨allet kan sm˚a delar av programmet som anv¨ands ofta implementeras i ett l˚agniv˚aspr˚ak. P˚a s˚a s¨att kan kodens effektivitet ¨okas markant, med minimal anstr¨angning [21].

3.5.3 Polla mindre frekvent

Polling ¨ar att regelbundet se om ett villkor har m¨otts. Det kan till exempel vara att se om anv¨andaren har interagerat med datorns input-enheter. Ist¨allet f¨or polling kan h¨andelsebaserade system anv¨andas f¨or b¨attre energieffektivitet. Ju mindre polling desto mindre energi kr¨avs [21].

3.6

Systemanatomi

En systemanatomi ¨ar en graf ¨over ett systems funktionella beroenden sett fr˚an ett anv¨andarperspektiv. Tanken bakom en systemanatomi ¨ar att f˚a en b¨attre f¨orst˚aelse f¨or ett mer komplicerat system. Den beh¨over s˚aledes inte lista specifika funktioner (kod), snarare presentera de delar som kr¨avs f¨or att systemet ska fungera. Systemanatomin ger sedan m¨ojligheten att underl¨atta beslutstagande och iterationsplanering.

4

Metod

F¨or att anv¨anda den framtagna teorin till att effektivisera utvecklingsarbetet, kan man underl¨atta arbetet genom att anv¨anda passande metoder. De anv¨anda metoderna i det h¨ar projektet utg˚ar ifr˚an relevant teori.

4.1

F¨

orstudie

Innan arbetet med produkten kunde b¨orja gjordes en f¨orstudie. De viktigaste dokumenten som togs fram var projektplan, kravspecifikation och kvalitetsplan. Det togs ¨aven fram en systemanatomi f¨or att f˚a en b¨attre uppfattning om hur systemet skulle byggas.

I projektplanen togs det fram ¨oversiktliga iterationsplaner och gruppens olika roller definierades. Det togs ¨aven fram en plan f¨or utbildning, rapportering, m¨oten, resurser, aktiviteter och kvalitet. I kravspecifikationen togs det fram ett antal krav som projektet var t¨ankt att uppn˚a. Fr¨amst f¨or att s¨akerhetst¨alla att projektgruppens bild av vad projektet skulle inneh˚alla st¨amde ¨overens med best¨allarens. Kvalitetsplanen togs fram f¨or att s¨atta upp en plan f¨or hur kvali-teten i projektet skulle uppr¨atth˚allas.

4.2

Projektorganisation

Projektets organisation beskrivs n¨armare i detta kapitel med information om de olika ansvarsrollerna inom projektgruppen och de olika metoder som f¨ort arbetet fram˚at.

4.2.1 M¨oten

Projektgruppen har haft regelbundna m¨oten med avst¨amningar om arbetets framfart minst en g˚ang i veckan. Under m¨otena diskuterades vad som utf¨orts sedan det senaste m¨otet och vad som skulle g¨oras tills n¨asta m¨ote.

Genom hela projektet har m¨ote med handledare varit en m¨ojlighet. Dessa m¨oten har utnyttjats av gruppen f¨or att ta l¨ardom av handledarens tidigare erfaren-heter.

4.2.2 Gruppkontrakt

Tidigt i projektet tog gruppen fram ett gruppkontrakt i syfte att tydligg¨ora vad som f¨orv¨antades av varje gruppmedlem. Enligt gruppkontraktet var det bland annat att f¨oredra att arbeta p˚a campus tillsammans med resten av gruppen. Motivationen till detta var att det ¨ar l¨attare att p˚a s˚a vis f¨olja med i vad ¨ovriga gruppmedlemmar arbetar med.

4.2.3 Koordinering

Projektgruppen har anv¨ant olika verktyg f¨or att koordinera gruppmedlemmar-na. Slack har anv¨ants f¨or att m¨ojligg¨ora snabb kommunikation inom gruppen och Google Calendar har anv¨ants f¨or att koordinera schemat. F¨or att kunna versionshantera koden har Git i anslutning med GitHub anv¨ants. Alla gemen-samma dokument har skrivits i Google Drive och shareLaTeX f¨or att m¨ojligg¨ora att alla gruppmedlemmar kunnat arbeta tillsammans. Asana anv¨andes i b¨orjan av projektet f¨or att ge gruppen en ¨oversikt ¨over hur utvecklingen framskrider och vad alla andra arbetar med. Efter ungef¨ar halva projektets g˚ang ersattes Asana med Trello f¨or att anv¨andas i samma syfte.

4.2.4 Roller

Under projektet har gruppmedlemmarna varit tilldelade en ansvarsroll. Dessa g˚ar att l¨asa om i detta avsnitt.

Teamledare

Teamledaren ansvarar fr¨amst f¨or att leda projektets arbete fram˚at. F¨or att lyckas med detta ansvarar teamledaren f¨or att best¨amma och f¨olja upp m˚al samt f¨olja upp de processer som specificerats i kvalitetsplanen. Vid behov ska teamledaren ¨aven se till att n¨odv¨andiga ¨andringar g¨ors i b˚ade m˚al och processer. I sitt arbete ska teamledaren agera coach mot resterande gruppmedlemmar och motivera projektets medlemmar. Vid konflikter eller skilda ˚asikter ¨ar det team-ledarens uppgift att styra upp problemet genom att antingen agera medium f¨or konflikter eller besluta om en fr˚aga. Teamledaren f¨orv¨antas lyfta st¨orre konflik-ter till projektets handledare vid behov.

Analysansvarig

Analysansvarig fungerar som f¨ormedlare och f¨orhandlare mellan projektgrup-pen och best¨allaren. Som prim¨ar kommunikationskanal tar analysansvarig reda p˚a best¨allarens behov och krav p˚a produkten och f¨ormedlar detta till projekt-gruppen. Det ¨ar ocks˚a analysansvariges uppgift att framf¨ora gruppens ˚asikter om vad som ¨ar rimligt att utf¨ora till best¨allaren och att f¨orhandla om kraven s˚a att de blir genomf¨orbara av projektgruppen samt att best¨allaren blir n¨ojd. Analysansvarig agerar ¨aven product owner i detta projekt.

Arkitekt

Arkitekten ansvarar f¨or den ¨overgripande kodstrukturen som bygger upp syste-met. Det ¨ar arkitektens jobb att identifiera de komponenter och gr¨anssnitt som ska ing˚a i produkten. Arkitekten g¨or ocks˚a ¨overgripande teknikval och har sista ordet i tekniska fr˚agor. Arkitekten m˚aste kunna kommunicera b¨arande id´eer och dokumenterar arkitekturen.

Utvecklingsledare

Utvecklingsledaren ansvarar f¨or detaljerad design av koden. Utvecklingsledaren leder och f¨ordelar (vid behov) utvecklingsarbetet samt fattar beslut om utveck-lingsmilj¨o och organiserar utvecklarnas tester. N¨astan alla hj¨alper till och blir

d¨armed ledda av utvecklingsledaren oavsett sin andra formella roll. Utvecklings-ledaren agerade ¨aven Scrum Master under projektets andra iteration.

Kvalitetssamordnare

Kvalitet ¨ar n˚agot som alla kommer att arbeta med, men att vara kvalitets-samordnare inneb¨ar bland annat att man har initiativ- och uppf¨oljningsansvar. Kvalitetssamordnaren ser till att utifr˚an gruppens erfarenheter g¨ora arbetet mer effektivt, att gruppen f˚ar r¨att utbildning och anv¨ander bra inspirationsk¨allor. Kvalitetssamordnaren planerar och budgeterar ¨aven ihop med gruppen om hur mycket kvalitet f˚ar kosta, till exempel om bra funktionalitet ska prioriteras ¨over antalet funktioner eller inte. Kvalitetssamordnaren skriver ¨aven en kvalitetsplan. Dokumentansvarig

Dokumentansvarig har ansvar f¨or alla dokument som skrivs. Dokumentansvarig ser till att alla dokument blir klara till deadline. Om gruppen vill ha en logotyp ansvarar ¨aven dokumentansvarig f¨or det. Dokumentansvarig jobbar ¨aven mycket med kvalitetssamordnaren och konfigurationsansvarig.

Konfigurationsansvarig

Konfigurationsansvarig best¨ammer vilka arbetsprodukter som ska versionshan-teras och vilka som ing˚ar i en utg˚ava. Konfigurationsansvarig v¨aljer och un-derh˚aller ocks˚a verktyg f¨or versions- och konfigurationshantering samt ser till att verktygen anv¨ands p˚a r¨att s¨att. Under projektet arbetar konfigurationsan-svarig mycket med utvecklingsledaren och dokumentankonfigurationsan-svarig.

Testledare

Testledaren ¨ar ansvarig f¨or att besluta om systemets status, det vill s¨aga vilka krav som systemet i sitt nuvarande tillst˚and n˚ar upp till. Testledaren sk¨oter den dynamiska verifieringen och valideringen av systemet genom exekvering. Testledaren ska tillsammans med kvalitetssamordnaren testa de kvalitetskrav som kunden specificerat. Testledaren skriver testplanen och testrapporterna. VR-specialist

Specialisten f¨ordjupar sig inom ett f¨orutbest¨amt omr˚ade inom vilket det kr¨avs mycket kunskap f¨or projektet. Detta omr˚ade har fastslagits till VR. VR-specia-listen ¨ar ¨aven ansvarig f¨or att VR-uppst¨allningen fungerar som den ska.

4.3

Utvecklingsmetod

Scrum och Kanban som tidigare tagits upp, ¨ar de utvecklingsmetodiker som anv¨ants i det h¨ar projektet. Ut¨over dessa har olika metoder f¨or kodgranskning och testning anv¨ants i syfte att s¨akerst¨alla god kvalitet p˚a slutprodukten.

4.3.1 Scrum

Projektgruppen p˚ab¨orjade arbetet i projektet med hj¨alp av Scrum-metoden, som anv¨andes under projektets andra iteration. Utvecklingsledaren agerade Sc-rum master och analysansvarig agerade product owner. Sprintarna planerades

f¨or att matcha projektets iterationer vilket gav en iterationsl¨angd p˚a drygt 2 veckor f¨or den iteration som scrum-metoden anv¨andes.

Scrum applicerades p˚a projektet relativt n¨ara sitt grundutf¨orande med den enda skillnaden att de s˚a kallade “standup-meetings” inte anv¨andes. Detta f¨or att vi inom projektgruppen inte hade m¨ojlighet att tr¨affas varje dag under f¨orsta delen av v˚arterminen (VT1).

Efter att projektgruppens applicering av Scrum utv¨arderats kunde det konsta-teras att utvecklingsmetodiken var l˚ang ifr˚an optimal och beslutet gjordes att f¨orfina metoden, varvid gruppens iterativa arbetss¨att gick ifr˚an principerna i Sc-rum. F¨or de resterande iterationerna anv¨andes den nya metoden, som beskrivs i avsnitt 4.3.2.

4.3.2 Kanban

Under projektets senare iterationer utvecklades projektet efter en mer f¨orfinad iterationsplan, vilket realiserades med hj¨alp av en s˚a kallad Kanban-tavla (eng. Kanban board). Genom att dela upp utvecklingsprocessen i olika steg blev det l¨attare att se gruppens framsteg och f¨olja processen. M¨angden tvetydigheter i processen minimerades genom att stapla upp vad f¨or krav som finns f¨or att f¨orflytta ett objekt fr˚an ett steg till ett annat och vad som g¨ors f¨or att uppfylla dessa krav.

Den tavla som anv¨ands f¨or att placera de olika objekten p˚a i Kanban-metodiken realiserades online med hj¨alp av verktyget Trello. P˚a s˚a s¨att kunde vi dokumen-tera delprocesserna ytterligare och samtidigt ha koll p˚a all information var vi ¨

an befann oss. Eftersom tillg˚angen till ett kontor eller en gemensam arbetsyta varit sporadisk valdes Trello, vilket m¨ojliggjorde kollaborativ utveckling trots detta.

4.3.3 Kodgranskning

F¨or att kvalitetss¨akra koden gjordes kodgranskningar. Metoden som anv¨andes under utvecklingen tog hj¨alp av ett verktyg f¨or kodgranskning, vid namn “Code-Factor”. Ut¨over den automatiska kontrollen utf¨ordes ¨aven manuella granskning-ar av tv˚a projektmedlemmar, som kunde kontrollera resultatet fr˚an CodeFactor och skumma igenom kod p˚a egen hand. Om kod passerade b˚ade den automa-tiska kontrollen som CodeFactor g¨or och den manuella kontrollen, “godk¨andes” koden.

4.3.4 Testning

Detta avsnitt beskriver hur testningen g˚att till under projektets g˚ang. Funktionalitet som skulle testas

F¨or att jobba s˚a agilt som m¨ojligt var tanken att de identifierade anv¨ andar-ber¨attelserna skulle ligga till grund f¨or testningen. Det var allts˚a dessa som skulle best¨amma vilken funktionalitet som skulle testas. Allt eftersom en anv¨ andar-ber¨attelse p˚ab¨orjades s˚a br¨ots funktionaliteten ner i testbara best˚andsdelar. Funktionalitet som inte skulle testas

F¨or att avgr¨ansa projektet och spara tid valdes flera omr˚aden bort fr˚an att testas. Till exempel utf¨ordes inte s¨akerhetstest med motiveringen att systemet inte handskas med n˚agon k¨anslig data.

Eftersom systemet ¨ar mer snarlik en prototyp eller ett konceptbevis utf¨ordes inte n˚agon form av stress-, volym-, ˚aterst¨allnings-, milj¨o-, konfigurations-, kompa-tibilitets- eller liknande form av kvalitetstest. Detta eftersom systemet inte kom-mer g˚a i produktion eller distribution till best¨allarens kunder, utan anv¨andas som ett verktyg f¨or att testa en forskningstes.

Tillv¨agag˚angss¨att

Eftersom projektarbetet utg˚att fr˚an en agil process s˚a har testprocessen blivit tvungen att anpassa sig efter detta. Detta gjorde att tester inte kunde plane-ras l˚angt i f¨orv¨ag, utan ist¨allet blev ett kontinuerligt arbete utefter sprinternas prioriterade anv¨andarber¨attelse eller anv¨andningsfall. F¨or att kunna avsluta ak-tiviteter med f¨ortroende att det som ¨ar implementerat fungerar s˚a testades varje aktivitet innan n¨asta p˚ab¨orjades. I slutet av varje sprint har det som implemen-terats acceptanstestats mot tillh¨orande anv¨andarber¨attelse eller anv¨andningsfall f¨or att se om systemet fortfarande uppfyllde den efterfr˚agade f¨orm˚agan. Tester-na p˚ab¨orjades vid iterationens feature freeze.

Planen var att alla inom gruppen som skrivit kod skulle vara ansvariga f¨or enhetstestning av koden de skrivit. Dock visade sig detta vara en sv˚arighet eftersom en extremt liten del av koden gick att enhetstesta.

N¨ar en modul implementerats s˚a utf¨ordes integrationstester. Detta f¨or att veri-fiera att moduler fungerar tillsammans som de ska.

Kriterier f¨or stopp av testning och krav f¨or att ˚ateruppta testning N˚agra direkt kriterier f¨or stopp och ˚aterupptagnning av testning fanns inte d˚a testningen skedde parallellt med projektets g˚ang. Dock s˚a p˚ab¨orjades acceptans-testerna vid iterationens feature freeze och upph¨orde i b¨orjan av n¨asta iteration. Testleveransprodukter

F¨or att kunna verifiera testresultatet och garantera kvalitet av testerna s˚a pro-ducerades vissa leveransprodukter. Dokumenten inneh˚aller en kort beskrivning av testfallet, testets godk¨annande och underk¨annande kriterier och testets sam-manfattade utfall.

4.4

Utvecklingsverktyg

• Microsoft Visual Studio • Unity

• Choregraphe • NAOqi SDK • Git & Git-LFS • Trello

• CodeFactor

Utvecklingsmilj¨o

F¨or att s¨atta upp en komplett utvecklingsmilj¨o beh¨ovs en dator, ett VR-headset och en humanoid robot. Koden till projektet distribueras via ett GitHub-repo. Efter att filerna i GitHub-repot har laddats ner beh¨over DLL-filer kompileras. Det innefattar k¨allfiler till OpenCV, ett externt kameraplugin samt en “wrapper” till NAOqi SDK.

4.5

Insamling av reflektioner fr˚

an KVIT Conference

P˚a KVIT Conference delade vi ut sm˚a kort, cirka 8 cm breda och cirka 4 cm h¨oga, till de som testat v˚art system. P˚a korten instruerades respondenten att skriva ned korta reflektioner om systemet.

4.6

Metoder f¨

or att f˚

anga erfarenheter

I detta avsnitt listas n˚agra av de metoder som anv¨ants under projektets g˚ang f¨or att f˚anga projektmedlemmarnas olika erfarenheter och skapa m¨ojligheter att f¨ora dessa vidare till resten av gruppen.

4.6.1 Granskning

Under utvecklingen av systemet granskades inte dokument och kod av f¨ orfatta-ren sj¨alv utan av andra projektmedlemmar. Detta skedde av flera anledningar, dels f¨or att alla projektmedlemmar skulle f˚a b¨attre ¨oversikt ¨over vad som gjorts, men ¨aven f¨or att f¨orfattaren skulle f˚a feedback fr˚an andra i gruppen med andra erfarenheter. P˚a s˚a vis kunde f¨orfattaren f˚a nya erfarenheter fr˚an arbetet.

4.6.2 Iterationsutv¨arderingar

Efter varje iteration h¨olls en iterationsutv¨ardering, ett m¨ote med anledning att utv¨ardera arbetet fr˚an den senaste iterationen. Fokus l˚ag p˚a att lyfta fram det som fungerat bra och vad som kunde ha f¨orb¨attrats. Iterationsutv¨arderingarna protokollf¨ordes f¨or att kunna f¨olja upp diskussionerna under senare utv¨arderingar.

4.6.3 Veckom¨oten

Vid varje m¨otestillf¨alle fick de olika projektmedlemmarna presentera vad de gjort sedan det senaste m¨otet. D¨ar fanns det m¨ojlighet att presentera och g˚a igenom de problem samt erfarenheter som projektmedlemmen i fr˚aga erfarit.

5

Resultat

Ut¨over en fungerande produkt fick projektet fler resultat i form av en systema-natomi och diverse anm¨arkningsv¨arda gemensamma erfarenheter. Ytterligare resultat fick projektet fr˚an KVIT Conference.

5.1

Systembeskrivning

Syftet med projektet var att utveckla en produkt d¨ar man med hj¨alp av ett VR-system kan styra en robot och uppleva v¨arlden utifr˚an dess perspektiv. Det system som har utvecklats beskrivs av Figur 2.

Figur 2: En skiss ¨over systemets delar

Systemet best˚ar i huvudsak av tv˚a delar. Dels kontrollstationen d¨ar en ut-omst˚aende person (exempelvis testledare eller bevakare) kan ¨overvaka anv¨ anda-ren och dels kopplingen mellan anv¨andaren och roboten. Personen som anv¨ander kontrollstationen har m¨ojligheten att ¨andra inst¨allningar eller att se det anv¨ an-daren ser genom VR-headsetet.

N¨ar anv¨andaren s¨atter p˚a sig VR-headsetet f˚ar denne se en tom v¨arld med ett anv¨andargr¨anssnitt som kalibrerar systemet efter anv¨andarens l¨angd.

N¨ar anv¨andaren aktiverar robotkopplingen skickas signaler med information om huvud- och armr¨orelser till styrdatorn. Data om huvudr¨orelser samlas in fr˚an HTC Vives headset medan data om armr¨orelser samlas in fr˚an HTC Vives handkontroller. Denna data ¨overs¨atts och skickas vidare till roboten som speglar dessa r¨orelser. Funktionen f¨or armr¨orelser fungerar emellertid inte fullst¨andigt och alla armr¨orelser ˚aterspeglas inte korrekt av roboten.

P˚a robotens huvud har en kamera monterats. Den kamera som anv¨ands ¨ar en webbkamera av m¨arket och modell “Logitech C922 Pro Stream”, som blivit in-kopplad till kontrollstationen med en USB-kabel. I valet mellan olika kameror fanns det ett par olika alternativ, som presenteras i Tabell 1. Den kamera som monterats p˚a roboten valdes f¨or dess goda kompromiss av uppl¨osning, uppda-teringsfrekvens (FPS), synf¨alt, och kostnad.

Tabell 1: Olika kameror som ¨overv¨agdes av projektgruppen

Tillverkare Modell Uppl¨osning FPS Synf¨alt Kostnad Aldebaran Peppers inbyggda kamera 1920x1080 7 57° 0 SEK Logitech C922 Pro Stream 1920x1080 30 78° 0 SEK CONNEX Pro Sight Camera 1280x720 30 130° 4 500 SEK

I headsetet f¨or HTC Vive kan anv¨andaren i realtid se kamerastr¨ommen. Med hj¨alp av handkontrollerna till HTC Vive s˚a kan anv¨andaren f¨orflytta och rotera roboten. Data skickas fr˚an handkontrollerna till styrdatorn, d¨ar den ¨overs¨atts och bearbetas f¨or att skickas vidare till roboten. F¨orflyttning och rotation kan ske samtidigt, och roboten kan f¨orflyttas fram˚at, bak˚at och i sidled. Alla dessa funktioner i samspel med varandra g¨or att anv¨andaren till viss m˚an upplever det som att den befinner sig i robotens kropp.

Det var ¨aven en del funktioner som inte p˚ab¨orjades eller utvecklades fullt ut. Ej f¨ardigutvecklade men p˚ab¨orjade krav innefattar:

• Robotf¨orflyttning av att anv¨andaren f¨orflyttar sig i rummet (eng. room-scale movement)

• Ett anv¨andargr¨anssnitt f¨or kontrollstationen d¨ar bevakaren kan styra ro-boten

• F¨orb¨attrade armr¨orelser.

Ej p˚ab¨orjade men p˚at¨ankta krav innefattar:

• F¨ormedling av robotens tr¨oghet och begr¨ansningar till anv¨andaren • M¨ojligheten f¨or anv¨andaren att h¨ora ljudupptagning fr˚an robotens

posi-tion

• M¨ojligheten f¨or anv¨andaren att prata genom roboten.

5.2

Systemanatomi

I Figur 3 presenteras den systemanatomi som togs fram. De tre ¨oversta bubb-lorna representerar det som kr¨avs f¨or att kunna anv¨anda systemet, sett till de grundkrav som finns. Forts¨atter man sedan ned˚at i grafen beskrivs de underlig-gande kopplingarna och de beroenden som finns i systemet.

5.3

Gemensamma erfarenheter

F¨or samtliga i projektgruppen har det h¨ar arbetet varit en stor erfarenhet d¨ar alla tar med sig nya kunskaper. Gruppen har kommit ¨overens om vilka de vikti-gaste gemensamma erfarenheterna ¨ar, tillsammans med de mest betydelsefulla kunskaperna som projektgruppen tar med sig i framtiden.

5.3.1 Agil utveckling

Gruppen har f˚att m¨ojligheten att testa p˚a tv˚a olika typer av agil utveckling. Under ett f¨orsta stadie av projektet anv¨andes Scrum f¨or att sedan ers¨attas av Kanban. Projektgruppen ans˚ag att Kanban fungerade b¨attre och att bytet av utvecklingsmetodik var positivt f¨or b˚ade gruppen och projektet.

5.3.2 Distribution av bin¨ara filer

P˚a grund av att Unity saknar vissa funktioner har det beh¨ovts skapas plugin f¨or systemet. Dessa plugin har varit skrivna i C eller C++ och kompilerats till DLL-filer som sedan kunnat anv¨andas i Unity. Vi har anv¨ant Git f¨or versions-hantering, som har sv˚art att hantera f¨or¨andringar i bin¨ara filer och har d¨arf¨or inte lagt till bin¨ara filer som DLL-filer i GitHub-repot. P˚a grund av att syste-met varit beroende av dessa plugin och vi inte kunnat dela dem via Git har de beh¨ovts kompileras om f¨or varje ny arbetsmilj¨o (dator eller inloggning p˚a en dator). Vissa av dessa plugin har varit enklare medan andra varit v¨aldigt tids-och kunskapskr¨avande att bygga. Mycket gr˚at, tid och tandagnisslan har g˚att ˚at endast till att st¨alla upp utvecklingsmilj¨on f¨or att kompilera dessa plugin. Det tog l˚ang tid innan vi kunde skriva en reproducerbar guide f¨or alla olika beroenden som fanns i projektet och ibland uppkom of¨orklarliga fel f¨or n˚agra av projektgruppens medlemmar. I slutet av projektet lades det tid p˚a att ska-pa en mer automatiserad process f¨or att hantera alla beroenden men ¨aven d¨ar uppt¨acktes undantag som gjorde att inte alla projektmedlemmar kunde anv¨anda byggsystemet.

En erfarenhet som alla gruppmedlemmar tar med sig fr˚an detta projekt ¨ar att n¨ar man har ett arbete som ¨ar beroende av bin¨ara filer f¨or att fungera (och som inte n¨odv¨andigtvis f¨or¨andras s¨arskilt ofta) s˚a finner man ett s¨att att dela dem med arbetsgruppen. F¨orslagna exempel ¨ar molnlagringstj¨anster som Google Drive eller Dropbox eller p˚a lagringsenheter ˚atkomstbara f¨or alla.

5.3.3 Kravhantering

N˚agot ovant f¨or de flesta av projektmedlemmarna var formulering av krav i ett agilt projekt. De ¨ar formulerade som anv¨andningsfall och anv¨andarber¨attelser. Projektet har delats upp i mindre uppgifter som specificerar en enstaka funktion per anv¨andningsfall. De ¨ar sedan definierade som ett m˚al som ska uppn˚as snarare

¨

an specifika tekniska funktioner. Det ger gruppen st¨orre frihet i hur en uppgift kan l¨osas. Gruppmedlemmarna tar s˚aledes med sig erfarenheten att anv¨anda denna typ av kravs¨attning inom ett projekt.

5.3.4 Jobba i ett st¨orre projekt

Ingen av gruppmedlemmarna har tidigare arbetat i ett projekt av denna storlek d¨ar 8 personer medverkar. Det har st¨allt h¨ogre krav p˚a gruppens organisering och intern kommunikation. Gruppen definierade ett antal roller med specifika uppgifter, se 4.2.4 Roller. Intern kommunikation l¨ostes med ett antal verktyg, se 4.2.3 Koordinering. Alla gruppmedlemmar har tagit med sig erfarenheten att ta p˚a sig en specifik roll inom ett st¨orre projekt samt att kommunicera inom gruppen p˚a ett professionellt s¨att.

5.4

KVIT Conference

Det som skrevs ner p˚a lapparna finns i Bilaga 1. Totalt svarade 13 personer efter att ha testat systemet. H¨ar f¨oljer en kort sammanfattning av svaren.

• 6 personer uttryckte p˚a n˚agot s¨att att det var kul, coolt eller en rolig upplevelse.

• 4 personer tycket att det k¨andes ¨overtygande.

• 3 personer p˚apekade att de p˚a n˚agot s¨att upplevde problem med armarna. • 3 personer tyckte att det k¨andes f¨orvirrande eller konstigt till en b¨orjan. • 3 personer tyckte att huvudet var responsivt.

• 2 personer klagade p˚a synf¨altet.

5.5

Oversikt ¨

¨

over individuella bidrag

Alla deltagare i detta projekt har skrivit en individuell del som anknyter till rap-portens ¨amne. De finns som bilagor och ¨ar numrerade fr˚an A till H. Rubrikerna f¨or dessa ¨ar f¨oljande:

A. Kodgranskning av Robin Christensen B. Spatial n¨arvaro av Jacob Lundberg C. Olyckor med robotar av Ylva Lundeg˚ard D. Inverterad kinematik av Emil Segerb¨ack

E. Studie av dokumentation ¨over byggprocesser i mjukvaruprojekt av Patrik Sletmo

F. Virtual reality och cybersickness av Teo Tiefenbacher G. Etik av Jon Vik

H. Kravhantering och kundrelationer i rollen som analysansvarig av David Wajngot

6

Diskussion

Med den grundl¨aggande teorin och de valda metoderna producerade gruppen goda resultat, och till det fanns det m˚anga faktorer som spelade roll. Upplagt f¨or diskussion ¨ar gruppens arbetsprocess fr˚an planering till f¨ardigutvecklad pro-dukt, vilket omfattar f¨orstudie, metodval, resultat och vilka ˚atg¨arder f¨or h˚allbar utveckling som var t¨ankbara f¨or implementation.

6.1

Systemet

F¨or att f˚a bild av robotens perspektiv till ett VR-headset fanns flera f¨orslag p˚a l¨osningar. Webbkameran “Logitech C922 Pro Stream” valdes eftersom den er-bj¨od en god kompromiss mellan de olika prestandaegenskaperna projektgruppen var ute efter: h¨og uppl¨osning, h¨og uppdateringsfrekvens, brett synf¨alt, och ett rimligt pris. Webbkameran monterades p˚a robotens huvud strax ¨over ¨ogonh¨ojd f¨or att inte t¨acka n˚agra viktiga sensorer eller ventilationsh˚al. Med en st¨orre bud-get hade antagligen “CONNEX Pro Sight Camera” valts ist¨allet d˚a det enda negativa var priset och tillg¨angligheten. CONNEX-modellen hade till skillnad fr˚an de andra kamerorna ett st¨orre synf¨alt, vilket hade ¨okat inlevelsen. Ett annat alternativ hade varit att ha tv˚a separata webbkameror, f¨or att b¨attre simulera m¨anniskans djupseende. Eftersom tv˚a identiska kameror hade beh¨ovt anv¨andas f¨or att inte st¨ora f¨arg˚atergivningen blev tyv¨arr ¨aven det en budgetfr˚aga. Ro-botens inbyggda kamera anv¨andes inte trots kundens inledande ¨onskan. Den prioriterades bort f¨or att ist¨allet ge plats ˚at en l¨osning med webbkamera, d¨arf¨or att robotens inbyggda kamera gav f¨or f˚a bilder per sekund. Det var inte ¨onskv¨art d˚a det skulle resultera i att anv¨andare kan bli illam˚aende, och inlevelsen skulle f¨ors¨amras. I efterhand uppt¨acktes ¨aven att roboten hade tillr¨ackliga problem med att processera de r¨orelsekommandon som skickades ¨over n¨atverket p˚a den svaga processorn och det hade antagligen inte funnits rum f¨or att ¨aven skicka en h¨oguppl¨ost video.

Den ursprungliga id´en med projektet var att ett redan existerande verktyg f¨or att fj¨arrstyra roboten skulle vidareutvecklas f¨or att kunna anv¨andas med VR. Det visade sig att det verktyget inte kunde anv¨andas p˚a grund av ett in-kompatibelt programmeringsspr˚ak och bristande dokumentation. Till f¨oljd av detta togs beslutet att en ny applikation skulle utvecklas fr˚an grunden. Det p˚averkade f¨orv¨antningarna hos de flesta intressenterna, men det fick goda resul-tat i slut¨andan trots allt.

De viktigaste kraven som kunden st¨allde p˚a f¨orhand var att f˚a bild fr˚an kamera till VR-headset, att f˚a roboten att spegla anv¨andarens huvudr¨orelser i realtid, kontrollera armarna, f¨orflytta roboten och minimera f¨ordr¨ojningen i all kommu-nikation mellan HTC Vive och robot. Dessa krav ¨ar till stor del uppfyllda. Det som saknas ¨ar ytterligare f¨orb¨attrade armr¨orelser. Ut¨over detta fanns diverse l¨agre prioriterade krav som ej implementerades, d¨aribland att kunna styra flera robotar. I stort sett blev kandidatgruppen n¨ojd med slutproduktens funktiona-litet, i synnerhet med tanke p˚a projektets komplexitet och att man trots allt var tvungen att bygga systemet fr˚an grunden ist¨allet f¨or att bygga vidare p˚a

det redan existerande programmet fr˚an f¨oreg˚aende ˚ar. Best¨allarna gav ocks˚a uttryck f¨or sin bel˚atenhet och att de var imponerade av funktionaliteten.

6.2

F¨

orstudie

Innan projektets start hade projektgruppen f˚a erfarenheter med de verktyg som skulle anv¨andas. Det var ett komplext system som skulle byggas, och d¨armed sv˚art att avg¨ora vilken mjukvara och h˚ardvara som skulle komma att beh¨ovas, samt hur mycket tid som skulle g˚a ˚at till olika delar av utvecklingen. Allt detta utgjorde sv˚arigheter i att planera l¨angre ¨an f¨orsta iterationen. Projektplanen kunde d¨armed inte bli f¨ardig under f¨orstudien. D˚a projektgruppen inte ¨annu var insatta i systemet blev det ¨aven sv˚art att skriva en arkitekturbeskrivning.

¨

Ovriga dokument kunde skrivas relativt sm¨artfritt.

En systemanatomi togs fram och reviderades ett antal g˚anger av projektgrup-pen. Det gav m¨ojligheten att tidigt i projektet f˚a en ¨oversikt ¨over systemet och vilka delar som kr¨avdes f¨or att f˚a fungerande funktioner. Genom att diskutera systemanatomin inom gruppen bildades en gemensam bild av slutproduktens struktur och konsensus kunde uppst˚a. Detta var ett mycket effektivt s¨att att ge hela gruppen en gemensam ¨oversiktsbild av systemet. Det var ¨aven myc-ket anv¨andbart att kunna se vilka beroenden som fanns mellan modulerna i systemet.

6.3

Projektorganisation

Med hj¨alp av gruppkontraktet best¨amdes bl.a. rutiner vid veckom¨oten och kom-munikation, och f¨orv¨antat ansvar fr˚an varje gruppmedlem. Kontraktet togs fram tidigt, vilket bidrog till att utvecklingen kunde avancera fram˚at. Rutinerna f¨or m¨oten har f¨orblivit of¨or¨andrade, d˚a det har fungerat bra. Ibland har extrain-satta m¨oten ¨agt rum d˚a gruppen ansett att en vecka emellan m¨oten under vissa perioder varit f¨or l˚ang tid.

Applikationen som samverkade med vald utvecklingsmetodik byttes ut under utvecklingen pga. flera anledningar. Bytet fr˚an Asana till Trello gjordes f¨or att ¨

oversikten var b¨attre i Trello, som ¨aven till˚ater flera personer att tilldelas ansvar f¨or en uppgift till skillnad fr˚an Asana.

Nio roller f¨ordelades ¨over ˚atta personer, d¨ar arkitekten ¨aven agerade konfigura-tionsansvarig. Det k¨andes l¨ampligast d˚a rollen “konfigurationsansvarig” tolka-des som ett mindre ansvar. Det gav utrymme till att n˚agon fick anta rollen som specialist, och i det h¨ar projektet innebar den rollen att man var specialist inom virtual reality. Med tanke p˚a att gruppens erfarenhet kring utveckling med VR p˚a f¨orhand var minimal, verkade det som en bra id´e att n˚agon agerade specialist.

6.4

Utvecklingsmetodik

P˚a grund av ¨overg˚angen fr˚an Scrum till Kanban och att det nya s¨attet att ut-veckla p˚a gjordes mer f¨orfinat och definierat ¨an tidigare ¨ar det sv˚art att direkt j¨amf¨ora Kanban-metoden med Scrum-metoden. Den st¨orsta anledningen till att Scrum-metodikten inte l¨angre applicerades var f¨or att Scrum l˚aser de utveck-lingsobjekt man valt f¨or en iteration och projektgruppen k¨ande att det var sv˚art att uppskatta hur mycket som skulle hinnas med. Mycket arbete har skett pa-rallellt med stora uppgifter och det f¨orsv˚arade uppskattningen ytterligare. Ifall det hade blivit mer naturligt att ses tidigt varje dag hade de “standup-meetings” som g¨or Scrum k¨ant med f¨ordel kunnat inkluderas i den nya metoden, och p˚a s˚a s¨att tagit gruppen n¨armre Scrum-metodiken.

6.5

Utvecklingsverktyg

Unity var ett av de verktyg som anv¨andes mest under projektet. Unity har m˚anga funktioner som underl¨attar utvecklingen av 3D-applikationer. VR-integ-rationen ¨ar v¨aldigt l¨att att anv¨anda. Det ¨ar ocks˚a relativt enkelt att koppla till externa bibliotek om man beh¨over det. Unity valdes ¨over Unreal som ¨ar en annan vanlig spelmotor eftersom Unity st¨oder utveckling i .NET-spr˚ak vilket kan vara enklare att utveckla i ¨an exempelvis C++. Unreal kr¨aver att man programmerar i ett grafiskt spr˚ak som kallas Blueprints eller i C++.

Choreographe anv¨andes ocks˚a en hel del, mest f¨or att testa r¨orelser n¨ar vi inte hade tillg˚ang till roboten. Det hade kanske lite mer funktioner ¨an vad som kr¨avdes f¨or v˚art projekt, men den inbyggda robot-simulatorn var till stor hj¨alp under utvecklingen d˚a roboten delades med hela IDA.

Vi fick lite problem med NAOqi SDK. N¨ar det st¨otte p˚a n˚agot fel krashade det vilket fick till f¨oljd att hela Unity ocks˚a krashade. Det hade varit bra om det hade funnits n˚agot s¨att att exempelvis kontrollera ett returv¨arde f¨or att detektera problem s˚a att det hade varit hanterbart. SDK:t hade inte heller inbyggd IK f¨or Pepper vilket var udda eftersom det fanns till NAO. Det hade varit en stor hj¨alp vid utvecklingen och hade f¨ormodligen kunnat ge ett mycket b¨attre resultat ¨an n˚agon IK-algoritm som implementerats av en tredje part.

6.6

Insamling av reflektioner fr˚

an KVIT Conference

De insamlade reflektionerna varierade en del, b˚ade i vad de svarande fokuserade p˚a och i omd¨ome av systemet. Vissa av reflektionerna handlade n¨astan enbart om tekniska synpunkter medans andra handlade mer om underh˚allningsv¨ardet eller andra intryck. En anledning till spridningen i fokus p˚a svaren ¨ar antagligen att ingen vidare instruktion gavs, mer ¨an att skriva en kort reflektion om syste-met. Tillf¨orlitligheten av svaren p˚a korten kan ocks˚a uppfattas som bristande p˚a grund av detta och att korten i sig var fysiskt sm˚a och d¨arf¨or begr¨ansade m¨ojligheten att uttrycka sig.

Trots detta ¨ar dessa korta reflektioner intressanta. Speciellt eftersom en stor del av dem var positiva och en del av dem ¨aven h¨avdade att upplevelsen var ¨

overtygande. Det sistn¨amnda talar f¨or att systemet skulle kunna anv¨andas f¨or dess utsatta syfte. Dock b¨or det tas med viss skepsis d˚a urvalet av reflektioner var litet och d¨arf¨or inte kan generaliseras till en st¨orre population.

6.7

Metoder f¨

or att f˚

anga erfarenheter

Att genomf¨ora granskningar av allt material som gruppen producerade under projektet var en god tanke och har h¨ojt kvaliteten p˚a materialet. N˚agot som kunnat g¨oras b¨attre i samband med granskningar ¨ar att rapportera de l¨ardomar som gjorts under granskningen, b˚ade av granskaren och av upphovsmannen, f¨or att dela dem med resten utav gruppen.

Veckom¨oten d˚a hela gruppen samlats och kunnat diskutera har varit till stor hj¨alp i att fatta beslut och samordna arbetet. Det blev emellertid s˚a att fokuset f¨or dessa m¨oten s¨allan blev att ta upp problem och presentera erfarenheter och l¨ardomar. Ist¨allet hamnade fokus p˚a vilka framsteg gruppen gjort eller inte gjort under veckan, och hur arbetet skulle forts¨atta n¨asta vecka. D¨aremot har itera-tionsutv¨arderingarna delvis t¨ackt upp f¨or denna brist. Iterationsutv¨arderingarna har n¨astan enbart handlat om att identifiera problem, l¨osningar till dessa pro-blem och vilka l¨ardomar vi som grupp kunnat dra fr˚an dem. Detta har varit till stor hj¨alp och underl¨attat f¨or gruppen att identifiera de arbetss¨att som fungerat bra och de som kunnat f¨orb¨attras.

6.8

H˚

allbar utveckling

N¨ar det kommer till att minska klockfrekvensen p˚a datorn vi anv¨ander f¨or att k¨ora v˚ar kod s˚a ¨ar det fullt m¨ojligt. Dock skulle det f˚a stora konsekvenser. HTC Vive kr¨aver stora m¨angder resurser f¨or att kunna leverera en s˚a f¨ordr¨ojningsfri upplevelse som m¨ojligt. Dessutom finns det ett krav p˚a att mjukvaran vi le-vererar ska vara s˚a fri fr˚an latens som m¨ojligt. Minskas klockfrekvensen ¨okar f¨ordr¨ojningen, vilket kunden vill h˚alla s˚a l˚ag som m¨ojligt. N¨ar en avv¨agning g¨ors mellan prestanda och str¨om˚atg˚ang m˚aste projektets storlek tas h¨ansyn till. Eftersom programvaran endast kommer anv¨andas av en kund, under kor-ta tidsintervall och vid f˚a tillf¨allen ¨ar det sv˚art att motivera en minskning av klockfrekvens. Dessutom skulle en minskning i prestanda vara m¨arkbar, vilket kunden inte efterfr˚agar.

Att implementera v˚art projekt i ett l˚agniv˚aspr˚ak som assembler hade varit om¨ojligt p˚a den tidsbudgeten som var tillg¨anglig. I projektet var vi v¨aldigt bundna till Unity f¨or att enkelt kunna sammankoppla v˚ar kod med kringut-rustningen. Visst skulle delar av koden kunnat skrivas i till exempel assembler. Men med tanke p˚a projektets storlek s˚a skulle nog tiden det tar att utveckla i assembler vara tillr¨ackligt stor f¨or att det inte skulle vara v¨art det ur en energi-synpunkt. Det vill s¨aga att energin man sparar p˚a optimeringen kanske inte ¨ar st¨orre ¨an den ytterligare energin som g˚ar ˚at f¨or ¨okad utvecklingstid.

Att minska frekvensen p˚a pollningen av HTC Vive skulle nog vara teoretiskt m¨ojligt, men ˚aterigen st˚ar vi inf¨or problemet prestanda mot energi˚atg˚ang. Som tidigare n¨amnt s˚a ¨ar kunden enbart ett f˚atal personer och koden kommer k¨oras ytterst lite. D¨arf¨or ¨ar det nog inte heller v¨art att minska frekvensen av pollning-en.