Smart Shopping Cart: Automatisering av handelsprocessen vid fysiska butiker, teknisk innovation

Kandidatuppsats

Civilingenjör datateknik 300hp

Automatisering av handelsprocessen vid

fysiska butiker, teknisk innovation

Smart Shopping Cart

Datateknik 15hp

Halmstad 2018-09-16

Mujtaba Aldebes

“I’m not a tech guy. I’m looking at the technology with the eyes of my customers, normal people’s eyes.” – Jack Ma

Sammanfattning

St¨older och snatteri ¨ar ett stort problem f¨or fysiska butiker, dessutom marknadsutvecklingen f¨or e-handel ¨ar avg¨orande f¨or fysiska butikernas framg˚ang och l¨onsamhet. Allt mer pengar investeras i s¨akerhetsl¨osningar, v¨aktare och personal

M˚alet med den h¨ar kandidat-uppsatsen har varit att utveckla en produkt f¨or ett modern och innovativt smart kundvagn. Den framtagna Smart kundvagnen ¨ar ett hj¨alpmedel som ¨ar b¨attre anpassad efter konsu-menternas behov f¨or att skapa trevligare upplevelse hos fysiska butiker och underl¨attar k¨opprocessen, vilket i l¨angden kan leda till trygga och ˚aterkommande kunder.

Genom att anv¨anda och utnyttja ny teknik tillsammans internetuppkoppling och nya funktioner till ett konkurrenskraftigt pris finns stora m¨ojligheter att s¨alja denna produkt. Kundvagnen anv¨ander sig av bilda-nalys och lastcell som m¨ojligg¨or att kunden inte l¨angre beh¨over manuellt skanna en vara. ist¨allet identifieras varan och registreras n¨ar den placeras i kundvagnen.

Prototypen har j¨amf¨orts och slutsats har dragit att produkten ¨ar ett b¨attre alternativ ¨an existerande pro-dukter f¨or ¨andam˚alet.

Abstract

Thefts and shoplifting is a big problem for local stores, additionally the development of e-commerce is a deciding factor for the success of physical stores and their profitability. An increasing amount of money is being invested in security solutions, guards and other related personnel.

The goal of this Bachelors thesis has been to develop a product for a modern and innovative smart shopping cart. The resulting cart is a tool that is more suitable for the benefit of consumers and their need for a more comfortable shopping experience, it has the benefit of streamlining the shopping process which in turn could attract repeat customers.

Through the use of new technology as well as the Internet and new functions at a competitive price point there is a great opportunity to market this product. The shopping cart uses image analysis and a load cell which alleviates the need for customers to manually scan each article for purchase, instead it is identified and registered as it is placed in the shopping cart.

The prototype has been compared to other solutions and conclusions have been drawn as to the optimality of the product fulfill the purpose.

F¨

orord

Jag ¨ar otroligt glad ¨over att jag har skrivit projektet p˚a egen hand, utan n˚agon direkt koppling till ett f¨oretag. P˚a s˚a s¨att har jag varit fri till att best¨amma och styra projektet ˚at de h˚all jag velat. Detta skapade mer engagemang och vilja att utveckla en ny innovativ produkt. Vilket ¨aven resulterade att jag har l¨art mig v¨aldigt mycket om de delar som ingick i projektet.

Jag skulle vilja rikta ett stort tack till alla som har hj¨alpt till i utvecklingen av produkten, alla som svarade p˚a marknadsunders¨okningen, Almi f¨or att beviljade id´est¨odet och min handledare Tommy Salomonsson f¨or hans hj¨alp och v¨aldigt goda r˚ad. Jag vill ¨aven tacka min examinator Pererik Andersson vid HH.

Projektidentitet

Kandidatexamen i

VT18, Mujtaba Aldebes, H¨ogskolan i Halmstad, IDE

Name Phone number Email Address

Mujtaba Aldebes +46 70-731 38 22 mujald14@student.hh.se

Examiners at the university: Name: Bj¨orn ˚Astrand

Mobile: (+46) 035-16 71 43 Email: bjorn.astrand@hh.se Name: Pererik Andreasson Mobile: (+46) 035-16 76 68

Email: pererik.andreasson@hh.se Supervisor at the university name: Tommy Salomonsson Mobile: (+46) 035-16 74 81 Email: tommy.salomonsson@hh.se

Inneh˚

all

Sammanfattning ii

Abstract ii

F¨orord iii

Begreppsf¨orklaring viii

F¨orkortningar viii 1 Introduktion 1 1.1 Problemformulering . . . 1 1.2 Syfte . . . 1 1.3 L¨osningsf¨orslag . . . 1 1.4 Fr˚agest¨allningar . . . 2 1.5 Avgr¨ansningar . . . 2 1.6 Kravspecifikation . . . 3 1.6.1 Applikationens specifikation . . . 3 1.6.2 Kundvagnens specifikation . . . 4

1.7 Enk¨atunders¨okning . . . 4

2 Bakgrund 7 2.1 Existerande l¨osningar . . . 8

2.2 Varukoder . . . 8

2.2.1 Streckkod . . . 8

2.2.2 QR-kod . . . 8

2.3 Streckkodsl¨asare och skannings teknologier . . . 10

2.3.1 Charge Coupled Device (CCD) . . . 10

2.3.2 Laser streckkodsl¨asare . . . 10

2.4 Databas . . . 10 2.5 Lastcell sensor . . . 11 2.6 Raspberry Pi . . . 12 2.7 Digital kommunikation . . . 13 2.7.1 Datorkommunikation . . . 13 2.7.2 Kommunikationsprotokoll f¨or mikrokontroller . . . 14

2.7.2.1 Serial Peripheral Interface (SPI) . . . 14

2.7.2.2 Inter-integrated Circuit (I2_{C) . . . . 15} 3 Metod 15 3.1 Projektmodell . . . 16 3.2 Utvecklingskort . . . 17 3.3 Backend - server . . . 18 3.4 Databas . . . 20

3.5 Streckkodsl¨asning och m¨onsterigenk¨anning . . . 21

3.6 Lastcell / v˚ag . . . 23

4 Resultat 27

4.1 Server . . . 27

4.2 Streckkodsl¨asning och m¨onsterigenk¨anning . . . 27

4.3 Lastcell/v˚ag . . . 29

4.4 Applikation . . . 31

5 Diskussion 37 5.1 J¨amf¨orelse med existerande l¨osningar . . . 38

5.2 S¨akerhetsaspekt . . . 38

5.3 Milj¨oaspekt . . . 39

5.4 Samh¨allsaspekt . . . 39

6 Slutsats 39

Begreppsf¨

orklaring

Android Studio ¨ar en integrerad utvecklingsmilj¨o, utvecklad av Google, f¨or att utveckla applikationer till operativsystemet Android. Programvaran finns tillg¨anglig f¨or Linux, Mac OSX och Windows. Sida . 24

AsyncTask startas i huvudtr˚aden och k¨ors i separat tr˚ad. Klassen utf¨or stora bakgrundsoperationer och n¨ar uppdraget ¨ar slutf¨ort ˚aterkopplar klassen till huvudtr˚aden och presenterar sitt resultat. Android inf¨orde klassen i avseende att undvika blockering av App-anv¨andningen under tiden. sida . 25

Data Race uppst˚ar om tv˚a eller flera tr˚adar i en process vill komma ˚at samma minnesplats samtidigt, d¨ar minst en av tr˚adarna vill skriva till minnet. Givet att tr˚adarna inte anv¨ander n˚agra l˚as f¨or att hindra andra processer fr˚an att komma ˚at minnet. sida . 20

Master/Slave teknik ¨ar en kommunikationsprotokoll f¨or digitala integrerade kretsar, d¨ar en masterenhe-ten har ensriktad kontroll ¨over en eller flera andra slavenheter. sida. 14

Xamarin ¨ar ett f¨oretag som erbjuder ett cross- platform ramverk, anv¨ander programmeringsspr˚aket C# f¨or att utveckla samma applikation f¨or iOS, Android och Windows UWP-appar. Sida . 24

F¨

orkortningar

I2C Inter-integrated Circuit. 14, 15 CCD Charge Coupled Device. 10 ITU Internationella TeleUnionen. 13 QR “Quick Response. 8

SCL Serial Clock. 14 SDA Serial Data. 14

SPI Serial Peripheral Interface. 14

1

Introduktion

M˚anga fysiska butiker f¨oljer ”l¨agsta prisgarantin” principen, men det r¨acker inte l¨angre f¨or att ”vinna” kunder genom att endast konkurrera om l˚aga priser. Utveckling av Internet har ¨oppnat m¨ojligheterna att handla fr˚an n¨atet. Attityden och tankes¨attet hos dagens generation har d¨arf¨or blivit positivt inst¨alld till n¨athandeln. Det betyder dock inte alltid att man ska bojkotta fysiska butiker och satsa p˚a n¨athandeln. Fysiska butiker m˚aste komma n¨armare, f¨orst˚a och f¨orenkla f¨or sina kunder.

Under projektets g˚ang kommer en innovations produkt att tillverkas, smartare sj¨alvscanningskundvagn (Smart Cart), f¨or att underl¨atta vardagshandel f¨or alla butikshandlare, dessutom fr¨amja kundlojalitet till fysiska butiker. Teknikens huvudfokus ligger i att produkten skall hantera all teknik relaterad till handeln, d¨ar kundens enda uppgift ¨ar att l¨agga ¨onskade varor i vagnen f¨or att sedan vara klar med sin handel.

Produkten underl¨attar f¨or kunden och g¨or ink¨opet smidigare och roligare. Samtidigt ¨ar produkten po-sitivt f¨or butikerna. Eftersom produkten ger ett positivt intryck av butiken samt resulterar till n¨ojdare och ˚aterkommande kunder. Ut¨over l¨attnaden som tekniken erbjuder s˚a f¨orebygger systemet snatteri eftersom allt registreras och kontrolleras. Kontrolleringen sk¨ots av en avancerad algoritm som uppt¨acker fusk och svarar med varierande indikeringslampor.

Kort sagt, en l¨osning som ger fria h¨ander och mycket roligare shoppingupplevelse.

1.1

Problemformulering

Smarta kundvagnar ¨ar ett hj¨alpmedel f¨or de fysiska butiker som vill ¨overleva den r˚adande successiva handels ¨

overg˚ang till n¨athandel. Fler och fler kunder s¨oker sig till n¨athandel, d˚a de inser l¨attnaden och bekv¨amligheten som n¨athandeln erbjuder. ¨Overg˚angen gynnar inte fysiska butiker och s¨atter fr˚agan om dess existens aktuell och i fokus.

