Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik och Mjukvaruteknik
19 | LIU-IDA/LITH-EX-G--19/011--SE
Utveckling av Mobilapplikation
för Rörelseanalys med
Kaskad-klassificerare
Development of a Mobile Application for Motion Analysis with
Ca-scade Classifiers
Alexander Andersson
Alexander Basa
Andreas Lindstén
Markus Loborg
Anton Orö
Handledare : Aron Gosch Examinator : Kristian Sandahl
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum 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 kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ 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 sammanhang som är kränkande för upphovsman-nens litterä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 circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, 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 consent 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 University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Alexander Andersson Alexander Basa Andreas Lindstén Markus Loborg Anton Orö
Sammanfattning
Denna rapport behandlar projektarbetet som utfördes av fem studenter inom datateknik och mjukvaruteknik vid Linköpings Universitet. Projektarbetet utfördes som en del av kur-sen TDDD96 Kandidatprojekt i mjukvaruutveckling under vårterminen 2019. Syftet med rapporten är att utvärdera arbetsgången för framtagningen av en produkt. Projektet be-handlar implementering av bildanalys för mobila Android-enheter och har gjorts på upp-drag av Image Systems Nordic AB. Applikationens ändamål var att genom kameran på en mobiltelefon kunna spåra objekt och analysera dess positioner. Resultatet av projektar-betet är applikationen TrackApp som genom maskininlärning kunde spåra objekt i realtid och på video. Utöver produkten bearbetar rapporten hur projektgruppen arbetade samt individuella fördjupningsområden gruppmedlemmarna studerat.
Författarens tack
Vårt kandidatarbetet hade inte varit möjligt att utföra utan uppdraget från vår kund Image Systems Nordic AB och vi vill tacka dem för ett varmt bemötande och möjligheten att jobba med en spännande teknik, ett speciellt tack vill vi även ge till Tomas Chevalier och Fredrik Rudbeck. Vi vill även rikta ett stort tack till vår kursledare Kristian Sandahl och handledare Aron Gosch som stöttat oss under projektets gång särskilt när vi tappade två teammedlem-mar.
Innehåll
Sammanfattning iii Författarens tack iv Innehåll v Figurer viii Tabeller x Definitioner xi 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställning . . . 2 1.4 Avgränsningar . . . 2 2 Bakgrund 3 2.1 Beställaren . . . 3 2.2 Applikationen . . . 3 2.3 Tidigare Erfarenheter . . . 3 3 Teori 5 3.1 Metoder . . . 5 3.2 Verktyg . . . 5 3.3 Bildanalys . . . 7 4 Metod 9 4.1 Organisation . . . 9 4.2 Iterationer . . . 10 4.3 Dokumentation . . . 10 4.4 Utveckling . . . 114.5 Testning och kvalitetssäkring . . . 13
4.6 Samarbete med kund . . . 14
4.7 Versionshantering . . . 14
4.8 Metod för att fånga erfarenheter . . . 15
5 Resultat 16 5.1 Dokument . . . 16 5.2 Logotyp . . . 17 5.3 Bildanalys . . . 17 5.4 Användargränssnitt . . . 18 5.5 Tester . . . 20
5.6 Grafritning . . . 21
5.7 Gemensamma erfarenheter . . . 21
5.8 Sammanfattning av individuella delar . . . 23
6 Diskussion 25 6.1 Resultat . . . 25
6.2 Vidareutvecklingspotential . . . 26
6.3 Tester . . . 27
6.4 Metod . . . 29
6.5 Arbetet i ett vidare sammanhang . . . 29
7 Slutsatser 31 7.1 Går det att implementera objektspårning i en mobilapplikation? . . . 31
7.2 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 31
7.3 Vilka erfarenheter kan dokumenteras från programvaruprojektet, som kan va-ra intressanta för fva-ramtida projekt? . . . 31
7.4 Hur kan applikationen implementeras så att man skapar värde för kunden? . . 32
A Alexander Andersson: 3D-Rekonstruktion, en Kortare Abstraktion 33 A.1 Inledning . . . 33 A.2 Bakgrund . . . 34 A.3 Teori . . . 34 A.4 Metod . . . 35 A.5 Resultat . . . 36 A.6 Diskussion . . . 38 A.7 Slutsatser . . . 39
B Alexander Basa: Hantering av Icke-Funktionella Krav i Mjukvaruutveckling 40 B.1 Inledning . . . 40 B.2 Teori . . . 41 B.3 Metod . . . 41 B.4 Resultat . . . 42 B.5 Diskussion . . . 44 B.6 Slutsatser . . . 45
C Andreas Lindstén: Attitydundersökning av Allmänhetens Inställning till Dator-seende Kamerabevakning 46 C.1 Inledning . . . 46 C.2 Bakgrund . . . 47 C.3 Teori . . . 47 C.4 Metod . . . 48 C.5 Resultat . . . 49 C.6 Diskussion . . . 52 C.7 Slutsatser . . . 56
D Markus Loborg: För och Nackdelar med Automatisk Testning i Git 57 D.1 Inledning . . . 57 D.2 Bakgrund . . . 58 D.3 Teori . . . 58 D.4 Metod . . . 58 D.5 Resultat . . . 59 D.6 Diskussion . . . 60 D.7 Slutsatser . . . 61
E Anton Orö: En Jämförelse av Olika Klassificerare i OpenCVs Bibliotek 62 E.1 Inledning . . . 62 E.2 Bakgrund . . . 63 E.3 Teori . . . 63 E.4 Metod . . . 66 E.5 Resultat . . . 66 E.6 Diskussion . . . 67 E.7 Slutsatser . . . 68 F Frågeformulär 69 Litteratur 72
Figurer
3.1 Exempelbild på gruppens Trelloboard. . . 6
4.1 Översikt över arbetsflödet. . . 12
4.2 Skiss av navigeringen för TrackApp. . . 14
5.1 Systemanatomin . . . 17
5.2 Logotypen för projektet. . . 17
5.3 Skärmbilder av applikationen . . . 19
5.4 Skärmbilder av applikationen . . . 20
6.1 Visualisering av djup . . . 27
6.2 Sustainability Analysis Diagram för TrackApp . . . 30
A.1 Nattvarden, Perspektivlinjer och horisonten är markerade i blått [Nattvarden]. . . 34
A.2 Illustration av projektion av ett kartesiskt system.Blå linje - andragradsekvation, röd linje - hyperbel . . . 35
A.3 Camera Obscura (Nålhålskamera - egenskapad bild). . . 36
A.4 Illustration av Epipolär geometri [EpipolarPicture]. . . . 37
B.1 Processen för framtagning av relevanta artiklar . . . 42
C.1 Inställning till övervakningskameror på allmän plats. . . 50
C.2 Inställning till att byta ut traditionella mot datorseende övervakningskameror. . . 50
C.3 Inkräktar övervakningskameror på den personliga integriteten? . . . 50
C.4 Allmänhetens åsikt kring övervakningskamerors brottsförebyggande effekt. . . 51
C.5 Allmänhetens åsikt kring övervakningskamerors användbarahet för att upptäcka pågående brott. . . 51
C.6 Allmänhetens åsikt kring ifall deras integritet kränks om polisen själva tillåts be-sluta om sitt behov av datorseende övervakningskameror. . . 51
C.7 Allmänhetens åsikt för vilken åtgärd som är mest avgörande för att behovet av integritet säkerställs. . . 52
C.8 Inställning till att sätta upp fler traditionella övervakningskameror. . . 53
C.9 Allmänhetens åsikt kring att traditionella övervakningskameror är användbara föra att klara upp brott. . . 54
E.1 Haar-kännetecken rektanglar . . . 64
E.2 Resultatet av summerad area tableux . . . 65
E.3 Kaskadklassificerare . . . 65
E.4 Kaskadklassificerare träningsdata . . . 67
F.1 Frågeformulärets inledning. . . 69
F.2 Fråga 1. . . 69
F.4 Fråga 3. . . 70
F.5 Fråga 4. . . 70
F.6 Fråga 5. . . 71
F.7 Fråga 6. . . 71
Tabeller
B.1 Identifierade problem . . . 43 E.1 LBP-metoden . . . 67 E.2 Haar-metoden . . . 67
Definitioner
• Bitcode Likt maskinkod exekveras Javas kod genom i ett liknande format kallat bitcode. • Bitmap Format för lagring av bilder. En matris innehåller information om färgkoder för
varje enskild pixel.
• Commit En commit är när en utvecklare skapar en "återställningspunkt" på en gren som git känner igen. Denna punkt sparas undan med ett specifikt ID som kan användas se-nare för att få tag på "återställningspunkten". Detta görs bland annat om man vill granska hur det såg ut vid det tillfället. Oftast används det dock för att antingen felsöka pro-grammet genom att gå igenom commit för commit för att se vart felet dök upp eller för att återställa programmet till en tidigare version för att någonting gick fel i senare versioner och det var enklare att börja om än att leta reda på och fixa felet.
• Frame För en video eller rörlig bild är en frame en bild i denna sekvens.
• GPU Grafik processor (Graphics Processing Unit) är en optimerad enhet för grafikrela-terade beräkningar.
• Gren En gren är en sak som Git använder för att dela upp kod. När man använder Git skapas automatiskt en Master-gren. Sedan är det upp till utveklarna eller personen som är ansvarig för Git att bestämma om fler grenar ska skapas. Grenar används för att man ska kunna modifera koden utan att påverka funktionaliteten av programmet. Ofta finns det minst tre grenar Nämligen mastergrenen, en utvecklingsgren och en gren för den senaste släppta versionen av kod. Dessa grenar brukar ofta existera under hela projektets gång medan mindre grenar ofta skapas för att lösa problem(buggar), skapa nya funktioner(features) och testa ny kod.
• IDE IDE står för Integrated Development Environment och är en miljö som underlättar utvecklandet. Oftast är det ett program som ger stöd för kodning på något sätt.
• Gradle Gradle är ett byggsystem som Android använder för att bygga sina projekt. Det betyder att när man startar ett android projekt från IDE:n så startas egentligen ett Gradle-program. Detta program bygger ihop applikationen och installerar den på emu-latorn eller telefonen.
• Layer Androidens grafiska användargränssnitt byggs på lager, så kallade layers. • Merge En merge är när man slår ihop kod från en gren med kod från en annan gren.
Konflikter kan uppstå när man försöker kombinera koden. I det tidigare fallet föreslår versionshanteringsverktyget att man löser dessa konflikter och är ofta tvungen att göra några ändringar för att kunna köra koden men tekniskt sett är det inte tvunget. Gör man dock en merge där man med flit försöker kombinera två grenar måste alla konflikter lösas innan man kan gå vidare. Självfallet finns det sätt att gå runt detta krav men det är oftast kontraproduktivt att använda dessa.
• Pull En pull är när en utvecklare hämtar ner alla ändringar som har gjorts på nuvarande gren. En pull kan enbart misslyckas då en av följande kriterier är uppfyllda
– Man har inte rättigheter att hämta informationen
– Man har inte internet-tillgång
– Det är något problem med den centrala servern där informationen ligger
– Vissa filer har modifierats och kommer bli överskrivna av informationen som ska hämtas
Utöver dessa kriterier kan en pull inte misslyckas. Men även om det inte misslyckas kan det fortfarande uppstå problem. Dessa problem kommer då både utvecklaren och den centrala kodbasen har ändrat på samma filer men pullen fortfarande går igenom. Då notifierar Git utvecklaren om detta och ber hen att lösa dessa konflikter (ofta kallade merge-konflikter) innan hen fortsätter arbeta. Oftast går det inte att fortsätta arbeta utan att lösa dessa konflikter då git lägger in textsträngar i de berörda filerna för att markera konflikten vilket oftast gör koden okörbar.
• Push En push är när en utvecklare uppdaterar den centrala delen av git med alla lokala ändringar som utvecklaren har gjort på en gren. Det görs genom att alla commits som utvecklaren har gjort på denna gren sedan senaste push skickas till den centrala servern. Git granskar ifall pushen går igenom eller inte. En push kan misslyckas om en annan utvecklare har gjort en push på samma gren som denna utvecklare inte har hämtat ner till sin lokala version. En push kan också misslyckas om det körs några scripts innan pushen (så kallade pre-push scripts) som kan misslyckas.
• Sprint Arbetet som skall göras delas in i sprintar. En sprint är 1-4 veckor lång.
• Sprint-backlog En Sprint-backlog är en lista av aktiviteter som skall utföras under kom-mande sprint.
• Sprint-planning Gruppen bryter ner de aktiviteter som skall utföras under kommande sprint samt estimerar den tid som skall utföras.
• Sprint-retrospective Samtliga gruppmedlemmar deltar i ett möte där föregående sprint utvärderas samt man diskuterar vad som skall förbättras inför nästa.
1
Inledning
Denna rapport beskriver det kandidatarbete som utförts av fem studenter från data- och mjukvaruteknikprogrammen på Linköpings universitet under våren 2019. Projektet behand-lar implementering av bildanalys för mobila Android-enheter och har gjorts på beställning av Image Systems Nordic AB.
1.1
Motivering
Idag finns det kraftfulla bildanalysprogram som snabbt och enkelt kan identifiera, klassifice-ra samt följa objekt från såväl stillbilder som videofilmer. Denna typ av mjukvaklassifice-ra har varit väldigt värdefull för industrin och har flera applikationsområden, så som säkerhet, mätning och medicin. Dessa program kan på grund av dess komplexitet vara kostsamma vilket inte gör dem tillgängliga för alla. Av denna anledning finns det intresse av att ta reda på ifall detta kan förenklas och implementeras för mer lättillgänglig hårdvara för enklare användning för såväl mindre organisationer som privatpersoner. Ett annat användningsområde av enklare implementationer skulle vara demonstration av konceptet bildanalys på företagsmässor där kunden deltar. Ytterligare en motivering med rapporten är att samla projektmedlemmarnas erfarenheter av att jobba i en projektgrupp för att ta fram en produkt på beställning av en kund.
1.2
Syfte
Den här rapporten syftar till att beskriva det projekt som genomförts. Den behandlar teorier, metoder och resultat för att ta fram och utveckla mjukvara för bildanalys anpassad för mobi-la enheter, implementerad för Android specifikt. Arbetet har gjorts på beställning av Image Systems Nordic AB. De var intresserade av hur den mjukvarumässiga strukturen för ett så-dant här projekt skulle kunna se ut. Den resulterande mjukvaran kommer fungera som en prototyp eller ett underlag för Image Systems Nordic AB att bygga vidare på.
1.3. Frågeställning
1.3
Frågeställning
Under arbetets gång kommer gruppen försöka att besvara följande frågor. Resultatet av ap-plikationen TrackApp och de använda arbetsmetoderna kommer att ligga till grund för detta.
1. Hur kan applikationen implementeras så att man skapar värde för kunden?
2. Vilka erfarenheter kan dokumenteras från programvaruprojektet, som kan vara intres-santa för framtida projekt?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Går det att implementera objektspårning i en mobilapplikation?
1.4
Avgränsningar
Detta projekt är begränsat till att endast utvecklas för mobila Android-enheter. Förutom detta finns det en tidsmässig begränsning på cirka 400 timmar per gruppmedlem, det vill säga cirka 2000 timmar totalt.
2
Bakgrund
Detta projekt har utförts som en del av kursen Kandidatprojekt i programvaruutveckling (TDDD96) på Linköpings universitet. I detta avsnitt beskrivs uppdraget mer i detalj.
2.1
Beställaren
Projektet sker på beställning av företaget Image Systems Nordic AB. Företaget har sitt ur-sprung i en utbrytning från Linköpings Universitet och skapades 1983 för att konstruera lösningar till behandling av bilder och videor tagna med höghastighetskameror[1]. De är i dagsläget en kommersiell aktör på marknaden för produktion och tjänster inom högupplöst bildbehandling. TEMA och TrackEye är företagets ledande projekt. Det förstnämnda är före-tagets kommersiella produkt som inkluderar flertal artiklar för användning inom industriellt bruk, bland annat krocktester. Det senare är utvecklat för militärt bruk med stöd för GPS och radar. Företagen som använder sig av Image Systems produkter är bland annat Volvo, Saab, DGA med flera. Företagets programvara har som huvudsyfte att användare skall kunna spå-ra objekt eller markörer genom video för att sedan kunna bilda sig en distinkt uppfattning om objektens rörelse, position och acceleration bland annat. Företagets ledande projekt har även möjlighet att analysera rotationen av objekt.
2.2
Applikationen
Image Systems Nordic AB har som ambition att genom projektet skapa en mobilapplikation som skall fungera som ett demonstrationsverktyg för företagets huvudprodukter på bland annat företagsmässor. Dess målsättning är att utveckla en förenklad version av en deras hu-vudprodukt, TrackEye. Projektarbetet kommer följaktligen att fungera som en prototyp och kommer att vara anpassad så att det finns möjlighet för vidareutveckling av företaget.
2.3
Tidigare Erfarenheter
Gruppmedlemmarna har alla erfarenhet av objektorienterad programmering i Java. Vissa er-farenheter finns även inom androidutveckling och Android Studio men mycket kunskap måste kompletteras för att gruppen ska kunna utveckla en antagbar applikation. Ingen av
grupp-2.3. Tidigare Erfarenheter
medlemmarna har tidigare erfarenheter av bildanalys. Då detta är det prestandamässigt mest kritiska området för en fungerande slutprodukt krävde denna del kräva mest utbildningstid för samtliga medlemmar.
De studenter i gruppen som läst kursen "Konstruktion med Mikrodatorer"har erfarenhet av att jobba i liknande projekt. Detta leder till att dessa studenter har erfarenhet av hantering, planering samt dokumentskrivning i större projekt. Merparten av dokumenten i denna kurs följer därför samma struktur som är inspirerad av LIPS-modellen [2].
Samtliga medlemmar har även erfarenhet av vad som fungerat bra samt dåligt i tidigare projekt. Därför sammanfattades dessa erfarenheter i början av projektet och ur detta skrevs ett gruppkontrakt. I gruppkontraktet skrevs bland annat förhållningsregler kring kommuni-kation, kodstandarder, deadlines och tidspassning.
3
Teori
Detta avsnitt kommer beskriva metoder, mjukvara och den allmänna teorin som ligger till grund för projektet. Även programvara som använts för framtagning av dokument samt kommunikation beskrivs översiktligt. Här beskrivs även den agila arbetsmetoden som an-vänts under projektets gång.
3.1
Metoder
Här beskrivs om de agila arbetsbetoder varifrån idéer har lånats för att komponera den ut-vecklingsmetodik som använts i projektet.
3.1.1
Scrum
Scrum är en agil arbetsmetodik populär inom mjukvaruutveckling runtom i världen. Att Sc-rum är agilt innebär att metoden tillämpar ett iterativt, inkrementellt tillvägagångssätt för att lösa allt från enkla till komplexa problem. Scrum är även väl anpassat till denna typen av projekt då det ger individerna i gruppen mycket eget ansvar. I Scrum arbetar man i Sprints som är cirka 1-4 veckor långa. Under en sprint utför man den sprint-backlog som planerats i början av sprinten. Efter en sprint så utvärderas arbetet, både hur arbetet gått samt vad man har hunnit med[3].
3.1.2
Kanban
Kanban är ett avskalat tillvägagångssätt för mjukvaruutveckling. Ordet Kanban betyder på japanska "Skylt" eller "Tavla" och sammanfattar mer eller mindre vad denna metodik går ut på. Kanban är ett sätt att visuellt hantera det arbete som krävs för att skapa värde genom att på ett tydligt sätt dela upp arbetet bland gruppmedlemmar. Ett exempel på hur man kan använda detta är att samtliga uppgifter bryts ned och skrivs sedan upp på någon typ av skylt, sedan väljer gruppmedlemmar vad de vill göra och sätter denna skylt under sitt namn[4].
3.2
Verktyg
3.2. Verktyg
3.2.1
Android Studio
Android Studio är Android’s officiella IDE (Integrated Develepment Environment) och är ba-serat på IntelliJ IDEA. I Android Studio finns funktionalitet för att kunna testa applikationen i en emulerad miljö alternativt kunna överföra applikationen via USB till telefon. Detta under-lättar utvecklingen av Androidapplikationer[5].
3.2.2
OpenCV
OpenCV heter det bildbehandling- samt maskininlärningsbibliotek som framförallt har an-vänts i detta projekt. Biblioteket har färdigt stöd för ett flertal funktioner, bland annat Kaskad Klassifikation (se 3.3.2) som används för spårningen av markörer[6].
3.2.3
Trello
Trello är en organisationsapplikation samt hemsida där användare kan skapa tavlor, listor och kort med uppgifter för att enkelt kunna fördela arbetet[7]. Gruppen använde funktio-naliteten för att på ett översiktligt sätt se vem som hade ansvar för vad samt för att se status på uppgifterna. Ett kort skapades per aktivitet i sprint-backloggen och sedan skrev de grupp-medlemmar som ville utföra aktiviteten sitt namn på det kortet. När uppgiften var slutförd så lades uppgiften under tavlan "Testa" för att meddela resterande gruppmedlemmar att denna uppgift behövde ses över.
Figur 3.1: Exempelbild på gruppens Trelloboard.
3.2.4
Git
Git är ett decentraliserat versionshanteringsprogram som kan användas för att samtliga med-lemmar ska kunna jobba på ett gemensamt projekt[8]. Git erbjuder även stöd för att köra skripts före, under och efter de flesta av stegen som Git använder för att hålla koll på projektet och förenkla uppdateringar av projektet så som commit, push, pull, merge med mera. Detta kan användas för att skriva skript som automatiskt testar kod vid något av dessa tillfällen.
3.2.5
GitLab
GitLab är en webbplattform som har servrar för att hålla den centrala delen av koden för projekt som använder Git för versionshantering. GitLab har också en hel del verktyg för att underlätta utveckling av ett projekt[9]. Webbplatformen ger också stöd för övervakning vid merge av grenar. Stödet innefattar krav på kodgranskning i den utsträckning att via GitLab
3.3. Bildanalys
kan man tilldela utvecklare roller med olika behörigheter och restriktioner. Till exempel kan man påtvinga kodgranskning på så sätt att vissa roller behöver utföra en merge förfrågning och få godkännande innan de kan pusha ny funktionalitet.
3.2.6
Slack
Slack är ett kommunikationsverktyg där samtliga projektrelaterade diskussioner kan hållas via text och samtal[10]. I verktyget kan olika kanaler och trådar skapas för att hålla relevanta diskussioner på ett ställe. Det går även att sända direktmeddelanden till enskilda personer.
3.2.7
Latex
Latex är ett gratis typsättningsverktyg, och är standard för kommunikation och publikation av vetenskapliga dokument[11]. Latex är inte i sig självt en textredigerare utan en Latexredi-gerare används oftast. Det här dokumentet är skrivet med Latex.
3.2.8
Overleaf
Overleaf är en gratis Latexredigerare där flera personer kan skriva i samma dokument samti-digt[12]. Overleaf har grammatikhjälp samt ett flertal andra bra funktioner för att underlätta skrivandet av dokument i Latex.
3.2.9
Google Drive
Google Drive är en molntjänst som samtliga medlemmar kan komma åt, redigera samt se dokument, kalkylark och bilder med mera[13]. Här kan flera individer redigera ett dokument på samma gång från olika ställen. Dessa är egenskaper som gör att denna tjänst lämpar sig väl för stora projekt där flera dokument ska redigeras och läsas samtidigt.
3.2.10
MPAndriodChart
MPAndroidChart är ett grafritningsbibliotek för Android. MPAndroidChart kan användas för att snabbt och enkelt rita ut linje- block- cirkel- spindel- bubbel- och ljusdiagram[14].
3.3
Bildanalys
I detta kapitel beskrivs hanteringen av bildanalysen i projektet.
3.3.1
Hough Transform
För att detektera enklare former i en bild så kan man använda sig utav en teknik som heter Hough Transform. Denna teknik kan då användas för att identifiera t.ex. linjer eller cirklar i ett större mönster för att avgöra om det är det objekt man söker.
3.3.2
HAAR Cascade Classifier
För att kunna genomföra spårning av markör i detta projekt så används framförallt en metod, nämligen HAAR-feature detection, som OpenCV har stöd för. För att hitta ett ungefärligt värde på mittpunkten av markören används HAAR-kännetecken i applikationen. Haar-kännetecken är kännetecken som är unika för något specifikt objekt. Dessa fås ut automatiskt via Open-CV’s inbyggda verktyg. Dessa kännetecken är skillnader i pixelintensitet i en gråskalad bild och för en 24x24 pixlar stor bild fås cirka 160 000 st kännetecken [15]. Genom något som kallas Ada-boost, vilket är en maskininlärningsalgoritm, så kan dessa kännetecken delas in i
3.3. Bildanalys
kaskadklassificerare ("Cascade Classifier") samt antalet kännetecken kan minskas ner till cir-ka 6000. För att få så få och effektiva kännetecken som möjligt är det bra att använda mycket träningsdata, det vill säga många positiva bilder (bilder där markören finns med) samt nega-tiva bilder (bilder där markören inte finns med). Exakt hur många varierar mycket beroende på hur unikt objektet du vill leta efter är.
Kaskadklassificerare är ett effektivt sätt att slippa leta efter alla kännetecken i varje bild-område. Genom att endast ha ett kännetecken i första klassificeraren sedan tio i nästa och så vidare så kan man snabbt utesluta om en del av en bild innehåller objektet man söker efter eller ej, se Figur E.3.
När detta är gjort så skapas en kaskad-fil som kan användas på ett enkelt sätt i applika-tionen för att snabbt kunna hitta samtliga markörer i bild och ge ut dess x- och y-koordinater i bilden.
Nackdelen med denna implementation är att en del falska detektioner kan fås samt att koordinatpunkten i en bild för en markörs mittpunkt kan bli oprecis. För mer detaljerad ge-nomgång se appendix E.
4
Metod
I detta avsnitt beskrivs hur arbetet utförts för att ta fram en produkt samt för att besvara frågeställningarna.
4.1
Organisation
Inom projektgruppen tilldelades varje person en specifik roll. Detta var nödvändigt på grund av projektets storlek. Dessa roller innebar att arbetet kunde delas upp där en person hade ett specifikt ansvarsområde. Nedan följer en redogörelse av dessa roller samt vad de innebär.
Teamledare – Anton Orö
Teamledarens yttersta ansvar är att se till att processer följs, se till att gruppen är i en trevlig miljö samt ha sista ordet om någon dispyt skulle uppstå. I detta projekt representerade även teamledaren gruppen för all kontakt utåt förutom med kund. Teamledaren var även ansvarig för veckorapporter samt statusrapporter för varje iteration. Teamledaren agerar coach för gruppen vid tillfällen då det behövs och ser till att gruppens mål uppfylls.
Arkitekt – Alexander Basa
Arkitekten i projektet ansvarar för att en bra arkitektur som är anpassad till projektet används. Arkitekten är ansvarig för dokument som behandlar detta, framförallt arkitektur-dokumentet. Personen ansvarar även för den tekniska delen i projektet vilket inkluderar alla tekniska beslut där personen har sista ordet. Arkitekten skall även ta fram tydliga modeller för att ge gruppen en bra översikt av systemets uppbyggnad och arkitektur.
Utvecklingsledare - Andreas Lindsten
Utvecklingsledaren ansvarar för att ta fram en mer detaljerad design av produkten. Under utvecklingsfasen är även utvecklingsledaren ansvarig för samtliga projektmedlemmar (oav-sett tidigare roll) då samtliga medlemmar i detta projekt deltar vid utvecklingen.
Analysansvarig - Alexander Andersson
Analysansvarig har som ansvar att vara gruppens kontakt gentemot kunden. Detta innebär att personen är ansvarig för att ta reda på kundens verkliga behov samt för att vara gruppens förhandlingspart med insikt i kundens önskningar. Analysansvarig har även en nära kontakt
4.2. Iterationer
med både arkitekt och testledare för att kunna skriva och verifiera att krav uppfylls.
Kvalitetsamordnare - Markus Loborg
Kvalitetsamordnaren tar på sig ett stort ansvar då personens område innefattar testning och försäkring av att kvalitetskrav uppnås. Personen tar även det övergripande ansvaret av dokumentation för projektet. Kvalitetssamordnare ska se till att fånga in vad resten av gruppen har för erfarenheter samt att analysera dessa. Utifrån detta skall han förbereda en utbildningsplan och ge inspiration till gruppen om hur de ska gå tillväga. Som ansvarig för testning har personen ansvar för att sköta den dynamiska verifieringen och valideringen av systemet genom exekvering. Utöver det ska denna vara ansvarig för att ta fram en logotyp, dokumentmallar samt ändringsrutiner. Detta är dock något som hela gruppen hjälps åt med, då alla tar fram en mall för sitt eget ansvarsområde.
4.2
Iterationer
Projektet utfördes i flera iterationer. Inför en iteration uppdaterades en testplan. Varje itera-tion avslutades med en inlämning av de dokument som hade producerats under iteraitera-tionen samt en statusrapport och en testrapport.
4.3
Dokumentation
Ett flertal dokument behövdes under projektet för att fastställa struktur och ramverk för att arbeta inom. Gruppen använde sig av ett flertal dokument som beskrivs nedan.
4.3.1
Förstudie
Den förstudie som utfört gjordes genom att gruppen tillsammans med kunden gick igenom visionen för projektet och de förväntningarna man hade. Till detta arbete skrevs det ett flertal dokument som kommer att beskrivas i detta avsnitt.
Kravspecifikation
Efter att två personer ur gruppen träffat kunden och diskuterat projektet så fortsatte man diskutera inom gruppen. Mycket av syftet var att ta reda på för och nackdelar med mobila enheter och hur denna produkt på ett så bra sätt som möjligt kan implementeras för dessa. Det ledde till formulering av väldigt generella krav som man kom överens om med kunden. Genom att inte ha alltför specifika krav lämnade man frihet åt gruppen för att undersöka de bästa och mest lämpliga metoderna under arbetets gång.
Systemanatomi
En preliminär systemanatomi skissades fram för att få en övergripande visualisering av syste-mets funktionalitet. Detta dokument har utökats och förbättrats kontinuerligt under arbetets gång.
Projektplan
Kandidatgruppen tog fram en projektplan där man listade de uppgifter som behövde ge-nomföras samt en tidsuppskattning för dessa. Uppgifterna togs fram genom att gruppen gick igenom kravspecifikationen och diskuterade hur implementationen av kraven skulle kunna se ut tills konsensus var nådd.
4.4. Utveckling
Kvalitetsplan
Då gruppen från början bestod av sex gruppmedlemmar påbörjade kvalitetsansvarig ett do-kument för en kvalitetsplan till projektet inspirerat av IEEE std 730. Egentligen var det be-stämt att gruppen skulle ha sju medlemmar men ett avhopp skedde innan projektet börjat. Syftet med kvalitetsplanen var att sätta och upprätthålla standarder för kvaliteten på doku-menten och produkten TrackApp. När ännu en gruppmedlem hoppade av så att gruppen nu bestod av fem personer övergavs arbetet med att färdigställa och upprätthålla kvalitetsplanen som ett levande dokument. Istället skapade kvalitetsansvarig tillsammans med utvecklings-ledaren en presentation för examinatorn. Presentationen beskrev översiktligt de delar som skulle ha ingått i den fulla versionen av kvalitetsplanen. Den beskrev även hur projektgrup-pen säkerställer att kvaliteten upprätthålls. Kvaliteten säkerställs genom diskussioner som utgår från kravspecifikationen och gruppmedlemmarnas tidigare erfarenhet av standarder.
4.3.2
Veckorapport
Varje vecka skickades en veckorapport till handledaren samt examinatorn. I veckorapporten sammanfattades veckans arbete samt kommande veckas arbete.
4.3.3
Statusrapport
I slutet av varje iteration skickades en statusrapport in. Statusrapporten reflekterade över hela iterationens arbete, hela nästa iterations arbete samt de risker projektet stod inför nästa iteration.
4.3.4
Arkitekturdokument
Arkitekturdokumentet skapades för att ge en beskrivning av den arkitektur som använts för utvecklingen av applikationen. Här beskrivs även för- och nackdelar med den arkitektur som har valts. Detta dokument skrevs på engelska, då kunden önskade detta.
4.4
Utveckling
Utvecklingen inleddes med att arkitekten gjorde en övergripande design som sedan delade upp projektet i olika områden. Gruppmedlemmarna fick sedan ansvar för dessa områden. Varje ansvarig person fick se till att ta till sig den nödvändiga kunskap som behövdes för att förstå vad som skulle göras och hur det skulle implementeras. Utöver detta hade man även ansvar för den tillhörande dokumentationen. De huvudområden som identifierades var:
• Bild-analys • Data-analys • Testning
• Datavisualisering/GUI
Designval gjordes genom att testa olika typer av metoder med fokus på dess komplexitet för att säkerställa att de inte skulle utgöra något hinder för de utsatta kvalitetskraven eller förhindra utökning eller modifiering av mjukvaran. Utvecklingen skedde genom att var och en tog ansvar för sitt område enligt tilldelning, däremot skedde ett nära samarbete mellan gruppmedlemmar inom dessa områden. Det bestämdes att minst ett möte skulle hållas per vecka för att gruppen skulle kunna ligga i fas med varandra samt för att gå igenom resultatet av det arbete som gjorts. I praktiken blev det mer än ett gång per vecka som gruppen träffades och det hölls ett väldigt nära samarbete.
4.4. Utveckling
Figur 4.1: Översikt över arbetsflödet.
4.4.1
Agil utveckling
Agil utveckling är en generell beskrivning av en rad olika arbetsmetoder som alla följer ett visst koncept. Termen populariserades av manifestet för Agil systemutveckling[16]. De be-skriver sina prioriteringar som följande.
Individer och interaktionerframför processer och verktyg
Fungerande programvaraframför omfattande dokumentation
Kundsamarbeteframför kontraktsförhandling
Anpassning till förändringframför att följa en plan
Det som dessa koncept har gemensamt är att de beskrivs som väldigt flexibla, där man inte binder sig till en detaljerad plan som är känslig för ändringar. Fokus blir istället att man ar-betar i mindre iterationer, utvärderar och anpassar arbetssättet löpande under arbetets gång. Stort fokus läggs på att ha en nära kontakt med beställaren av projektet samt ett nära samar-bete inom gruppen. Vi har framförallt använt oss av en kombination av Scrum [3] och Kanban [17] under utvecklingen.
Från Scrum användes i första hand konceptet Sprints. Vi hade sprintar på en vecka och började varje måndag med ett Sprint retrospective möte kombinerat med Sprint planning, dvs en planering av kommande veckas sprint samt en sammanfattning av föregående vecka.
Vi använde oss av en Kanbantavla i applikationen Trello, som är en applikation där varje medlem kan fylla i tavlor med aktiviteter. Detta gjorde att vi kunde strukturera upp vem som skulle göra vad samt ha deadlines för när det skulle vara klart, på ett tydligt och överskådligt sätt.
4.5. Testning och kvalitetssäkring
4.4.2
Implementationsspråk
Samtliga gruppmedlemmar hade erfarenhet av Java och därför valdes det språket för im-plementation av TrackApp. Som utvecklingsmiljö användes Android Studio. På en del av de veckomöten som arrangerades under iteration 1 och 2 diskuterades möjligheten att skri-va delar av programmet i C++. Framför allt övervägde gruppen att optimera spårningen av markörer eftersom C++ kom rekommenderat som det snabbare och bättre alternativet. Det förutspåddes dock innebära en del extra kodskrivning och utbildning på grund av den ökade komplexiteten och inlärningskurvan av att kommunicera mellan de två språken, då grunden av applikationen måste vara i Java. Ett strategiskt beslut togs att skriva källkoden i endast Java för att hinna få med den önskade funktionaliteten.
4.4.3
Användargränssnitt
Användargränssnittet utvecklades i ett flertal steg. Till en början skissades ett antal olika strukturval kring hur man skulle navigera runt i applikationen (se figur 4.2). Dessutom val-des vilket del av applikationen som skulle vara startsida. Efter att ett antal förslag hade tagits fram så gick gruppen igenom de olika förslagen och valde det som flest tyckte mest om. Efter det togs multipla alternativ fram för de färger och stilar på bakgrunder och knappar. Des-sa alternativ demonstrerades för kunden där kunden då kunde säga vad de tyckte om våra alternativ samt komma med egna förslag. Deras förslag kring färger implementerades.
4.4.4
Utvecklingsmiljö för Användargränssnitt
Android Studio ger utvecklare ett bra stöd för grafisk utveckling. Vi använde oss således av Layout Editor som är ramverket för grafisk design i Android Studio tillsammans med MPAnd-riodChart för grafritning. Detta eftersom att vi inte använde komplicerade grafiska moduler i utvecklingen av användargränssnittet.
4.4.5
Navigering
En gemensam bild av hur de olika utvecklingsområdena i projektet skulle integreras behöv-des. Dessa områden var framför allt markördetektion, grafritning och layout. En enkel skiss skapades för att beskriva TrackApps funktionalitet och vy-navigering. Skissen användes som utgångspunkt för diskussioner under iteration 1 (se figur 4.2).
4.5
Testning och kvalitetssäkring
Skapandet av tester går till på så sätt att en gruppmedlem väljer att skriva ett test för en del av koden. Medlemmen öppnar en specifik mapp i projektet. Beroende på om testet är ett enhetstest eller ett test där man behöver hela applikationen för att trycka på en knapp eller liknande så finns det varsin mapp. Dessa två mappar genererades automatiskt av Android Studio när projektet skapades.
I den valda mappen skapas antingen en ny klassfil eller så modifieras en existerande be-roende på om testet man skapar är ett nytt test eller ett extra test för ett problem där vi redan har skapat några tester. Sedan skriver man ihop sitt test och ser till att det fungerar mot den nuvarande koden. Fungerar det inte får man granska och se ifall man har skrivit fel i testet eller om det är den nuvarande koden som inte fungerar som den ska. Oavsett vart felet ligger ser man till att fixa det.
Sedan när testet passerar är skapandet av testet klart. Vid nästa Git-push på den grenen kommer detta test att köras tillsammans med alla andra tester som fanns tidigare. Detta beror på att alla tester som ligger under de två specifika mapparna körs automatiskt av ett skript varje gång man pushar på en gren. Detta händer för att vi har skapat ett skript som alla gruppmedlemmar måste köra efter första gången de drar ner projektet på en dator. Detta
4.6. Samarbete med kund
Figur 4.2: Skiss av navigeringen för TrackApp.
skript modiferar en fil som skapades av git som körs innan varje push till att testa alla tester och bara fortsätta om testerna passerar.
Även en del manuella tester har gjorts nämligen kodgranskning vid merge samt under-sökt hur många procent av koden som är kommenterat. Detta för att säkerställa kvaliteten på koden som skrivs samt för att se till att koden var lättläst.
4.6
Samarbete med kund
För att säkerställa att arbetet tillfredsställde kundens önskemål under arbetets gång så såg gruppen till att ha möte med kunden cirka varannan vecka samt regelbunden kontakt via email. Vid dessa möten med kunden så demonstrerades arbetets fortgång och hur produkten utvecklats hittills samt så diskuterade deras åsikter. Kundens åsikter respekteras och används vid all implementation genom hela projektarbetet.
4.7
Versionshantering
Git är det versionshanteringsprogram som använts. Gruppen använde Gitlab för att kunna dela projektet med varandra samt för att lägga krav på merge till master-grenen. Kraven var att det krävdes två gruppmedlemmars godkännande, vilket gavs elektronisk via GitLab. Dessa två skulle dessutom inte ha varit med och utvecklat den specifika grenen. Innan ett godkännande gavs skulle gruppmedlemmarna gå igenom de ändringar som försöker mer-gas och se till att de uppehåller den standard som var satt. Grenar användes för att de olika modulerna skulle kunna utvecklas parallellt samt för att underlätta arbetet för utvecklarna och minska merge-konflikter. Dessutom användes Gits skriptfunktionalitet för att se till att
4.8. Metod för att fånga erfarenheter
alla tester körs innan varje push via pre-push skriptet. Skriptet skrevs så att varje gruppmed-lem enbart behövde köra ett skript som kallades install-hooks.bash en gång i början efter att de hade hämtat ner all kod första gången. Detta skript bytte ut Gits default pre-push skript vilket inte gör något mot ett skript som anropar två metoder som finns i gradle för att köra androidtester.
4.8
Metod för att fånga erfarenheter
Gruppen hade som mål att ha ett möte en gång i veckan där alla medlemmar närvarade utö-ver de handledarmöten som hölls varje vecka. Dessa möten planerades oftast in på måndagar och hade som mål att synkronisera arbetet. Under mötena fick gruppmedlemmar visa upp nya funktioner som de kodat och få återkoppling på dessa. På mötena delades arbetet upp för den kommande veckan fram till nästa möte. Ofta träffades hela eller delar av gruppen fler gånger i veckan men då mer specifikt för att utveckla produkten eller skriva dokumen-tation. Utöver det diskuterades hur arbetet hade gått och hur gruppen kunde ta till vara på den kunskap och erfarenhet som skaffat hittills. Det som diskuterades var de arbetsmetoder som använts och hur gruppmedlemmar arbetade tillsammans. Även den återkoppling som gruppen fått från kunden diskuterades för att komma fram till hur man på bästa sätt kunde leverera en bra produkt och om det fanns utrymme för förbättring.
5
Resultat
Detta kapitel behandlar resultaten av vad som producerats av projektgruppen för projektet TrackApp. Dessa innefattar resultaten vid utvecklingen av produkten samt de dokument som är relaterade till produktens utveckling. Syftet är huvudsakligen att klarlägga resultat som är relevanta i förhållning till frågeställningen.
5.1
Dokument
Här presenteras resultaten utav de dokument projektgruppen har bearbetat under projektets gång.
5.1.1
Förstudie
Material som producerades under förstudien ligger till grund för hur arbetet genomförts. Kravspecifikationen som utformades är det dokument som huvudsakligen dikterat grund-principerna för projektets arbetsprogression [18]. Vi använde oss av use-cases och diskussio-ner inom gruppen för att bygga en uppfattning om vilken information som behövde inför-skaffas.
5.1.2
Systemanatomi
Systemanotomins syfte var att identifiera nyckelfunktioner som systemet behövde och avgö-ra relationer mellan dessa. Vi tog hjälp av systemanatomin vid implementation av funktio-nerna. Systemanatomin kan ses i figur 5.1.
5.1.3
Arkitekturdokument
Produkten dokumenterades i arkitekturdokumentet där viktiga aspekter av dess struktur beskrevs. Dokumentet beskriver de olika vyerna i applikationen och implementationen av dessa.
5.2. Logotyp
Figur 5.1: Systemanatomin
5.2
Logotyp
Under förstudien ritades en logga i det fria bildbehandlingsprogrammet GIMP (The GNU Image Manipulation Program)[19]. Tanken med loggan var att ha en symbol som represente-rade projektet för gruppmedlemmarna. Vid framtagandet var temat att inkludera något som påminde om projektet. Loggan (se figur 5.2) är anpassad för att kunna klistras in i sidhuvudet på de dokument som skrevs utan att ta upp alltför mycket plats.
Figur 5.2: Logotypen för projektet.
5.3
Bildanalys
Spårning av objekt i bild och video använder mönsterigenkänning. Genom en 2D pixelmatris kan ett specifikt sökt mönster urskiljas från detaljer i bilden. Generellt sett innebär det im-plementation av algoritmer som noterar skillnader från en pixel till en annan. Mer specifikt ska skillnader uppvisa kännetecken som klassificeras för det sökta objektet. Det finns ett fler-tal utvecklade algoritmer för mönsterigenkänning med olika angreppssett för hur detta görs men också vad de letar efter.
5.4. Användargränssnitt
5.3.1
Träning av klassificerare
Själva träningen av kaskadklassificerare gjordes med OpenCV’s inbyggda metoder[20]. Här användes 1000 positiva bilder samt 3000 negativa. Positiva bilder innebär bilder där objektet finns med. Dessa bilder var tagna i olika ljus och från olika avstånd. Sedan klipps dessa bilder ut manuellt, man tar alltså bort bakgrunden från bilden. De negativa bilder som användes var 3000 slumpmässiga bilder, både inomhus och utomhus, där objektet inte finns med. Denna träning tog cirka sex timmar.
5.3.2
Alternativa spårningsmetoder
Försök till att skapa en mer exakt spårning av markören gjordes bland annat genom att im-plementera Harris corner detection. Denna algoritm visade sig vara effektiv för att hitta mitt-punkten och kanterna men gav även många falska positiva resultat längst linjerna av mar-kören. För att minimera detta skapades ytterligare ett filter som avgjorde om färgerna kring dessa resultat matchade färgerna på markören. Detta visade sig vara problematiskt då fär-gerna skiljer avsevärt beroende på ljuset som faller på markören. Dessutom blev spårningen signifikant mycket långsammare, spårningen tog upp mot tio gånger längre tid när dessa algoritmer användes.
5.3.3
Spårningssäkerhet
Hur väl markören spåras varierar beroende på ljusförhållanden vid inspelningen. Vid opti-mala förhållanden hittas markören direkt och spåras utan falska detektioner, dessa förhållan-den innebär ett stadigt ljus uppifrån mot en plan bakgrund med starka kontraster som av-skiljer markören från bakgrunden. Innehåller bakgrunden flera tydliga räta vinklar kan även det ge upphop till falska detektioner. Kvantitativa metoder att säkerställa huruvida effektiv spårningen är har däremot inte genomförts.
5.3.4
Filtrering
Eftersom falska positiva resultat kan uppstå från kaskadklassificeraren så behöver detektio-ner genomgå ett filter för att säkerställa att resultatet är korrekt. Det som gjorts i detta projekt är att man använt Hough Lines för att hitta alla linjer inom området för detektionen. Linjerna sorteras sedan baserat på deras lutning och algoritmen approximerar om linjerna utgör ett kors genom att titta på ifall majoriteten av linjerna tillhör de två största grupperna (lutning-arna) och att dessa två är vinkelräta.
5.4
Användargränssnitt
Applikationens grafiska användargränssnitt startar med en huvudmeny (se figur 5.3.a) där tillgång till all funktionalitet utgår.
5.4.1
Android aktiviteter
Utseendet på det grafiska användargränssnittet byggs i Android Studio genom aktiviteter som innehåller grafiska layers där funktionalitet fästs via koden till varje specifikt layer. Varje hu-vudsaklig funktion för applikationen är följaktligen skapad som en egen aktivitet.
Huvudmeny
Applikationen är byggt utifrån en huvudmeny där tillgång till kamera, grafer och inställning-ar finns distribuerat genom rörelseresponsiva knappinställning-ar. Huvudmenyn är skapad med avsikt att följa Image System Nordic ABs färgschema. Exempel kan ses i figur 5.3a.
5.4. Användargränssnitt
(a) Huvudmeny (b) Kamera
Figur 5.3: Skärmbilder av applikationen
Kamera
Kameraaktivtetens grafiska användargränssnitt visar användaren bilden från vad som in-hämtas från kameran på helskärm. Den ritar dessutom ut och spårar markörer som upphittas i bilden så att användaren kan följa dessa i realtid. När användaren börjar filma öppnas mobi-lenhetens egen kameramodul och filmning sker precis som användarna är vana vid. Exempel ses i figur 5.3b.
Extern kameramodul
Gruppen jobbade även på att skapa en extern kameramodul för filmning av video genom Androids API. denna modul ger möjlighet för utökad funktionaliteten vid videoinspelning, så som kontroll av inhämtning av extern data i samband med inspelning och videoinspel-ning med flera synkroniserade kameror. Modulen blev dock aldrig färdig och utelämnades i slutprodukten.
Grafer
Då grafaktiviteten öppnas väljer användaren en inspelad video att utföra spårningen på från internminnet. Efter att en inspelning valts analyseras denna från back-end. Då beräkning-arna är klara visas en bild för videons nuvarande frame. Exempel ses i figur 5.4b. Genom att välja en axel X- eller Y för spårning får användaren upp ett kartesiskt koordinatsystem som skapats av MPAndroidChart som indikerar rörelse av markören med avseende på tiden. Användaren har därefter möjlighet att välja olika punkter på grafen och bilden på videons nuvarande frame uppdateras därefter. Under inspelningen av video från applikationen ville
5.5. Tester
(a) Lista på videos (b) Datavisualisering
Figur 5.4: Skärmbilder av applikationen
vi ha objektigenkänning i realtid. Denna del implementerades i projektet med hjälp av Haar classifiers som beskrivs närmre i appendix E.
5.5
Tester
Testerna delades in i ett antal grupper beroende på vad testerna behandlade och vilken del av projektet som testerna testade. Dessa grupper var Layout-, Bildanalys-, Kvalitets-, System-och Acceptanstester.
5.5.1
Layouttester
Alla layouttester som planerades blev gjorda. Dessa tester testade rotation, skärmsvepningar och knapptryckningar på huvudmenyn i applikationen. Mer specifikt kring rotation testades det att oavsett vilket håll man roterade enheten så roterade aldrig applikationen. Knapptryck-ningstesterna innebar att korrekt aktivitet startades utan att krascha och skrämsvepnings-testet testade att svepningar inte påverkade applikationen på något sätt. Alla dessa tester genomfördes och passerade.
5.5.2
Bildanalystester
Det fanns enbart ett inplanerat bildanalystest och det testet genomfördes aldrig. Testet skulle ha testat att markörer detekteras inom en viss tidsperiod 3 utav 4 gånger.
5.6. Grafritning
5.5.3
Kvalitetstester
Kvaliteten har testats på flertal sätt. Först körs alla tester automatiskt när kod blir pushad på en branch. Sedan går all kod genom en granskning av minst två individer som inte har varit med och skapat koden. Under denna granskning ska individerna gå igenom all kod och se till att de förstår den samt att den uppfyller de kodstandarder och andra kvalitetskrav som sattes när gruppkontraktet skrevs på. Sedan finns ett test som kollar hur många procent av koden som är kommentarer. Det testet lyckades med resultatet att 20 procent var kommentarer.
5.5.4
Systemtester
De systemtesterna som genomfördes var endast informella test utförda av gruppen där de kvalitetskrav som var satta analyserades. Dessa krav var att appen skulle hitta en markör på under tio sekunder, samt att kunna spela in en tio sekunders video på minst 10Hz och sedan visa datan i grafer. Dessa tester uppskattades att vara godkända då båda dessa funktioner klarade kraven.
5.5.5
Acceptanstester
Det planerades och genomfördes ett acceptanstest. Testet genomfördes hos kunden men an-ses vara informellt. Kunden fick då testa applikationen och resultatet blev blandat. De blev glada över att att se hur långt projektet hade kommit men däremot missnöjda med att viss funktionalitet inte hade blivit implementerad. Bland annat att 3D detektion av markören inte blev färdig.
5.6
Grafritning
Kunden efterfrågade funktionalitet för att rita upp grafer i syfte att demonstrera vad markör-detektion kan användas till. Markörmarkör-detektionen ger datapunkter i form av position och tid från vilka annan data kan beräknas. Under förstudien undersöktes möjligheten att rita upp grafer genom att använda OpenGL som har stöd för hårdvaruacceleration[21]. Det övergavs dock under iteration 1 till förmån för grafritningsbibilioteket MPAndroidGraph för att spara tid, vi valde detta bland flera andra alternativ [14, 22]. Biblioteket ges ut under Apache Licen-se Version 2.0. Biblioteket har i skrivande stund över 26000 uppröstningar på GitHub vilket avgjorde valet av grafritningsbibliotek. Jämför detta med HelloChart 6000, WilliamChart 4000 och GraphView över 2000 uppröstningar.
5.7
Gemensamma erfarenheter
Under projektarbetets gång har gruppen samlat mycket erfarenheter om projektarbeten och grupparbete. I detta avsnitt behandlas de erfarenheter vi tillsammans har erhållit. Riskhante-ring har också varit centralt för gruppen eftersom gruppen under arbetets gång blivit av med två gruppmedlemmar tidigt under projektet.
5.7.1
Utbildning
Eftersom gruppen inte hade någon erfarenhet av varken Android eller bildanalys så krävdes en hel del utbildning inom dessa ämnen för att kunna lösa de problem som gruppen stod inför. Det vi fick ut av detta var en grundläggande kunskap av Android och Android studio som användes för utvecklingen. Gruppen fick även kunskaper om grundläggande bildanalys och de olika metoder som kan användas för att detektera olika kännetecken i en bild. Majori-teten av tiden åt bildanalys gick åt att lära sig använda existerande verktyg och metoder för att arbeta med detta på en högre abstraktionsnivå istället för att sätta sig in i hur metoderna
5.7. Gemensamma erfarenheter
exakt fungerade. Detta har gjort att en del funktionalitet kunde implementeras på kort tid. Att inte lära sig förstå dessa metoder lite djupare ledde däremot till att implementationen inte blev optimal. Att sätta sig in i dessa på en mer detaljerad nivå skulle leda till effektivare bildanalys och är någonting att ta med sig till nästa projekt.
5.7.2
Projektarbete
Samtliga medlemmar i projektgruppen har utvecklats inom att jobba i en projektgrupp relate-rat till mjukvaruutveckling. Detta innebär att medlemmarna kunnat tillämpa sina kunskaper som utvecklats under kursen Programutvecklingsmetodikdär gruppen bland annat lärde sig om effektiv versionhantering med olika grenar samt användning av UML-diagram. Gruppen har även fått kunskaper inom agil utveckling samt användandet av applikationer, som t.ex. Trello för att underlätta arbetet. Här har gruppen lärt känna många av de fallgropar som finns i större projektarbeten med en extern kund och kommer kunna förutse många problem bättre framöver.
5.7.3
Riskhantering
Projektgruppen bestod från början av sju personer men innan arbetet startat hoppade en per-son av och sedan ett par veckor in i projektet ytterligare en perper-son. Det ledde till att arbetet med att upprätthålla en kvalitetsplan övergavs och alternativ med mindre arbetsbörda an-vändes för att upprätthålla kvaliteten. Utöver det identifierades fyra risker med projektet. Riskerna bedömdes inträffa med trolighet T enligt skalan låg 1, måttlig 2, hög 3 och mycket hög 4. Riskernas påverkan P på projektets framgång bedömdes enligt skalan katastrofal 4, allvarlig 3, tolererbar 2 och insignifikant 1. Utifrån dessa bedömningar beräknades riskfak-torn R enligt trolighet x påverkan för varje risk. I början av projektet identifierades fyra risker som beskrevs i projektplanen.
Hantering av kvalitet
Då vi inte använde oss av en kvalitetsplan säkerställde vi kvaliteten genom följande: Innan en merge skedde skulle koden läsas igenom och godkännas av två personer. Vi såg till att 15 % av koden bestod av kommentarer samt att vi implementerade automatiserade tester av GUI:t som kördes vid push till branch.
Risk: otillräcklig beräkningskraft
Android smarttelefoner har inte tillräcklig beräkningskraft för att köra bildbehandlingspro-gram såsom OpenCV. Beredskapsplan: ifall det skulle visa sig att android smarttelefoner inte har tillräcklig beräkningskraft kan koden köras på surfplattor istället. I värsta fall finns det en tanke om att lägga beräkningarna på Image Systems AB:s servrar. Alternativt optimera koden. T=2, P=4, R=8.
Risk OpenCV saknar behövliga algoritmer
OpenCV saknar de bildanalyseringsalgoritmer som TrackApp behöver. Beredskapsplan: Vi använder ett annat bibliotek för bildanalys. Till exempel Image Systems egna via deras API. T=1, P=3, R=3.
Risk: tracking modul ej modulär
Utvecklingen av vår tracking-modul är inte modulär i enlighet med kundens efterfrågan samt att modulen ej kan färdigställas. Beredskapsplan: Eftersom att modulen kan lämnas öppen är huvudsaken att denna går att bytas mot kundens egna modul. T=2, P=2, R=8.
5.8. Sammanfattning av individuella delar
Risk: frånvaro på möten
Personer i gruppen närvarar ej vid gruppmöten och/eller handledarmöten. Beredskapsplan: Gruppen tar och pratar med personen i fråga och tar reda på varför personen inte närvarar. T=3, P=2, R=6.
5.7.4
Tidsplanering och tidsbrist
Under projektets gång har gruppen fått god erfarenhet av att både planera och rapportera tid. Vi har närmare deadlines, inlämningar och seminarium fått en indikation på huruvida vi ligger i fas med den planering som gjorts. Detta har haft som konsekvens att gruppen varit tvungen att planera om vid tidsbrist och att vissa delar av projektet inte blev utförda. Exempel på gruppens planering är hur det på veckomötena bestämdes vad som skulle göras under den kommande veckan och vilka som skulle ta ansvar för vilken del för att föra projek-tets arbete framåt. Gruppens behov av att balansera tidsbristen med att leverera den önskade funktionaliteten gjorde att de delar som ansågs ta för lång tid att slutföra lades åt sidan till förmån för det som snabbare kunde slutföras. Mycket av de beslut som togs gjordes efter samtal med kunden. Ett exempel på detta var implementationen av att kunna utläsa grafdata i SI-enheter. Här valde gruppen en enklare och mindre noggrann metod över en mer avan-cerad och tidskrävande med mer precision för att ha någon form av funktionalitet av detta presenterat i applikationen.
5.7.5
Androidutveckling
Alla gruppmedlemmar har under projektarbetet lärt sig mycket om Android-utveckling. Ut-veckling för applikationer är huvudsakligen styrt från GUI. Detta har som konsekvens att programflödet sker asynkront. Det asynkrona programflödet har inneburit vissa problem vid implementation av delar och hantering av dessa har också varit lärorikt i avseende på hur Android-enheter fungerar. Utvecklingen överlag har också givit oss erfarenheter att arbeta med stora existerande bibliotek och hantering av dess dokumentation. Mycket av utveck-lingen krävde att utforska den tillgängliga funktionaliteten i diverse bibliotek för att på bästa sätt kunna implementera de önskade funktionerna.
5.8
Sammanfattning av individuella delar
Här ges en kort sammanfattning av samtliga individuella delar som tas upp i denna rapport.
5.8.1
Alexander Andersson: 3D-Rekonstruktion, en Kortare Abstraktion
Detta bidrag undersöker tillvägagångssätt för att införa djupseende från tvådimensionella bilder. Den förklarar även olika metoder för att genomföra denna övergång och hur en foto-graferad bild representeras matematiskt.
5.8.2
Alexander Basa: Hantering av Icke-Funktionella Krav i
Mjukvaruutveckling
Framtagning av en kravspecifikation är en central del i ett mjukvaruprojekt. Den ger ett kon-kret mål att arbeta mot både under design, utveckling och testning, och har stor nytta för personer, oavsett roll, i utvecklingen. Denna undersökning kommer att titta på den kunskap som finns om icke-funktionella krav och försöka att besvara frågor relaterat till hur dessa bäst hanteras.
5.8. Sammanfattning av individuella delar
5.8.3
Andreas Lindstén: Attitydundersökning av Allmänhetens Inställning till
Datorseende Kamerabevakning
Denna del presenterar en enkätundersökning som undersöker attityder kring datorseende övervakningskameror. Attityderna jämförs med åsikter kring övervakningskameror utan da-torseende. Etiska aspekter av kamerabevakning samt deras brottsförebyggande effekt och användbarhet som bevisföring introduceras.
5.8.4
Markus Loborg: För och Nackdelar med Automatisk Testning i Git
Denna rapport kommer gå igenom några av för och nackdelarna med automatiserade tes-ter med fokus på verktyget Git. Den konstates-terar att för- och nackdelarna är ofta beroende på vilket typ av projekt samt nivå av automatisering man vill ha. Dock är en del av slutsat-serna baserade på åsikter mer än vetenskaplig fakta då det var svårt att hitta källor till alla frågeställningar.
5.8.5
Anton Orö: En Jämförelse av Olika Klassificerare i OpenCVs Bibliotek
För att utföra spårning av objekt i detta projekt så har OpenCV’s inbyggda funktioner an-vänts. Dock upptäckte gruppen tidigt att det var svårförståeligt samt att det inte fanns något tydligt sätt att se ungefär hur lång tid det skulle ta att träna klassificeraren samt vad skill-naden var mellan HAAR-metoden samt LBP-metoden. Denna rapport försöker ge läsaren en översiktlig bild över hur dessa klassificerare fungerar samt vilken metod som ger vilka fördelar.6
Diskussion
I detta kapitel diskuteras och analyseras resultaten samt metoderna för att komma fram till resultaten.
6.1
Resultat
Detta avsnitt diskuterar de resultat som gruppen producerade under projektet.
6.1.1
Dokument
En del av resultatet för projektet var de dokument som gruppen producerade. Här upplev-de samtliga gruppmedlemmar att vissa dokument var bra, men några var onödiga och tog endast tid. Under förstudien upplevde medlemmarna att kravspecifikationen var nödvändig för både kunden samt medlemmarna. Detta på grund av att man tvingades tänka igenom både vad gruppen skulle hinna med samt vad kunden ville ha, man gav också kunden tidigt en indikation om vad som förväntades utföras under projektets gång.
Efter förstudien var det framförallt systemanatomin samt arkitekturdokumentet som ar-betades på. Här upplevde gruppen återigen att dessa dokument gav visst värde för både kund samt grupp. Systemanatomin tvingade gruppen tidigt att tänka igenom strukturen på systemet och gav även kunden en bra översikt av hur systemet är byggt. Arkitekturdoku-mentet bidrog också med detta men även mer djup kunskap i systemet.
Däremot upplevde medlemmarna i gruppen att projektplan samt testplaner endast bidrog med stress samt tidsbrist till projektet. Då arbetet utfördes agilt var det svårt att skapa en projektplan med färdiga aktiviteter med mera. Det var även svårt att hålla testplanen aktuell då gruppen inte hade någon ensam testansvarig. Det man istället hade kunnat göra är att låta gruppens behov leda utvecklingen av dokumenten för att inte ta fram överflödiga dokument som mest konsumerar tid som kunde gått till annat. Även fler gruppmedlemmar hade löst många av problemen.
6.1.2
Bildanalys
Som presenterat i Teori samt Resultat så har bildanalys varit en central del i detta projekt. Här använde sig gruppen av inbyggda verktyg i OpenCV’s bibliotek. De alternativa
implementa-6.2. Vidareutvecklingspotential
tionssätt som finns hade varit att skapa en egen maskininlärningsmetod alternativt kommu-nicera mer med kunden och implementera en lösning som de redan har. Utöver detta finns det få bildanalys bibliotek och liknande, detta på grund av att det vanligaste är att använda sig av OpenCV.
6.1.3
Användargränssnitt
Användargränssnittet som kan ses i figur 5.3 och 5.4 har hög kontrast mellan text och bak-grund vilket ger bra läsbarhet. I aktiviteten med realtidsdetektion av markörer visas en röd ring runt de markörer som hittats vilket tydligt visar att TrackApp har hittat en markör. När en video har filmats backar användaren tillbaka till menyn. Diskussioner hölls om att gå di-rekt till grafaktiviteten efter att en video filmats men den idéen avslogs då det skulle innebära att användaren skulle backa förbi kameraaktiviteten för att komma tillbaka till huvudmenyn efter att en video analyserats i grafaktiviteten. För att demonstrera konceptet bildanalys har grafaktiviteten valts att göras så interaktiv som möjligt genom att göra datapunkterna klick-bara. Vid ett klick visas den bild i videon varur en markör detekterats.
6.2
Vidareutvecklingspotential
Status för projektet i slutskededet var att gruppen lyckades implementera spårning i ett två-dimensionellt koordinatsystem. Dessvärre lyckades vi inte genomföra spårning i koordinater i förhållande till världen, någonting som vi hade sätt som en målsättning. Fler metoder finns för att lösa detta problem. Dessa kan delas in i två kategorier, problem med datahämtning och problem med effektiv markörspårning.
6.2.1
Dataextraktion
Nuvarande hämtar applikationen all sin information från en kamera brygga från Java vid realtidsspårning. Detta gränssnitt skiljer sig från att spela in videor där applikationen öpp-nar den redan befintliga kameraapplikationen för inspelning. Detta är däremot en stor be-gränsning för huruvida vi kan kontrollera vilken typ av data som vi kan registrera. Tillgång att extrahera mer data än den specifika videon har visats avgörande för vissa metoder av 3D-spårning för ytterligare läsning se Appendix A.5.3. Vi hade exempelvis kunnat mäta hur telefonen rört sig mellan varje bild och på så vis spåra via Structure-from-motion (A.5.3). Alter-nativt att vi hade kunnat filma med två kameror samtidigt och på så vis triangulera objektet i realtid (A.5.3). Vi har däremot skapat en passande kameramodul som kan göra möjlighet för att extrahera den data som behövs. Dessvärre har vi inte lyckats få modulen att fungera felfritt för att implementera denna i vår nuvarande applikation. Vi hoppas däremot genom att bifoga denna modul kunna skapa ytterligare värde för kunden.
6.2.2
Markörspårning och prestanda
Applikationen kräver i dagsläget relativt lång tid för att utföra beräkningar enbart för en mar-kör genom Haar klassificerarna. Harris corner detection algoritm för att registrera kanterna och mittpunkten för vår markör skapade också problem med tiotal gånger längre beräknings-tid än utan denna implementation. Metoder för att skapa uppfattning om tredimensionella koordinater kan utföras genom kamerans egenskaper – Kameramatrisen i kombination med flertalet specifika punkter i en bild SolvePnP, detta förklaras noggrannare i Appendix A.5.3. Om dessa punkter kan detekteras på bilden och deras verkliga förhållande till varandra, det vill säga avståndet mellan dessa punkter, är känt kan vi vid varje bild få en uppfattning om rörelser i förhållande till kameran. Problemet för denna metod är däremot att applikationen behöver klara effektiv spårning av flera punkter på markören. Om vi hade lyckats skapa en snabbare spårnings algoritm som dessutom klarar av flera punkter hade vi på så sätt snabbt
