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.