Under perioden mars-april ˚aret 2017 gjorde ”HUI Research” en unders¨okning[1] f¨or att utreda st¨older och svinnets storlek under ˚aret innan, 2016, hos Svensk handels medlemmar. Rapporten presenterade det kriminella snatteriet uppgick till 7.9 miljarder kronor, allts˚a en ¨okning med 1.8 miljarder kronor (31 procent) fr˚an tidigare unders¨okning, ˚ar 2013. Dessutom presenterade rapporten att administrativt svinn i from av bokf¨oring, felv¨axling och annat m¨anskligfel uppgick till 4.1 miljoner kronor.

Detta skadar butiker negativt dessutom visar statistiken ingen f¨orb¨attring till problemet i framtiden. D˚a fler och fler anv¨ander sj¨alvbetj¨aningssystem, vilket i sj¨alva verket f¨orenklar snatteriet enligt flera rapporterade incidenter.

1.2

Syfte

Syftet med denna kandidatexamen ¨ar att framst¨alla en ny innovativ kundvagn som skall vara tillg¨anglig vid fysiska butiker (se fig 1). Id´en ¨ar att produkten skall underl¨atta f¨or alla butikshandlare genom att g¨ora deras handel l¨attare, roligare och mycket smidigare. Detta genom att utf¨ora en marknadsanalys och kundunders¨okning f¨or att extrahera vad kunderna vill ha implementerad i projekt. Dessutom skall rapporten ha en f¨ordjupningsdel av kommunikation f¨or att s¨akerst¨alla att kommunikationen mellan klienterna sker felfritt. D¨arefter redovisa mitt arbete som f¨orst¨arks utifr˚an analys och resultatet.

1.3

L¨

osningsf¨

orslag

Projektet kommer delas in i fyra hanterbara huvudgrupper d¨ar huvudgrupperna ¨ar som f¨oljande:

Streckkodsl¨asning ¨ar en viktig del i projektet, den har i uppgift att skanna varornas streckkod f¨or att senare registrera de produkter som b˚ade placeras och togs bort fr˚an vagnen. Dessutom skall Feature Matching[2][3][4] till¨ampas f¨or att verifiera att den skannade streckkoden tillh¨or en registrerad f¨orpackning hos kunden.

Integrerad v˚ag kommer anv¨andas f¨or att v¨aga vagnens nettovikt vid vikt¨andring. V˚agstationen anv¨ands som extra s¨akerhet, kontrollerar och f¨orebygger fusk (vid de fall att kunden l¨agger oskannade varor). Vikten

j¨amf¨ors med den totala summan av alla skannade varor registrerade i servern. Vid fusk kommer indikerings-lampan att lysa r¨ott, gr¨ont om inget fusk registrerad och gult under behandlingsprocessen.

Sk¨armen har stor betydelse d˚a den skall redovisa placerade varor, totalpris, ink¨opslista och m.fl. Mer specifikt en Android Applikation och eventuellt till¨aggsfunktioner.

Serven implementeras f¨or klienterna i vardera Raspberry Pi 3 Model B. Servern och databasen imple-menteras f¨or att ett informationsutbyte ska kunna ske mellan de olika enheterna samt produktregistrering. Dessutom f¨or att h˚alla en ¨oversikt eller statistik ¨over vilka produkter som har k¨opts.

Figur 1: F¨orsta skiss ¨over kundvagnen

1.4

Fr˚

agest¨

allningar

Den huvudsakliga fr˚agest¨allningen som denna rapport ¨amnar att unders¨oka och besvara vetenskapligt samt utf¨orligt ¨ar f¨oljande:

1. ¨Ar det m¨ojligt att utveckla produkten, med f¨oreslagna verktyg och enligt specifikationen? 2. Kan man exkludera v˚agen och f˚a lika s¨akert system?

3. Beh¨ovs produkten j¨amf¨ort med liknande produkter?

1.5

Avgr¨

ansningar

Projektet kommer vara helt beroende av sin egen h˚ard- och mjukvara f¨or att uppvisa systemets funktionalitet. Detektera, skanna och validera r¨orliga f¨orem˚al ¨ar en utmanande uppgift. Dessutom med tidsramen, sexton veckor, finns det inte tid att skriva en optimerad kod. D¨armed kommer f¨oljande begr¨ansningar att till¨ampas:

1. Objekt vikt ¨ar begr¨ansad till lastcellens uppl¨osning och noggrannhet. 2. Systemet ¨ar avgr¨ansat till endast f¨orpackningar (statisk design). 3. Enkel och stilren grafiskt gr¨anssnitt p˚a applikationen.

4. Val av komponenter och programvara ¨ar begr¨ansade av projektets budget. 5. Projektet behandlar inte betalningsprocessen.

1.6

Kravspecifikation

Vilka och vems behov skall tillfredsst¨allas?

Eftersom examensarbetet ¨ar skrivet f¨or att tillverka en produkt baserad p˚a min egen id´e och tankar, ¨ar jag d˚a b˚ade projektbest¨allaren och projektansvarig. D¨arav ¨ar det mina behov som skall tillfredsst¨allas i f¨orsta hand med h¨ansyn till examinatorns krav samt till¨agg av handl¨aggaren.

Hur vet du att din specifikation ¨ar bra?

En bra specifikation av en projektuppgift ¨ar om den kan delas upp i flera mindre och mer hanterbara delar och s¨attas ihop till ett fungerande koncept. Tillsammans med de angivna begr¨ansningar ¨ar det en stabil grund f¨or att examensarbetet komma i m˚al inom tidsramen som ¨ar avsedd.

Beskrivning av den ¨onskv¨arda produkten och dess anv¨andningsomr˚ade:

Produkten skall skanna alla varor som b˚ade placeras och tas bort fr˚an kundvagnen, v¨aga vagnen f¨or att verifiera att allt som finns i vagnen ¨ar registrerad samt att det inte f¨orekommit n˚agot fusk. Vid fusk/fel r¨od indikeringslampa ska lysa eventuellt gr¨ont. Det skall finnas en sk¨arm(Applikation) som redovisar totala summan och alla registrerade varor i vagnen.

Produktens prestanda, kapacitet:

Prestandan och kapaciteten begr¨ansas till den h˚ardvara som projektet anv¨ander.

1.6.1 Applikationens specifikation M˚att, vikt, utsl¨app, bullerniv˚a m.fl:

Inga krav f¨or m˚att och vikt men produkten skall vara milj¨ov¨anlig och anv¨ander endast f¨ornybar energi. Bullerniv˚an f˚ar inte ¨overstiga niv˚an att den uppfattas som st¨orande.

Krav p˚a ing˚aende s¨akerhetssystem: Ospecificerad, vidareutveckling.

Driftskostnadskrav Ospecificerad

Vilka krav som st¨alls p˚a dokumentation:

Kod och koddokumentation skall f¨olja kodkonventioner f¨or det spr˚ak som systemet skrivs i. Enkel funktions-beskrivning samt beskrivande variabelnamn att en annan kunnig programmerare skall kunna f¨orst˚a koden utan vidare problem. Rapporten skall f¨olja de krav som examinatorn angivit.

Volymer vad avser antal eller timmar och tider f¨or leverans:

leveranstiden ¨ar avsedd till vecka 20 (slutseminarium avsedd f¨or denna kandidatexamen) Kostnadsramar:

Systemet kommer inte s¨aljas till privatpersoner utan till fysiska butiker eller branscher som h˚aller p˚a med packning t.ex. inom e-handel (f¨or b¨attre ¨oversikt samt hindrar att l¨agga oskannad artikel i vagnen). Preli-min¨ara kostnader f¨or prototypen:

• Raspberry pi 349 kr

• Raspberry Pi-kamera 249-350 kr • Last cell 99 kr

• F¨orst¨arkare(HX711) 112 kr • RGB dioder och ledare 60-100 kr • Sk¨arm 0 kr

Systemet kan implementeras p˚a butikens vagnar alternativt tillkommer kostnaden f¨or en ¨onskad vagn. Kost-naden f¨or en sk¨arm och batteri tillkommer.

1.6.2 Kundvagnens specifikation Funktionella krav

• Lista upp alla produkter som finns i kundvagnen • Ange den totala summan f¨or produkterna • Skanna och visualisera ink¨opslista

Generella krav

• Applikationen begr¨ansas till endast Android. • Presentera registrerade varor i vagnen.

• visualisera ink¨opslista och markera k¨opta varor. Presentation

• Mobilapplikationen ska utifr˚an observationer visa en meddelande vid tekniskt- eller kommunikationsfel. S¨akerhet

• Mobilapplikationen ska inte lagra eller logga personuppgifter eller k¨anslig information

1.7

Enk¨

atunders¨

okning

F¨or att kunna besvara och senare diskutera grundfr˚agan: huruvida produkten kan underl¨atta butikshandeln gjordes en marknadsunders¨okning. Tv˚a identiska formul¨ar skickades till olika m˚algrupper, f¨or att f˚a st¨orre p˚alitlighet. Nedan presenteras enk¨atresultat med vag analys fr˚an marknadsunders¨okningen.

Den ena enk¨aten skickades till mina v¨anner(V) och bekanta medan den andra sl¨apptes fri i sociala-medier(S). Som grundprincip kommer resultatet att presenteras i f¨oljande struktur. Enk¨atresultat fr˚an den frisl¨appta enk¨aten(S) kommer ligga p˚a v¨anstersidan och enk¨atresultat fr˚an mina v¨anner(V) och bekanta p˚a h¨ogersidan.

Figur 2: Marknadsunders¨okning - K¨on och ˚alder (sociala-medier(S) v¨anster, V¨anner(V) h¨oger) Man ser en tydlig ˚aldersvariation f¨or S medan klar majoritet bland 21-30 ˚aldriga i resultatet fr˚an V (fig 2). K¨onsf¨ordelningen spr˚akar att m¨an kanske ¨ar mer villiga att svara p˚a min enk¨at ¨an vad kvinnor ¨ar.

Figur 3: Marknadsunders¨okning - fysiska butiker vs Online samt ifall konsumenter anv¨ander snabbkassa? (sociala-medier(S) v¨anster, V¨anner(V) h¨oger)

Statistiken fr˚an fig 3 ser n¨astintill vad jag hade f¨orutsp˚att. Enligt statistiken ¨ar ungdomarna(V) hela 16.2% mer ben¨agna att anv¨anda snabbkassor och sj¨alvscanning ¨an ¨aldre personer(S). Statistiken talar ¨aven f¨or att folk fortfarande butikshandlar mer ¨an n¨athandlar och anv¨ander g¨arna sj¨alvscanning/sj¨alvutcheckning n¨ar de har m¨ojlighet. Framf¨or allt ¨ar det mer intressant hur ungdomarna(V) ¨ar mer ben¨agna att anv¨anda hj¨alpsamma produkter f¨or att det ska g˚a snabbare och smidigare vid butikshandel. Vilket ¨ar precis projektets huvudm˚al och vad detta projektet syftar p˚a.

Figur 4: Marknadsunders¨okning - vad kunder anser vara jobbigt med butikshandel (sociala-medier(S) v¨anster, V¨anner(V) h¨oger)

G¨allande vad grupperna anser vara jobbigt med butikshandel, ¨ar b˚ade grupperna enade om att det ¨ar job-bigt, tr˚akigt och tar l˚angtid vid utcheckningen, 71.2% f¨or de ¨aldre(S) och 58.5% f¨or ungdomarna(V). Dess-utom f¨orst¨arker statistiken en av funktionerna som kommer implementeras, n¨amligen synka och visualisera k¨oplistan sk¨armen.

2

Bakgrund

Konsumenters k¨opvanor f¨or¨andrades genom ˚aren d¨armed ser butikerna annorlunda ut. Den stora fr˚agan ¨ar om ¨

ar p˚a v¨ag mot sin d¨od? Att handla ¨ar en grundl¨aggande n¨odv¨andighet, d¨ar de flesta handlar intill dagligen. I den r˚adande tiden ¨ar butikshandel det traditionella s¨attet att handla[5]. Med den v¨axande n¨athandeln b¨orjar man redan m¨arka att trenden ¨ar under f¨or¨andring [6][7]. I Sverige har n¨athandelns oms¨attning v¨axt fr˚an 14.3 miljarder under 2006 till ungef¨ar 67.7 miljarder kronor ˚ar 2017. Med andra ord ¨okade oms¨attningen fyra g˚anger p˚a tio ˚ar och med fortsatt ¨okning. Samt rekord¨okning p˚a 9,8 miljarder kronor mellan 2016 och 2017 [6].

Figur 5: oms¨attningen i elektronik och total e-handel.

F¨ordelarna med e-handel ¨overstiger nackdelarna[8] och allt fler kunder b¨orjade handla p˚a n¨atet. Vid j¨amf¨orelsen av e-handel med butikshandel r˚ader det skillnad i bekv¨amlighet och flexibilitet [6][9]. Fysiska butiker kommer med flera begr¨ansningar som kunden f˚ar anpassa sig efter, t.ex. begr¨ansningen ¨ar det faktum butikens ¨oppettider. Det kan vara jobbigt och stressfullt att passa tiden efter jobbet, r¨oda dagar eller av rad olika andra anledningar[5]. P˚a n¨atet finns inte dessa begr¨ansningar, butikerna har ¨oppet dygnet runt, surfa in p˚a butiken mitt p˚a natten som fr˚an kontoret[8].

En annan f¨ordel ¨ar att n¨atbutiker har mycket st¨orre lager och d¨armed st¨orre sortiment[9]. D¨arf¨or ¨ar det troligt att skicka stora best¨allningar och f˚a det hemlevererat. Samt att det ¨ar billigare att handla p˚a n¨atet i j¨amf¨orelse med butiker. Anledningen ligger i att n¨atbutiker har en br˚akdel av driftkostnaderna f¨or fysiska butiker, exempelvis billigare lokalhyra och ingen stor m¨angd personal som kostar i l¨onekostnader[9]. F¨or n˚agra ˚ar sedan var det ingen id´e att handla eller j¨amf¨ora n¨athandel med butikshandel eftersom n¨atbutiker var kraftigt begr¨ansade b˚ade vad det g¨allande produkter, kategorier och tillg¨anglighet. Men idag har st¨allningen v¨ant, nu kan man handla allt ifr˚an syn˚al till flygbiljetter lika enkelt som mat och kl¨ader. ¨Overblicken ¨over k¨opet blir ocks˚a helt annat p˚a n¨atet, b¨attre ¨oversikt i ”kundvagnen” och smidigt att l¨agga till varor som att ta bort fr˚an ”kundvagnen”. Dessutom ¨ar det smidigt att l¨asa och j¨amf¨ora varor fr˚an olika n¨atbutiker fr˚an sin dator, mobil eller surfplatta[8].

Allt fler kunder v¨aljer att handla Online och butikshandeln ¨ar under konstant f¨orminskning, faktum att det tar l¨angre tid att leverera varor till konsumenten f˚ar m˚anga att ˚aka och handla fr˚an fysiska butiker[8]. Kunder v¨aljer fortfarande fysiska butiker ¨over Online handel av anledningen att f˚a varorna direkt i handen efter avslutad handel[8]. ¨Aven det ¨ar under utveckling, hemk¨orningen ut¨okas och n¨atbutiker kanske levererar direkt till d¨orren efter avslutad n¨athandel[7]. Pl¨otsligt ¨ar vi inne p˚a en ekonomisk fr˚aga, alla ¨ar inte lika villiga att betala extra f¨or att f˚a sina produkter hemk¨orda.

Men att handla vid fysiska butiker har fortfarande sin unika upplevelse, att handla till exempel kl¨ader ¨ar f¨or m˚anga en n¨ojesaktivitet. Speciellt f¨or den senaste generationen som f¨oredrar att handla i aktivitetssyfte.

”Att handla p˚a internet medf¨or flera risker. N˚agon kan ta dina kontouppgifter och du kan bli lurad p˚a den vara eller tj¨anst du k¨opt.” - Polisen.se

Det finns alltid en oro att bli lurar p˚a sina pengar[8], men dagens betalningsalternativ ¨ar mycket avancerade och krypterade, d¨armed p˚alitliga att en konsument inte beh¨over oroa sig f¨or bedr¨ageri eller bankkonto intr˚ang[10].

2.1

Existerande l¨

osningar

Amazon GO[11] ¨ar den f¨orsta butiken som inte har m¨ansklig interaktion med konsumenter vid butikshandel. Konsumenter anv¨ander Amazon Go-app och skannar en framtagen QR-kod f¨or att komma in i butiken. D¨ar en sofistikerad teknik sp˚arar konsumentens ink¨op, samt till˚ater de ta ¨onskade varor och l¨amna butiken utan en fysisk kassa. D¨arefter debiteras Konsumenten automatiskt samt skickar en notis med kvittot i applikationen. F¨ordelarna med Amazon Go, likt id´en bakom detta projektet, ¨ar att eliminera kostnaden f¨or kassapersonal med hj¨alp av en algoritm som sk¨oter de tekniska detaljerna.

Amazon Go anv¨ander datorseende (Computer vision), sensorfusion (Sensor fusion) och djupinl¨arning (Deep learning)[12] tillsammans med lastceller. Alla hyllor ¨ar digitaliserade med vikten av alla registre-rade artiklar tillsammans med ett stort antal kameror i taket som registrerar allt konsumenten tar. En del av f¨orpackningarna ¨ar utrustade med koder f¨or att underl¨atta identifieringen hos kamerorna, n¨ar ori-ginalf¨orpackningarna ¨ar samst¨ammiga.

Sj¨alvutcheckning och sj¨alvskanning[13]

Med hj¨alp av sj¨alvutcheckning och sj¨alvscanning f˚ar kunden m¨ojligheten till sj¨alvhj¨alp och ¨ar sj¨alvst¨andighet under handelsprocessen. Vid anv¨andning av sj¨alvscanner skannar konsumenter alla k¨opta produkter f¨or att sedan l¨agga in den i vagnen. Vid avslutad handel g˚ar konsumenten tillsammans sin vagn till en betalnings-station f¨or att betala och avsluta sitt k¨op. Vid sj¨alvutcheckning skannar konsumenten alla k¨opta produkter vid betalningsstation. I de moderna sj¨alvutcheckning har en v˚ag integrerats s˚a att konsumenten kan v¨aga och v¨alja l¨osvikt, t.ex gr¨onsaker.

2.2

Varukoder

Streckkoder bidrar till snabbare och s¨akrare informations¨overf¨oring, speciellt viktig f¨or varudistributionen [14]. Med hj¨alp av streckkoder kan artiklar identifieras, administreras och sp˚aras. Produkter f¨oljer en standard streckkodsmarkering som ¨ar gemensam f¨or alla leverant¨orer[14]. P˚a s˚a vis uppn˚as st¨orsta m¨ojliga effektivitet och s¨akerhet, vilket underl¨attar f¨or konsumenten att verifiera ink¨opta produkter[14].

2.2.1 Streckkod

GTIN (Global Trade Item Number, GS1-artikelnummer) anv¨ands till att dela unika artikelnummer f¨or varje artikel, p˚a s˚a s¨att f¨orhindras f¨orv¨axlingen med varandra[14]. De vanligaste streckkoderna f¨or att ¨overf¨ora GTIN ¨ar EAN-13 (European Article Numbe nummer)[14]. Standaren best˚ar av 13-siffror men lagras med 14 nummer i databasen, genom att inkludera den inb¨addade ”0:an”[15][14]. Med hj¨alp av denna str¨ang kan man utl¨asa f¨oljande information om produkten, landsnummer, tillverkarens eller import¨orens-id och produkt-id[14][16].

Streckkodssystemet anv¨ander sig av det bin¨ara talsystemet, dvs att streckkoderna skrivs i talkombinatio-ner best˚aende av nollor(vita streck) och ettor(svarta streck), vilket ocks˚a beskriver streckkodens struktur[16]. Det m¨ojligg¨or skrivandet av kod-kombinationer representerade siffrorna mellan noll och nio. Vidare indikerar breda streck, att det st˚ar flera av samma siffra, i f¨oljd, som f¨argen representerar[16].

2.2.2 QR-kod

“Quick Response (QR) kod ¨ar en tv˚a dimensionell streckkod[17]. F¨ordelen med Qr-kod ¨ar bland annat m¨angden data som g˚ar att lagra, eftersom den lagrar information b˚ade vertikal och i horisontell riktning[17].

Dessutom l¨asning av det lagrade informationen utan att komma ˚at en databas, till skillnad fr˚an streckkoder (Kap 2.2.1[18]).

Funktionen ¨ar i princip detsamma som en vanlig streckkod, att lagra information. Dock skiljer det i att man enkelt kan generera en QR-kod utan att vara f¨oretagskund, vilket man beh¨over vara f¨or en en-dimensionell streckkod. Man kan generera en egen QR-kod enklast genom att bes¨oka en sida som genererar en QR-kod, skriva den information man vill lagra och trycka sig vidare till att skapa en[17]. Qr-kod ¨ar inte m¨anskligt l¨asbar[17]. D¨arf¨or beh¨ovs ett system som kan avl¨asa den inb¨addad informationen (en mobilkamera tillsam-mans med en applikation, Qr-l¨asare)[18][17]. QR-koden leder kunden vidare och betydligt snabbare till en ¨

onskad m˚al[17], vilket g¨or att tekniken lever upp till sitt namn, ”Quick Response”.

Figur 6: Struktur av en QR-kod[19][20]

1. Positioneringsmarkeringar: till˚ater att en QR-l¨asare att identifiera och fastst¨alla r¨att orientering 2. Justeringsm¨onster: anv¨ands vid h¨oga lager av QR-kod, f¨or att hj¨alpa med orienteringen av

QR-koden.

3. Storleksbest¨ammning: Varannan svart och vit rumsenhet, beskriver data-matrisstorlek. Med hj¨alp av dessa rader best¨ammes hur stor datmatrisen ¨ar

4. Versionsinformation: beskriver vilken version (1-40) som QR-koden anv¨ander sig av.[19]

nuvarande QR-kod. Feltoleransen till˚ater att QR-koden kan l¨asas p˚a information trots f¨or¨andring, se fig 6.

6. Data: inneh˚aller lagrad information(data) i 8-bitars format.

7. Ram: ett avst˚and f¨or att skilja QR-koden fr˚an annat. Helst ska ramen ha samma f¨arg som den enhetsrummen i data, f¨or att f¨orb¨attra skanningen.

2.3

Streckkodsl¨

asare och skannings teknologier

2.3.1 Charge Coupled Device (CCD)

Den typen av streckkodsl¨asare anv¨ander en Charge Coupled Device (CCD) chip (kamera-sensor) som ¨ar en elektrisk komponent f¨or att skapa en bild av skannade objekt f¨or att antingen lagra den information digitalt eller transportera datan i form av elektriska pulser [21]. Vilket har en likhet, egenskapsm¨assigt, till en digitalkamera att den lagrar en bild av ett objekt. CCD-enheten omvandlar denna optisk bild till elektrisk signal som anv¨andaren kan behandla programmeringsm¨assigt f¨or att inh¨amta inb¨addad information fr˚an streckkoden. F¨ordelen med denna skannings-variant ¨ar att den ¨ar billigare j¨amf¨ort med andra enheter. Mest n¨amnv¨art CCD-teknik har snabb skannings-frekvens och har h¨og noggrannhet men nackdelen ¨ar att den har en kort r¨ackvidd 10cm, j¨amf¨or med laserskanner eller digitala-kameror. Vilket ocks˚a ¨ar d¨arf¨or CCD-tekniken inte kommer implementeras h¨ar, d˚a detta projekt kr¨aver l¨angre skannings r¨ackvidd

2.3.2 Laser streckkodsl¨asare

De flesta streckkodsl¨asare ¨ar uppbyggda huvudsakligen av tre komponenter, belysningssystem (illumination system), lasersensorer och en avkodare. Den anv¨ander r¨orlig laserstr˚ale f¨or att belysa streckkoden och en mottagande fotocell f¨or att lagra reflekterande ljus. Generellt skannar en lasersensor streckkoden (de vita och svarta strecken) genom att belysa p˚a streckkoden med hj¨alp av ett belysningssystem (svepande laserstr˚ale). Sensorn i skannern detekterar det reflekterande ljuset och genererar en analog signal som sedan skickas till avkodaren. Avkodaren tolkar signalen, validerar signalen med hj¨alp av kontrollsumman och omvandlar den till text (som ¨ar inb¨addad).

laserskanning av streckkod har h¨og noggrannhet och dessutom l¨asa t¨atare streckkod till skillnad fr˚an andra teknologier.

2.4

Databas

Relationsdatabaser ¨ar f¨or n¨arvarande den mest utbredda typen av databaser [22]. Ist¨allet f¨or att spara informationen i en enda stor tabell[23] delar man informationen (data) i organiserade tabeller (relationer). D¨ar varje tabell ¨ar uppbyggd av n-kolumner (f¨alt) som representerar unika data-typer och m-rader (record) som inneh˚aller all data som ¨ar relaterad till tabellen i fr˚agan [24]. Unika nycklar och fr¨ammande nycklar kan man skapa relationer mellan ¨onskade tabeller.

Nackdelen med relationsdatabaser ¨ar att de oflexibla, vid de fall d¨ar schemat m˚aste ¨andras p˚a grund av konstruktioner i den underliggande applikationen. Relationsdatabas kan inte lagra information som inte kan ˚ask˚adligg¨oras eller inte l¨angre passar in i tabeller: bilder, video eller musik. F¨or att hantera s˚adana data har det bildats en annan databas-typ, NoSQL [25][26]. Att NoSQL ger m¨ojligheten att lagra bilder g¨or den anv¨andbar i detta projekt, eftersom projektet behandlar bildanalys.

Med tanke p˚a att det ska finnas en relation mellan varorna i vagnen och butikens alla varor (en central databas) m˚aste NoSQL kombineras med en relationsdatabas.

2.5

Lastcell sensor

(a) SparkFun’s HX711 Amplifier bre-akout board

(b) Kopplingsschema f¨or Wheatstones brygga - bild fr˚an Wikipedia

Figur 7: Huvudkomponenter som anv¨ands f¨or att bygga en v˚ag - bild fr˚an sparkfun.com.

En lastcell ¨ar en kraftsensor som omvandlar deformationen av ett material till en elektrisk signal[27]. Den vanligaste typen av lastcell anv¨ander balkteori, deformation i en balk under b¨ojning, f¨or att leverera mekanisk sp¨anning[27]. Genom att montera tr˚adt¨ojningsgivare p˚a en balk och balken uts¨atts f¨or en b¨ojning, ¨andras resistansen i givarna och oms¨atter resistansf¨or¨andringen till elektriskt signal[27]. Tr˚adt¨ojningsgivaren best˚ar av antingen en liten ledare eller folie, som ¨ar uppbyggd i ett rutm¨onster s˚a att det finns en linj¨ar f¨or¨andring av elektrisk resistans n¨ar kraft appliceras i en specifik riktning[27]. Med andra ord tr˚adt¨ojningsgivaren uts¨atts f¨or en f¨orl¨angning eller f¨orkortning och genom att m¨ata resistansf¨or¨andringen kan vi f˚a en uppfattning om hur mycket och vilket h˚all materialet b¨ojs.

Wheatstones brygga[28], fig ??b, ¨ar en elektrisk krets med tre k¨anda och ett ok¨ant motst˚and kopplad ¨over en galvanometer f¨or att ber¨akna det ok¨anda motst˚andet med h¨og noggrannhet.

F¨orst anv¨ands Kirchhoffs f¨orsta lag (KCL) f¨or att hitta str¨ommarna vid nod B (eq 1) och D (eq 2):

I3− Ix+ IG = 0 (1)

I1− I2− IG= 0 (2)

D¨arefter anv¨ands Kirchhoffs andra lag (KVL) f¨or att ber¨akna sp¨anningen ¨over ABD (eq 3) och BCD (eq 4):

(I3∗ R3) − (IG∗ RG) − (I1∗ R1) = 0 (3)

(Ix∗ Rx) − (I2∗ R2) + (IG∗ RG) = 0 (4)

Fr˚an eqkvation 3 och 4 ocg givet att kretsen ¨ar balanserad IG = 0 f˚ar vi f¨oljande eq:

Rx=

R2∗ I2∗ I1∗ R3

R1∗ I1∗ Ix

(5) vidare kan vi f¨orminska eq 5 fr˚an f¨orsta lagen eq 1 och 2, I3= Ix och I1= I2:

Rx=

R3∗ R2

R1

Med vid de fall d¨ar alla motst˚and och sp¨anningen Vin i sp¨anningsk¨allan ¨ar k¨anda, kan man ber¨akna

sp¨anningen ¨over bryggan Vg genom att best¨amma sp¨anningsdifferensen ¨over b¨agge sp¨anningsdelarna:

VG= Rx R3+ Rx ∗ Vin− R2 R1+ R2 ∗ Vin (7) Efter f¨orenkling: VG =  R_x R3+ Rx − R2 R1+ R2  ∗ Vin (8)

Wheatstones brygga anv¨andas i det f¨oreliggande projekt ber¨akna resistansf¨or¨andringen fr˚an lastcellen, ef-tersom lastcellens utsignal ber¨aknas utifr˚an sm˚a resistans f¨or¨andringar. Utsignalen fr˚an lastcellen f¨orst¨arks med hj¨alp av f¨orst¨arkaren Hx711[29], figur ??a, innan utsignalen skickas till Raspberry Pi. Vidare demon-strerar figur 8 en lastcell med fyra tr˚adgivare, vilket resulterar att utsignalen ¨ar fyra g˚anger st¨orre.

(a) Fyra tr˚adt¨ojningsgivare kopplade till Wheatstones brygga - bild fr˚an allaboutcircuits

(b) Grafisk representation vid t¨ojning och hoptryck-ning av r˚adgivare vid tillsatt kraft

Figur 8: Huvudkomponenter som anv¨ands f¨or att bygga en v˚ag - bilder fr˚an sparkfun.com.

2.6

Raspberry Pi

Raspberry pi ¨ar en enkortsdator som var utvecklats av det brittiska f¨oretaget Raspberry Pi Foundation1, kraftfull, och billig samt i grunden var utbildningsorienterad dator. F¨or att uppmuntra ’unga’ att engagera sig och utveckla intresse f¨or programmering och datavetenskap[30]. Nu har den ett stort anv¨andningsomr˚ade och anv¨ands till m¨angd olika projekt, t.ex. i Bagage Sp˚arningssystem[31], realtids igenk¨anning av k¨anslouttryck[32] och andra system d¨ar man kan beh¨ova en liten dator[33]. S˚a l¨ange man inte f¨orv¨antar sig riktigt h¨og pre-standa (intensiv ber¨akningsm¨assig programvara). Alla modeller av Raspberry pi ¨ar kompletta och kraftfulla minidatorer. Dock ¨ar de inte j¨amf¨orbara med de stora avancerade datorerna i fr˚agan om prestanda. En Raspberry Pi inneh˚aller en processor, grafikkort, RAM-minne och kontakter f¨or externa enheter. Raspberry Pi fungerar p˚a samma s¨att som en vanlig dator, som kr¨aver ett tangentbord, datormus, displayenhet och str¨omf¨ors¨orjning(micro USB-kontakt) f¨or hantering av enheten (bortsett fr˚an att koppla upp sig via Secure Shell (SSH)). SD-flashminne fungerar som en h˚arddisk till Raspberry Pi-processorn. Man anslutar sig till Internet med antingen Ethernet / LAN-kabel eller Wifi-anslutning [33][34]. Raspberry PI st¨odjer ett antal operativsystem b˚ade Linux och Non-linux baserade operativsystem [35], som enklast kan laddas ner med

hj¨alp av en enda programvara NOOBS. Raspbian ¨ar den officiella operativsystem, en Linux-version som bygger p˚a operativsystemet Debian och har utvecklats av och f¨or Raspberry Pi.

2.7

Digital kommunikation

H¨ar presenteras de olika kommunikationsprotokoll och modeller som ansvarar f¨or data¨overf¨oring ¨over ett n¨atverk. Typiskt det som h¨ander n¨ar information skickas fr˚an systemet till servern och n¨ar applikationen mottar data b˚ade fr˚an servern och databasen.

2.7.1 Datorkommunikation

Begreppet datorkommunikation ¨ar ett samlingsnamn f¨or alla till¨ampningar, n¨atverksarkitektur och protokoll som anv¨ands vid data¨overf¨oring fr˚an en enhet till en annan, ¨over n¨atverk. Som karta ¨over beskrivningen anv¨ands OSI-modellen eller sin motsvarande Transmission Control Protocol/Internet Protocol (TCP/IP).

OSI-modellen togs fram p˚a initiativ av Internationella TeleUnionen (ITU) ˚ar 1984 f¨or att ers¨atta alla d˚ a-existerande tekniker, X.25, DECnet och Arpanet[36]. OSI-modellen struktureras av sju noggrant definierade lager[37], d¨ar varje lager beskriver tekniska och funktionella problem som ¨ar relaterade till datorkommunika-tion. Modellen ger dessutom anvisningar p˚a hur dessa problem kan hanteras. Specifikationen f¨or varje lager att kommunicera endast med sina grannar fr˚an modellen. OSI-standarden blev ¨overspelad i samma takt som genombrottet av Internet, d˚a TCP/IP b¨orjade sin popularitet. Transmission Control Protocol/Internet Protocol (TCP/IP) ¨ar ocks˚a en arkitektur f¨or datakommunikation ¨over n¨atverk som ¨ar indelad i fyra lager. D¨ar varje lager tillhandh˚aller en specifik tj¨anst och ¨ar helt oberoende av vad som h¨ander i ¨ovriga lager. I takt med Internets popularitet har TCP/IP blivit alltmera en standard f¨or datakommunikation, och en ers¨attare f¨or OSI-modellen. Viktigt att po¨angtera att TCP/IP fortfarande inneh˚aller alla lagern fr˚an OSI-modellen men sammansatta, se tabell 1.

Tabell 1: Protokollstack OSI-modell (v¨anster) kontra TCP/IP (h¨oger) Applikation

NNTP, SIP, SSI, DNS, FTP, Gopher, HTTP, NFS,

NTP, SMPP, SMTP, SNMP, Telnet Applikation

Presentation BitTorrent, DNS, FTP, HTTP, IMAP

MIME, XDR, ASN.1 IRC, NNTP, POP3, RTP, SIP, SMTP

Session SNMP, SSH, Telnet, TLS, SSL, TFTP

Named, pipe, NetBIOS, SAP, PPTP, RTP, SOCKS, SPDY

Transport Transport

TCP, UDP, SCTP, DCCP, SPX DCCP, SCTP, TCP, UDP, IL, RUDP

N¨atverk N¨atverk

IP(IPv4, IPv6), ICMP, IPsec, IGMP,

IPX, AppleTalk, X.25, PLP ARP, BGP, ICMP, IGMP, IP (IPv4, IPv6), RIP

Datal¨ank

ATM, ARP, IS-IS, SDLC, HDLC, CSLIP.... H˚ardvara

Fysiska ATM, Ethernet, Wi-Fi,

ISDN, xDSL USB, Bluetooth, RS-232, RS-449....

2.7.2 Kommunikationsprotokoll f¨or mikrokontroller

F¨orst¨arkaren till lastcellen och Raspberry Pien kommunicerar via mikrokontrollers som anv¨ander sig av I2C protokoll. Generellt finns det tv˚a kommunikationsprotokoll f¨or mikrokontroller Inter-integrated Circuit (I2C) och Serial Peripheral Interface (SPI)[38][39]. Inter-integrated Circuit (I2C) protokoll best˚ar huvudsakligen av tv˚a ledare, Serial Data (SDA) och Serial Clock (SCL) tillsammans med en jordanslutning, d¨arav namnet ”two wire interface”[39]. Serial Peripheral Interface (SPI) bussen arbetar i full-duplex f¨or synkron seriekom-munikation f¨or mikrokontroller[39]. SPI-bussen arbetar med 3+N ledare, SCLK, MOSI/SIMO, MISO/SOMI och SS(slave select)[39]. D¨ar N ¨ar antalet enheter som ¨ar anslutna till masterenheten p˚a bussen.

Trots sina skildringar i struktur anv¨ander de samma kommunikationsprotokoll, Master/Slave tekniks. Master/Slav ¨ar ett kommunikationsprotokoll f¨or digitala integrerade kretsar, d¨ar processen(Master) har ensriktad kontroll ¨over en eller flera slav-enheter. En Slav-enhet kan inte initiera en busstransaktion, ut-an enheten m˚aste v¨anta tills masterenheten b¨orjar kommuniceringen. P˚a en buss med flera slav-enheter ¨

ar det endast till˚atet att Master kommunicerar med dessa enheter. I vissa system till˚ats slav-enheterna att kommunicera med varandra under ett villkor, genom att meddela Master-enheten som i sin tur inr¨attar kom-munikationsl¨ank. Nedan kommer en lista p˚a f¨ordelar som varje protokoll har i f¨ordel ¨over sin motsvarande[39].

1. I2C kr¨aver endast tv˚a ledare, medan SPI kr¨aver tre eller fyra ledare.

2. SPI st¨oder h¨ogre hastighet i full-duplex-kommunikation medan I2_{C ¨ar l˚angsammare.}

3. I2_{C drar mer effekt ¨an SPI.}

4. SPI kr¨aver ytterligare ”chip signal” f¨or att hantera flera enheter p˚a samma buss. Vilket I2_{C inte kr¨aver,}

eftersom varje slavenhet har en unik adress.

5. I2_{C s¨akerst¨aller att data som skickas fr˚an masterenheter mottas av slavenheten; medan SPI inte}

veri-fierar att data har tagits emot korrekt.

6. I2_{C ¨ar billigare att implementera ¨an SPI-kommunikationsprotokollet.}

7. SPI st¨oder endast en Masterenhet p˚a samma buss medan I2C st¨oder flera Master p˚a samma buss. 8. I2C ¨ar mindre mottagligt f¨or brus ¨an SPI.

B˚ada SPI och I2_{C ¨ar bra kommunikationstill¨ampningar, men var och en har sina egna tydliga f¨ordelar}

¨

over sin motsvarande. Det finns med andra ord ingen mall f¨or vilket protokoll man ska implementera till sitt projekt. Val av protokoll f˚ar v¨aljas baserat p˚a ovann¨amnda skillnader som b¨ast passar in f¨or ens projekt. Generellt ¨ar SPI b¨attre f¨or h¨oghastighets- och l˚agkraftskomponenter. B˚ada SPI och I2_{C ¨ar robusta, stabila}

och v¨al l¨ampade kommunikationsprotokoll f¨or integrerade kretsar, d˚a b˚ada ¨ar enkla synkrona bussar ¨over ett fysiskt medium.

2.7.2.1 Serial Peripheral Interface (SPI)

SPI-gr¨ansnittet utvecklades av Motorola p˚a 1980-talet[38][39]. I2_{C ¨ar v¨aldigt energisn˚al, fyra-tr˚adigt seriellt}

kommunikationsgr¨anssnitt som ¨ar utformat f¨or IC-controllers f¨or att kommunicera med varandra. SPI-bussen ¨

ar en full-duplex som till˚ater kommunikation att str¨omma till och fr˚an huvudenheten(Master) samtidigt med en hastighet p˚a upp till 10 Mbps.

2.7.2.2 Inter-integrated Circuit (I2_C)

i2c-gr¨ansnittet utvecklades av Philips Semiconductors[38][39], som nu mera heter NXP-Semiconductors och aktie¨agare av tekniken. Protokollet Inter-integrated Circuit (I2C) ¨ar ett protokoll som till˚ater slav-enheter att kommunicera med en eller flera Master-enheter. Slavenheterna kan koppla upp sig till en Master-enhet under f¨oruts¨attning att protokollet ¨ar definierad enligt f¨oljande specifikation[38].

1. Varje uppkopplad slav-enhet har sin unika adress. 2. Datan ¨ar indelad i 8-bitars byte.

3. Reservera n˚agra bitar f¨or att kontrollera kommunikationen (start, avslut och riktning samt bekr¨aftelse om mottagen medelande).

Data¨overf¨oringshastigheten m˚aste v¨aljas mellan 100 kb/s, 400 kb/s och 3,4 Mb/s[38], men vissa I2

C-varianter inkluderar 10 kb/s (l˚ag hastighetsl¨age) och 1Mb/s (snabbl¨age) som giltiga hastigheter.

3

Metod

Detta kapitel kommer presentera och beskriva vilka metoder som har anv¨ants, samt vilka vetenskapliga och ingenj¨orsm¨assiga beslut har fattats. F¨or att besvara den konkreta fr˚agan om hur projektet har framtagits i f¨oreliggande kandidatexamen har tre metoder anv¨ants; en litteraturstudie, programmering och testning. Sj¨alva programmerings delen i projektet delades in i fyra oberoende huvudgrupper som senare sammansat-tes till en f¨ardig testad prototyp. De fyra grupperna ¨ar en backend(server och databas), streckkodsl¨asning, uppbyggnad av v˚agstation och en Applikationsprogrammering, se figur 9.

3.1

Projektmodell

Figur 10: Projektet anv¨ander Extreme Programming(EP), EP ¨ar Scrum-baserad ramverket som anv¨ands mest f¨or mjukvaruutveckling. Modellen fokuserar mycket

p˚a kvalit´e f¨ore implementering av produktbest¨allarens krav. Backlogen prioriteras av ett team tillsammans med produktbest¨allaren. Kontinuerliga tester

och kodoptimering sker kontinuerligt.

Projektet f¨oljde Scrum liknande ramverk med Agilt arbetss¨att under implementationsdelen, Extreme Pro-gramming se figur 10.

LIPS och andra icke-agila projektledningsmodeller byggs oftast av faserna F¨orstudie/Planering (f¨ore), Im-plementation (under) och Utv¨ardering (efter)[40]. Strukturen av modellen har i avsikt att faserna kommer i ordningsf¨oljd utan m¨ojlighet att omplacera eller g˚a tillbaka till tidigare fas. D¨arf¨or kr¨avs noggrann pla-nering, kontroll och uppf¨oljning under hela processen. Till skillnad fr˚an Agile Scrum, som ¨ar l¨attr¨orlig och anpassningsbar till f¨or¨andringar i planeringen[41]. Viktigt och po¨angtera att Scrum anv¨ands mest inom mjukvaruutveckling, eftersom ramverket ¨ar idealiskt f¨or projektf¨orh˚allanden d¨ar produkten kan genomg˚a snabba f¨or¨andringar i ¨onskem˚al. Idealist f¨or alla projektmodeller vore att skriva en kravspecifikation f¨orst och leverera f¨ardig implementation baserad p˚a backlogen, men s˚a ¨ar det inte i praktiken[42]. Kravspecifika-tionen kan f¨or¨andras under tidens g˚ang, det skapar oreda i projektet och frustration, men utvecklingsgruppen m˚aste fokusera p˚a aff¨arsnyttan. Det Agila arbetss¨attet k¨annetecknas av korta sprintar och avst¨amningar, med levererad prototyp f¨or varje sprint.

Extreme Programming(EP) p˚aminner mycket om Scrum metodiken, men skiljer i att EP ¨ar mer inrikta-de p˚a kvalitet av produkten ¨an att avsluta produktbest¨allarens prioriterad backlog. Eftersom Utvecklingen av projektet och backlogens prioritering planeras av Extreme-teamet tillsammans med best¨allaren. Vilket skiljer sig fr˚an Scrum d¨ar endast best¨allaren s¨atter prioriteringen.

Kunder best¨ammer omfattningen och tidsramen med uppskattningar av en programmerare. Teamet f¨ordelar uppgiften till mindre uppdrag, d¨ar varje programmerare i teamet ¨ar ansvarig f¨or en del. Program-merarna implementerar, i f¨orsta iterationen, ett funktionellt koncept av projektet. Iteration ¨ar definitionen som anv¨ands hos Extreame Programming kontra Sprints hos Scrum. Skillnaden mellan dessa definitionerna ¨

ar att Iterationer ofta ¨ar kortare ¨an 30 dagar.

Val av projektmodell har sin vikt i hur delaktig best¨allaren ska vara. Scrum l˚ater best¨allaren styra arbetet medan EP f¨orespr˚akar att “A customer sits with the team full-time”[42].

3.2

Utvecklingskort

Servern och klienterna implementerades p˚a vardera Raspberry PI av modellen 3B. Som ¨ar den tredje genera-tionen i Raspberry PI-serien av de popul¨ara minidatorerna(kompakta datorer). Med sin 1.2 GHz Quad-Core 64bit CPU blev modellen snabbare ¨an f¨oreg˚aende generationer, se tabell 2. Utrustad med 1 GB RAM-minne, samt wifi internetuppkoppling, f¨or att uppr¨atth˚alla tr˚adl¨os kommunikation. Prestandan och funktionaliteten hos modellen 3B anses vara tillr¨ackligt f¨or att klara av projektets uppdrag (enligt specifikationen).

Tabell 2: Tekniska specifikationer mellan Raspberry Pi 1, 2 och 3

Raspberry Pi Raspberry Pi 2 Raspberry Pi 3 Releasedatum Februari 2012 Februari 2015 Februari 2016 CPU ARM1176JZF-S ARM Cortex-A7 ARM Cortex-A53 CPU hastighet 700MHz single core 900MHz quad core 1.200MHz quad core RAM 256MB ->512MB 1GB 1GB

Grafik Broadcom Videocore IV Broadcom Videocore IV Broadcom Videocore IV Lagring SDHC minnesplats MicroSDHC slot MicroSDHC slot

USB Portar 2 4 4

WiFi Nej Nej 802.11n och Bluetooth 4.1

Prestandan och funktionaliteten hos Raspberry PI 3B har ¨aven j¨amf¨orts med f¨oljande IoT minidatorerna (se tabell 3) och valdes som b¨asta alternativ.

• Arduino plattform - Programmeras med deras utvecklingsmilj¨o IDE samt m¨ojligg¨or anv¨andning av b˚ade h˚ardvara och mjukvara. Arduino Uno ¨ar en av de vanligaste och mest anv¨anda Arduino utveck-lingskort. Kortet kan l¨asa data fr˚an olika sensorer och st¨oder tv˚a arbetsl¨agen, frist˚aende eller ansluten till en dator via USB-kabel. Utvecklingskortet ¨ar baserat p˚a ATmega328 processor med ¨oppen k¨allkod och f¨orinstallerad bootloader. G˚ar att ut¨oka med fler funktioner med s˚a kallade shields. Kortet ¨ar byggt att k¨ora ett program ˚at g˚angen, om och om igen, ”upprepande program”, t.ex automatisk gara-gesport¨oppnare [43]. P˚a grund av kortets byggkonstruktion, enk¨arnig processor och sekventiell exekve-ring, ¨ar kortet begr¨ansad fr˚an att k¨ora parallella flertr˚adsteknik (multithreading”). P.g.a begr¨ansning av flertr˚adsteknik och l˚ag klockhastighet p˚a 16 MHz anses Arduino Uno inte l¨amplig f¨or projektet. Dessutom att Arduino varken har ett operativsystem eller kamera-interface.

• BeagleBone plattform - BeagleBone Black ¨Ar en vidareutveckling av den popul¨ara Beaglebone platt-formen baserad p˚a AM335X -ARM Cortex-A8. Ett utvecklingskort kommer med f¨orinstallerad Debian Linux med b˚ade ¨oppen k¨allkod och h˚ardvara, utrustad med 92 I/O och 1GHz CPU f¨or att klara realtidsanalys, integreras med robotar[44] och olika sensorer. Kretskortet BeagleBone black antogs in-te l¨amplig f¨or projektet av samma anledning som f¨or Arduino, n¨amligen singel-core processor. Samt inte har tillg˚ang till Wifi, vilket ¨ar ett krav f¨or projektet att enheterna skall kommunicera tr˚adl¨ost. Dessutom har jag mer erfarenhet av Raspberry pi anv¨andning, vilket kommer underl¨atta arbetet.

Arduino Uno Rev.3 BeagleBone black Raspberry Pi 3 Driftsp¨anning DC-kontakt, USB-B (5V) DC-kontakt (5V) Micro-USB 2.0 (5V)

Microcontroller ATmega328P AM335X: ARM Cortex-A8 BCM2837: ARM Cortex-A53 CPU - k¨arnor 1 st 1 st 4 st CPU -klockfrekvens 16 MHz 1 GHz 1 GHz RAM 32 KB (0.5KB bootloader) 512 MB 1024 MB I/O pins 20 92 st 40 st I2C Ja Ja Ja SPI Ja Ja Ja

USB Portar 1 (USB-B) 1 (USB 2.0) 4 (USB 2.0) N¨atverksport 0 1 st (100 Mb/s) 1 st (100 Mb/s)

Wifi Nej Nej Ja

Videoutg˚ang Nej Micro-HDMI HDMI

WiFi Nej Nej 802.11n och Bluetooth 4.1 Dim (mm) /vikt (g) 53.5x75x15 86.4x53.3 (39.68) 56x86x20 (50)

Operativsystem Nej Ja Ja

Tabell 3: Tekniska specifikationer mellan Arduino Uno Rev 3, Raspberry 3B och BeagleBone black

3.3

Backend - server

Under detta stycke kommer rapporten att beskriva tillv¨agag˚angss¨att f¨or kommunikationen mellan alla system i projektets lilla distribuerade system. Du kan f¨ordjupa dig i Server programmering med programmerings-spr˚aket Java fr˚an denna bok[45]. Projektet f¨oljde programmeringsmodellen f¨or programmering av serversidan enligt beskrivningen i samma bok Javaserver programming av Subrahmanyam Allamaraj [45], beskrivning en-ligt f¨oljande.

Tabell 4: J¨amf¨orelsetabell: Mellan TCP och UDP

TCP UDP

Kommunikation F¨orbindelseorienterat F¨orbindelsel¨ost Tillf¨orlitlighet H¨og (garanterar att all data ¨overf¨ors korrekt) L˚ag

Packet ordning Overf¨¨ ors enligt specificerad ordning Ingen ordning, paketen ¨ar oberoende av varandra. ¨

Overf¨oringshastighet L˚angsammare ¨an UDP. Snabb

Header-storlek 20 bytes (K¨allport, Destination port, Checksum) 8 bytes (K¨allport, Destination port, Checksum) Felkontroll Ja Ja

Felaktiga paket Skickas igen fr˚an k¨allan till destinationen. Kastas Handskakning Ja Nej

• Vad ¨ar det underliggande n¨atverksprotokollet?

TCP/IP har mer f¨ordelar med h¨anseende till kravspecifikationen(se tabell 4). F¨ordelarna med TCP ¨

over UDP att trafiken kommer i r¨att ordning, att inga paket (data) f¨orloras, ¨aven vid de fall att paket ¨

and˚a f¨orloras skickas de igen automatiskt [46]. UDP ¨ar med andra ord inte lika noggrann, att paket f¨orloras h¨ar och d¨ar s˚a f˚ar de f¨orsvinna, utan m¨ojlighet att skicka de p˚a nytt. Den ¨ar inte heller noggrann i hur ordningen av paketen kommer in till systemet. UDP gjord f¨or att ha h¨og ¨overf¨oringstid[47], enkel och utan massa extra kontroller. ¨Overf¨oringstiden ¨ar relativt mindre kritisk i f¨oreliggande projekt.

F¨orbindelseorienterad kommunikation (Connection-oriented communication) var mer eller mindre det enda alternativet, eftersom och som tidigare n¨amnt, enheterna kommunicerar med TCP/IP protokoll. F¨orbindelseorienterad kommunikation inneb¨ar att enheter utf¨or en ’handskakning’ f¨or att uppr¨atth˚alla en end-to-end-anslutning. protokollet fungerar endast i dubbelriktad kommunikationsmilj¨o.

Anslutningsfri kommunikation sker vanligtvis genom att s¨anda information i en riktning, fr˚an k¨alla till destination, utan att verifiera om destinationen fortfarande finns eller beredd p˚a att ta emot mer

(a) Etablerar anslutning och skickar (b) Avslutar anslutning

Figur 11: Schematisk representation av de fyra steg vid n¨atverksanslutning med handskakningsmetoden. Bild fr˚an wikipedia

information. Man kan f¨orknippa UDP med anslutningsfri kommunikation, d˚a UDP baseras p˚a anslut-ningsfritt kommunikationsprotokoll. Desamma f¨or TCP och f¨orbindelseorienterat kommunikationspro-tokoll.

• Hur lokaliserar klienterna servern?

Klienterna (v˚agen, kameran och applikationen) lokaliserar servern med hj¨alp av den unika IP-adressen som server-enheten erh˚aller[48]. S˚aledes skall server-enheten vara uppkopplad till Internet f¨or att kli-enterna skall kunna lokalisera och kommunicera med servern. Observera att servern m˚aste ha en fix IP-adress, tilldelas av internetleverant¨oren eller konfigureras manuellt f¨or en enhet. J¨amf¨ort med en dynamisk IP-adress riskeras server-enheten att byta adress som medf¨or att kommunikationen bryts och inte l¨angre uppr¨atth˚allas med det gamla IP-adress. St¨angda portar eller paketen inte n˚ar destinationen (broken pipe) ¨ar exempel p˚a problem som kan hindra enheterna fr˚an att ansluta till servern. Med hj¨alp av Ping och Traceroute kan en fels¨oka anslutningsv¨agen fr˚an klienterna till servern.

Ping-kommandot testar anslutningshastigheten till servern, uppr¨attar en anslutning till servern, genom att skicka ett paket (32 byte) och ber¨aknar tiden f¨or packet att skickas och f˚ar svar fr˚an serven. Dynamic Host Configuration Protocol (DHCP) ¨ar ett n¨atverksprotokoll som tilldelar datorerna i ett lokalt n¨atsegment med dynamiska IP-adresser. Ett system b¨orjar med att skicka ett DHCP-f¨orfr˚aga (DHCP-discover”)[49]. Vilket servern svarar med en anslutningstid (lease-time”). Systemet beh˚aller den dynamiska IP-adressen under hela anslutningstiden. Vanligtvis brukar man f˚a samma IP-adress fr˚an DHCP-servern n¨ar anslutningstiden har l¨opt ut, givet att man skickar en (DHCP-renewal”). Vid fall att systemet ¨ar avst¨angd n¨ar anslutningstiden l¨opt ut blir det DHCP-discovery och en ny adress tilldelas till systemet.

• Kommunicerar klienterna och servern synkront eller asynkront? Systemet kommunicerar synkroniskt.

Hela systemet (Kundvagnen) ¨ar multitr˚adad, d¨ar varje enhet ¨ar sin egen tr˚ad och agerar som en sj¨alvst¨andig klient. Detta till˚ater datorn att utnyttja den maximala kapaciteten av processorn och ¨okar prestandan. En server som hanterar flera klienter implementeras b¨ast genom att skapa en tr˚ad f¨or varje klient. Vilket ger upphov till en multitr˚adad server. Det kan dock leda till besv¨ar och problem om

enheter f¨ors¨oker l¨asa/skriva till servern samtidigt. Om det skulle uppst˚a, intr¨affar en sp kallad ”Data Race”. Allts˚a att l¨asning och skrivning kan ge felaktieresultat beroende p˚a ordningen som data racet skedde. Det l¨ostes genom att introducera exklusiva l˚as, d¨ar tr˚adar l˚aser minnesplatsen de befinner sig i. Minnesplatsen kvarst˚ar o˚atkomlig f¨or alla andra processer tills den process som h˚aller i nyckeln l˚aser upp minnet. L˚asmekanismen garanterar att hindra tr˚adarna fr˚an att kollidera samt data race undvikas. Dock ¨ar det inte n¨odv¨andigt att multitr˚ada serven, men priset man f˚ar betala ¨ar att enheterna f˚ar v¨anta med att skicka data till servern, tills servern ¨ar tillg¨anglig. En enhet som v¨antar p˚a att skicka in data till en server som s¨ander data till andra komponenter tenderar att sitta och v¨anta, vilket sl¨osar bort tid. Enheterna kan anv¨anda denna tid till att exekvera andra saker.

(a) Ingen Data Race, l¨asningen och skrivningen sker utan att data race sker (lyckligtvis)

(b) Data Race, tr˚ad2 l¨aste objektet innan tr˚ad1 hann spara till minnet, det resulterade till att det v¨arde som tr˚ad1 uppdaterade bara f¨orsvann.

Figur 12: Demostration p˚a hur tv˚a tr˚adar/processer som l¨aser och skriver kan leda till Data Race, om l˚asmekanismen inte ¨ar implementerad

• Vad ¨ar protokollet mellan klient och server p˚a applikationsniv˚a?

Klienterna skickar HTTP request till servern och servern svarar med en HTTP-statuskod.

3.4

Databas

Databasen kommer programmeras i SQL spr˚aket med hj¨alp av databashanteraren MySQL[50] och php-MyAdmin f¨or administrera via webbl¨asaren[51]. Databasen inneh˚aller information om registrerade varor-nas vikt, pris och namn p˚a varan. Streckkoden p˚a varan anv¨ands som den unika prim¨arnyckel. Databasen kommer vara enkel och okrypterad, d˚a det fyller en tillf¨allig l¨osning, projektet har ingen avsikt att spara information om produkter. Tanken ¨ar att projektet anv¨ander best¨allarens REST API f¨or att h¨amta(fetch) information om produkter som de har i sin butik. F¨ordelen med att anv¨anda REST(Representational Sta-te Transfer) API(Application programming inSta-terface) ¨ar att den ¨ar direkt s¨akerhet f¨or databasen. Eftersom anv¨andarapplikationen inte f˚ar veta k¨anslig informationen om tabellerna i databasen, anv¨andarapplikationen f˚ar en l¨ank med annorlunda parametrar.

Tabell 5: En j¨amf¨orelsetabell mellan JSON- och XML-gr¨anssnitt

JSON XML

Struktur

Anv¨ander namn/v¨ardespar, samt avgr¨ansat av ”{” och ”}” f¨or objekt, ”[” och ”]” f¨or arrayer ”,” f¨or att skilja par och ”:” f¨or att skilja namn fr˚an v¨arde

Kr¨aver ¨oppnings- och st¨angningskod

Storlek Betydligt mindre ¨an XML St¨orre ¨an JSON pga struktur ¨

Overf¨oringshastighet 100 g˚anger snabbare ¨an XML l˚angsam ¨overf¨oringstid p.g.a. dess stora storlek. L¨asbarhet Tydlig strukturerad och anses vara enklare m¨anskligt l¨asbar. Mindre tydlig strukturerad

S¨aker JSON-tj¨anst returnerar ett JSON-svar inkapslat i ett ”functioncall” S¨akrare ¨an JSON

Projektet valde att anv¨anda JSON[52] som datautbytes spr˚ak ¨over XML[53], se tabell 5 f¨or en ¨overblick. JSON ¨ar utformad f¨or att vara m¨anskligt l¨asbar och enklare f¨or datorer att analysera och anv¨anda(”parse”)[54], framf¨or allt ber¨aknas JSON att vara hundra g˚anger snabbare ¨an XML[54]. Dock ¨ar nackdelen med JSON att den saknar felhantering vid JSON-anrop[54].

En annan stor nackdel med JSON att den ¨ar farlig att anv¨anda med otillf¨orlitliga tj¨anster och webbl¨asare, eftersom en JSON-anrop returnerar ett JSON-svar inkapslat i ett ”functioncall” som kommer att k¨oras av webbl¨asaren. Otillf¨orlitliga webbl¨asare kan hackas och resultera till en s˚arbarhet och rad attacker som f¨oljd[52].

Inl¨asningen av bilder vid Feature Matchning anropades fr˚an NoSQL med hj¨alp av streckkoden som refe-rens till sparade bilderna i databasen.

3.5

Streckkodsl¨

asning och m¨

onsterigenk¨

anning

Projektet startade med att implementera ett fungerande streckkodsl¨asning (detekterade och l¨aste streck-koden p˚a information), det med hj¨alp av en fysikalisk ber¨oringsfri sensor, kameramodul f¨or Raspberry Pi i programmeringsspr˚aket Python[55]. Den skannade r˚adata fr˚an kameramodulen analyserades och konver-terades till digitala data. Fr˚an datan avh¨amtades identifierad streckkod i b˚ada en och tv˚a dimensionell f¨or att registrera inb¨addad information, dessutom utf¨ordes en m¨onsteridentifiering ”Feature Matching” och j¨amf¨ordes med m˚alkarakteristika varan fr˚an databasen f¨or att identifieras.

Projektet valde att anv¨anda en snabb och kompatibel teknik, QR-kod, f¨or att l¨asa/registrera ink¨opslistan till produkten. Med hj¨alp av samma kameramodul detekteras och identifieras QR-koden samt avl¨asas p˚a in-formation f¨or att visualisera p˚a sk¨armen.

L¨osningen ¨ar kostnadseffektiv samtidigt som en ¨ar l¨amplig f¨or produkten. Eftersom teknikutvecklingen av kameramoduler ¨ar numera avancerade och minimala i storlek. Det medf¨or att projektet kan implementera flera kameramoduler utan uppoffring av plats.

Projektet anv¨ande ”Feature Matcher” som en m¨onsterigenk¨anning[56], det anv¨andes f¨or att b˚ade verifi-era och s¨akerst¨alla att den skannade varan ¨overensst¨ammer med butikens varudatabas. Det finns flera olika algoritmer f¨or att kontrollera om en bild matchar en annan. Feature Matchning ¨ar b¨attre val vid de fall det skannade objektet varierar i ljusstyrka, vinkel eller orientering fr˚an originalbilden.

Feature matchning fungerar p˚a s˚a s¨att att den tar in tv˚a bilder, en originalbild p˚a f¨orpackningen”queryImage”, se fig 17, och bilder fr˚an kameramodulen ”trainImage”, och f¨ors¨oker hitta samma m¨onster fr˚an trainImage i queryImage med hj¨alp av matchningsalgoritmen SIFT[4]. Man kan se p˚a algoritmen som en ”Brute Force”, den kommer matcha alla ”keypoints” och sortera de beroende p˚a b¨ast och mest sannolik matchning av bil-derna.

Projektet valde att implementera matchningsalgoritmen SIFT, som tidigare n¨amnt, f¨or att algoritmen anses vara b¨attre anpassad till projektet. Vid en j¨amf¨orelsestudie med liknande algoritmer SURF, BRIEF och ORB presenterade forskarna Ebrahim K, Siva P, och Mohamed S i sin vetenskapliga artikel Image Matching Using SIFT, SURF, BRIEF and ORB: Performance Comparison for Distorted Images[57]. ORB algoritmen ¨ar snabbast av ovann¨amnda matchningsalgoritmer medan SIFT presterade b¨ast i de flesta sce-narier, se tabellerna 6, 7 och 8 Dock visade pappret att det var enstaka speciella fall d¨ar SURF och ORB fick b¨attre resultat ¨an SIFT n¨ar vridningsvinkeln ¨ar 90◦(se tabell 8 ) samt SURF-algoritmen visade s¨amre matchningsresultat vid brus ”noice”.

Tabell 6: Resultat av att j¨amf¨ora bilderna med varierande f¨argkontrast. Time(sec) Kpnts1 Kpnts2 Matches Match rate (%)

SIFT 0.13 248 229 183 76.7

SURF 0.04 162 166 119 72.6

ORB 0.03 261 267 168 63.6

’Kpnts1’ ¨ar antal ’keypoints’ hos queryImage och ’Kpnts2’ ¨ar antal ’keypoints’ hos trainImage Tabell 7: Resultat av att j¨amf¨ora bilderna med vinklade ’trainImage’

Time(sec) Kpnts1 Kpnts2 Matches Match rate (%)

SIFT 0.16 248 260 166 65.4

SURF 0.03 162 271 110 50.8

ORB 0.03 261 423 158 46.2

’Kpnts1’ ¨ar antal ’keypoints’ hos queryImage och ’Kpnts2’ ¨ar antal ’keypoints’ hos trainImage Tabell 8: Matchningsgrad mot varierande rotationsvinkel

Angle -> 0 45 90 135 180 225 270

SIFT 100 65 93 67 92 65 93

SURF 99 51 99 52 96 51 95

ORB 100 46 97 46 100 46 97

Dessutom visade resultatet att matchade keypoints f¨or ORB var mestadels centrerade av objektet, till skillnad fr˚an SURF och SIFT d¨ar matchningens keypoints var distribuerad ¨over hela objektet (se bild 13).

Figur 13: Resultat av att j¨amf¨ora bilderna med varierande f¨argkontrast. (a) SIFT (b) SURF (c) ORB Feature Matchning ¨ar per definition b¨attre val ¨an Template Matching, i det att trainImage kommer variera mycket fr˚an originalbilden, d˚a skanningsbilderna kommer vara varierande. Template Matching klarar inte av de fall d˚a trainImage varierar i ljusstyrka, orientering och storlek fr˚an originalbilden. Dvs s˚a l¨ange man inte vill riskera fel matchning genom att s¨anka ”threshold”.

3.6

Lastcell / v˚

ag

En lastcell anv¨andes f¨or att v¨aga vagnens nettovikt (summan av den totala vikten av alla varor som finns i vagnen). Lastcellen konstruerades med hj¨alp av fyra tr˚adt¨ojningsgivare kopplade p˚a en balk (med uppl¨osning upp till 5kg) (se fig 21, under det vita klistret p˚a balken ¨ar tr˚adt¨ojningsgivare). Eftersom differenssp¨anningen ¨

ar bara n˚agra millivolt kopplades lastcellen till en f¨orst¨arkare (HX711) f¨or att f¨orst¨arka signalen fr˚an last-cellen. F¨orst¨arkaren ¨ar vidare kopplad till Raspberry Pien.

Projektet valde att k¨opa in f¨ardigbyggd sp¨anningsf¨orst¨arkare f¨or 112.00 kr, p˚a grund av tidsbrist och f¨or att undvika sp¨anningsspikar som f¨orst¨or sensorn. Annars var det andra alternativet att konstruera en egen sp¨anningsf¨orst¨arkare med hj¨alp av en operationsf¨orst¨arkare (LM741)[58] och en instrumentf¨orst¨arkare (AD620)[59].

Figur 14: UML Diagram: Lastcellen v¨ager nettovikten och vidarebefordrar resultatet till servern.

3.7

Applikation

Det mest grundl¨aggande kravet f¨or applikationen ¨ar att den skall kommunicera och motta information fr˚an b˚ade servern och databasen parallellt med app-anv¨andningen. Kommunikationen mellan applikationen och serversidan etablerades genom att implementera TCP/IP protokoll m.h.a Socketkommunikation.

Applikationen utvecklades i programspr˚aket Java i utvecklingsmilj¨on Android Studio. F¨ordelarna med Andro-id Studio ¨ar deras Intellij-editor (avancerad kodnavigering och Intelligent kodkomplettering) och att man inte beh¨over ha en fysisk enhet f¨or att testk¨ora sin applikation.

D¨arav valde projektet att inte k¨opa in en surfplatta, applikationsvisualisering sker genom att k¨ora appli-kationen p˚a dator med hj¨alp av AVD (Android Virtual Device).

Man kan konfigurera en AVD, som ¨ar en konfiguration som definierar egenskaperna hos en Android-enhet, f¨or att simulera i Androidemulatorn. Androidemulatorn har ¨an idag fortfarande n˚agra begr¨ansningar, mest n¨amnv¨ard att den inte st¨odjer bluetooth, NFC (Near Field Communication) och andra verktyg[60].

Java och Android Studio karakteriserades ¨over C# och Xamarin, eftersom huvudm˚algruppen f¨or projektet inte ¨ar direkt inriktad f¨or privat personer, utan f¨or f¨oretag. D¨arf¨or beh¨over inte applikationen integreras till mer ¨an en plattform. Java karakteriserades ¨aven ¨over Swift programmeringsspr˚aket (Utvecklats 2014 av Apple) i det m˚an att Android har flera APIer och mycket mer dokumentation ute p˚a n¨atet, dessutom erh˚alls begr¨ansad kunskap i Android programmering fr˚an tidigare kurs. Vidare kan man l¨asa denna bok f¨or att komma ig˚ang med utvecklingsverktyget[61].

Med C# och Xamarin inneb¨ar det att skriva en gemensam kod som genererar iOS, Android och Windows UWP-appar vid kodkompilering. Den anv¨ander de vanliga anv¨andarkontrollerna som Knapp, Label, Listview, Bild, StackLayout, Kalender m.fl. Med andra ord r¨acker det med att skriva kod en g˚ang, exempel skapa en knapp och Xamarin genererar en kod f¨or varje plattform. Det vore smartare alternativ vid de fall man ska anpassa applikationen till fleraplattformar, men bara att m¨ojligheten finns r¨acker inte som kriterium att det ska karakteriseras som n¨odv¨andigt.

Figur 15: Class Diagram: beskriver strukturen hos applikationens och hur dess klasser f¨orbinder sig till varandra.

En Android-applikation best˚ar av flera aktiviteter, som i sig best˚ar av grupper av organiserade UI-elements (det anv¨andaren ser p˚a sk¨armen). D¨armed kan applikationen ses som en ActivityStack, se figur 16. Vid applikationsanv¨andning och en ny Activity k¨ors, l¨aggs denna aktivitet h¨ogst i stacken tills aktiviteten st¨angs av med ”onDestroy()” d˚a visas n¨astf¨oljande Activity i stacken. B˚ade databehandlingen i applika-tionen och l¨ankningen till serversidan sk¨ots av IntentServices. IntentService-klassen ger en enkel struktur f¨or att k¨ora en uppgift i bakgrundstr˚aden. Detta m¨ojligg¨or att hantera och l˚ata l˚angvariga funktioner i drift utan att p˚averka anv¨andarens App-anv¨andning. Dessutom p˚averkas inte IntentService av de flesta anv¨andargr¨anssnittens livs-cykelh¨andelser, s˚a det forts¨atter att k¨oras ¨aven vid de omst¨andigheter som skul-le st¨anga av AsyncTask. Android erbjuder ut¨over IntentService, AsyncTask och AsyncTaskLoader f¨or att m¨ojligg¨ora synkronisk programmering. AsynkTask ¨ar utformad f¨or att utf¨ora kortvariga uppdrag till skillnad fr˚an de andra tv˚a, som ¨ar b¨attre val vid utf¨orande av l˚angvariga uppdrag. AsynkTask erh˚aller en referens till ett GUI-element f¨or att enkelt kommunicera/uppdatera GUIn baserad p˚a resultatet. Dock kan AsynkTask leda till l¨ackage i minnet, f¨orlorat resultat och sl¨osa energi vid felaktig anv¨andning[62]. Eftersom systemets ”garbage collector” inte rensar dessa element under tiden AsynkTask k¨ors, d˚a de h˚alls som referens. Denna nackdel finns inte hos IntentService, eftersom IntentService och GUI-tr˚aden kommunicerar genom ”broadcast messages”, skickar och mottar meddelanden.

Figur 16: Demonstration p˚a hur en applikation fungerar som ActivityStack fungerar.

4

Resultat

Resultatet av projektet blev v¨aldigt lik l¨osningsf¨orslaget, med h¨ansyn till avgr¨ansningarna och kravspecifi-kationen.

4.1

Server

Med hj¨alp TCP/IP protokollet byggdes en komunikationsl¨ank (Socket) mellan serversidan och klienterna. Serversidan programmerades i programmeringstr˚aket Java.

Systemets alla klienter (v˚agen, kameran och applikationen) b¨orjar alltid med att ansluta sig till servern. D¨arefter skickar klienterna ”commands” till servern med ny data eller f¨or att inh¨amta data. Kameran-tr˚aden skickar information om skannade varor, v˚agen skickar in viktf¨or¨andringen medan applikationen l¨aser informationen fr˚an serversidan. Responstiden och svarstiden ¨ar mindre ¨an en sekund.

Utf¨orda tester resulterade visade att servern kunde hantera alla ansluta enheter utan att varken f¨orv¨axla eller tappa informationen.

4.2

Streckkodsl¨

asning och m¨

onsterigenk¨

anning

Figur 17: Bilderna representerar en liten m¨angd av queryImage. queryImage anv¨ands som referens f¨or att skannade Traindata.

(a) Registrerad produkt 1 (b) Registrerad produkt 2

Skanning av produkter, streckkodsl¨asning och m¨onsterigenk¨anning med hj¨alp av Feature Matching gav lo-vande resultat vid identifiering av registrerade produkter, enligt kravspecifikationen.

Streckkod identifiering och streckkodsl¨asning skedde kontinuerligt med hj¨alp av kamera-tr˚aden, med en re-sponstid p˚a ∼0.5s (under perfekta omst¨andigheter). D¨ar de perfekta omst¨andigheterna ¨ar att streckkoden ¨

ar i fokus och med korrekt sk¨arpa, vilket ˚astadkommer ifall varan ¨ar 10cm till 1m fr˚an kameran, oberoende av vinkeln (se tabell 9).

Tabell 9: Resultatet ¨over streckkodsl¨asning och m¨onsterigenk¨anning i f¨orh˚allandet till avst˚and och inst¨alld fokus p˚a Raspberry Pi-kameran

Streckkodsl¨asning M¨onsterigenk¨anning <10 cm Suddig sk¨arpa, streckkoden blir suddig och

ol¨asbar

Varan ¨ar f¨or n¨ara (Suddig sk¨arpa), algoritmen misslyckas att identifiera varan

10 cm Bra intervall f¨or l¨asning av streckkoden lyckas att identifiera, bara n˚agra f˚a sannolika matchningar (mindre ¨an 30 ’keypoints’) 1 m Bra intervall f¨or l¨asning av streckkoden lyckas att identifiera, med m˚anga sannolika

matchningar (mer ¨an 30 ’keypoints’) >1 m

varan ¨ar f¨or l˚angt ifr˚an, streckkodens pinnar sm¨alter samman vilket medf¨or ol¨aslig streck-kod

Misslyckas att identifiera varan

Resultatet fr˚an Feature Matching hade en m¨onsterigenk¨annings-tid p˚a ∼3s, d¨ar den totala tiden ¨ar 3.5s f¨or varje identifierad vara. Att d¨oma resultatet utifr˚an h˚ardvarans kapacitet bed¨oms detta till rimlig identifieringstid.

Dock visade resultatet att Feature Matching kunde identifiera felaktiga varor (fig 20) eller med f˚a match-ningar (fig 18). Algoritmen fick kalibreras med ett tr¨oskelv¨arde p˚a mer ¨an 30 sannolika matchningar innan varor klassificeras som korrekt identifierad. Fig 18 ¨ar ett exempel p˚a en korrekt identifierad vara men inte godk¨and, p.g.a. f¨or f˚a matchningar. Vidare ¨ar figur 19 exempel p˚a godk¨and identifierade och registrerade varor.