Enligt de f¨orsta praktiska testerna har m¨atos¨akerhet ber¨aknats till ± 8g med medelv¨arde p˚a 1g som kvar- st˚aende fel, se fig 21 och tabell 10.
Tabell 10: Resultatet av lastcellen Resultat M¨atomr˚aden (minsta och st¨orsta): 3g-5kg
Tid till stabil signal: ∼ 1.5s
Stigtiden 0.1 s
M¨atos¨akerheten: ±1.739g
Kvarvarande fel(min, max): -1 g, 2 g Offset(medelv¨arde Kvarvarande fel): 0.63077g
Figur 21: F¨orsta praktiska testningen av lastcellen (Arduino anv¨ands inte i slutprodukten)
Enligt felanalysen ¨ar det konstruktionen av lastcellen och kopplingen av komponenten som bidrog till st¨orsta delen av os¨akerheten, bara genom att stabilisera konstruktionen och l¨oda ledningarna till komponenten minskade m¨atos¨akerheten med mer ¨an fj¨ardedel. Framf¨or allt minskade stigtiden fr˚an 7s till 1.5s. Kalibre- ringsvikterna m˚aste v¨agas med korrekt noggrannhet vid kalibrering av lastcellen, det p˚averkar resultatet direkt p˚a ett s¨att att alltid visa felaktig vikt.
Figur 22: V˚ag linj¨aritet, faktiskt- mot uppm¨att vikt
Dessutom visade testresultatet att lastcellen var linj¨ar i f¨orh˚allande det praktiska och uppm¨att vikt fr˚an lastcellen, se fig 22.
4.4
Applikation
Applikationen hade en uppdateringsfrekvens p˚a 1 server- och databasanrop samt inl¨asning per sekund. Upp- dateringsfrekvensen resulterade att applikationen uppdaterades i realtid (med ungef¨ar 1 sekunds f¨ordr¨ojning). Det g¨allde ¨aven uppdatering av ink¨opslistan. Responstiden vid knapptryckning ¨ar v¨aldigt liten att den anses vara f¨orsumbar (ungef¨ar 0.1 ms). Under alla utf¨orda verifieringstest har applikationen varken kraschat eller slutat fungera. Under testfasen st¨angdes serversidan f¨or att ¨overvaka applikationens felhantering, vid avbru- ten kommunikation. Applikationen gick i ett kontinuerligt tillst˚and att f¨ors¨oka ˚aterkoppla sig till servern. i resten av sektionen beskrivnings applikationen och alla implementerade funktioner.
Applikationens f¨orsta Activity ’v¨alkomstsidan’ (fig 23). Applikationen skickar beg¨aran om att ansluta sig till servern f¨orst n¨ar knappen ’Press to start shopping’ trycks. D¨arefter efterfr˚agar applikationen om b˚ada kameran och lastcellen ¨ar anslutna och ˚atkomliga. Aktivityn f¨orblir i ”loading screen” tills servern svarar med att alla enheter ¨ar anslutna och handeln kan b¨orja(fig 24). Alternativt startar om o˚atkomliga enheter.
Figur 24: Loading screen: Applikationen f¨ors¨oker ansluta efterfr˚aga servern om kameran och lastcellen ¨ar anslutna och ˚atkomliga
Efter en lyckad anslutning, startas ’ActiveStore’-Activity(fig 25). Activityn ansvarar f¨or att visualisera alla varor i kundvagnen, ink¨opslistan, presentera Error meddelanden och andra till¨aggsfunktioner, som att av- sluta handel och kalla p˚a hj¨alp.
CANCEL: Handeln avbryts, Applikationen ˚aterg˚ar till v¨alkomstsida, fig23. CALL ON HELP: En till¨aggsfunktion som kallar p˚a personal, fig 28.
ADD SHOPPING LIST: Uppdaterar ink¨opslistan, vid fall att listan ¨ar registrerad i servern. Fig 27. Se fig 27 f¨or en registrerad och uppdaterad ink¨opslista.
CHECK OUT: Tillhandah˚aller den tj¨anst f¨or betalning och avsluta handeln (startar ny Activity). Fig 29
Figur 25: ’ActiveStore’-Activity: ansvarar f¨or att visualisera alla varor i kundvagnen,ink¨opslistan, presentera ett Error meddelande och andra till¨aggsfunktioner, som att avsluta handel och kalla p˚a hj¨alp.
Figur 26: vagnen har registrerat 2st mj¨olkf¨orpackningar f¨or totalt 50 kr och 2st ¨aggf¨orpackningar f¨or totalt 108 kr, l¨angst ner p˚a sk¨armen/bilden visas den ber¨aknade summan av det totala priset av produkterna F¨or att s¨akerst¨alla att applikationen uppdateras i realtid (med ungef¨ar 1 sekunds f¨ordr¨ojning), skickar ap- plikationen kontinuerliga meddelanden till servern f¨or en uppdatering om registrerade varor. Meddelanden ¨
ar en JSON-str¨ang som inneh˚aller alla varor i kundvagnen och dess antal, byggd enligt f¨oljande format {
{ "Streckkod":"987654321", "Antal": 2, }, { "Streckkod":"123456789", "Antal": 2, }, ] }
JSON-str¨angen l¨ases p˚a information, inh¨amtar alla streckkoder och g¨ora ett databasanrop om styckpriset och namnet p˚a varan.
{ "data":[ { "barcode":"123456789", "namn":"Milk", "pris": 25 }, { "barcode":"987654321", "namn":"Eggs", "pris": 54 } ] }
Vid en lyckad databas¨overf¨oring ˚aterst˚ar det bara att iterera JSON-str¨angen och visa resultatet p˚a applika- tionen.
Figur 27: ActiveStore: Ink¨opslistan registrerad. Applikationen ger kunden m¨ojlighet att trycka p˚a den knapp som korresponderar till varor har placerat in i vagnen, f¨or att markera det gr¨ont. (Eftersom varje kund stavar olika eller skriver ink¨opslistan i olika spr˚ak, valdes att inte implementera automatisk markering)
Figur 28: N¨ar en kund tycker p˚a till¨aggsfunktionen ”CALL ON HELP”, visas en ”push”-meddelande som ber¨attar att personal ¨ar p˚a v¨ag. Likadant f¨or ”Error meddelande” ex. fel nettovikt
Figur 29: ”Check out”: H¨ar ¨ar det t¨ankt att kunden betalar och avslutar sitt k¨op. Den totala summan som kunden ska betala visas ¨aven h¨ar.
5
Diskussion
Projektet har utvecklat en smartare kundvagn (Smart Cart), prototypen har genomg˚att testfaser och upp- fyller specificerad kravspecifikation. Anv¨andaren skulle kunna placera en vara i kundvagnen och d˚a ska varan identifieras och registreras, vidare presenteras resultatet p˚a sk¨armen. Anv¨andaren skulle ¨aven kunna ta ut en varan fr˚an vagnen, varan skannas av och tas bort fr˚an sk¨armen. P˚a serversidan skulle det uppr¨attas en databas som anropades f¨or produktinformation som visas p˚a sk¨armen. Lastcellen visade en uppl¨osning p˚a 3g (en sockerbit) med ± 1.7g noggrannhet, vilket ¨ar i viktklassen av ett vykort. Det ¨ar speciellt mindre f¨orv¨antat hur den sj¨alvbyggda v˚agen, utan extra optimering till ett stadigt f¨aste, kunde n˚a den h¨oga noggrannheten. Identifiering av produkter skulle beh¨ova b¨attre kalibrering och ¨overs¨attas till c++ kod f¨or att uppn˚a snabba- re inl¨asnings- och identifieringstid ¨an vad Python har ˚astadkommit[55]. Det finns inga krav p˚a inl¨asningstid men b¨attre resultat b¨or alltid efterstr¨avas. Applikationen visade stora utvecklingsm¨ojligheter, b˚ade design och mer integrerade funktioner. Funktionaliteten och uppvisning av prototypen p˚averkades inte av den be- gr¨ansade varo-databasen, med omkring 20 registrerade varor. Inte heller av den enkla konstruktionen av vagnen (byggdes p˚a FabLab i Halmstad). Konstruktion och utveckling av fysiska kundvagnar st˚ar utanf¨or ramen f¨or detta projekt. Projektet har varit utmanande n¨ar det g¨aller att f˚a ihop kommunikationsl¨anken mellan de involverade komponenterna och vidare publicera i resultatet till sk¨armen. Att f˚a tr˚adarna att kom- municera och k¨oras parallellt utan datarace uppst˚ar blev snabbt till problematik n¨ar buggar uppstod. Samt att uppr¨atth˚alla internetuppkopplingen mellan sk¨armen, servern och komponent-klienterna var p˚afrestande d˚a de dynamiska IP-adressen utv¨axlades med j¨amna intervall. Slutligen tilldelades klienterna statiska IP- adresser f¨or att l¨osa kr˚angligheten.
¨
Ar det n¨odv¨andigt med v˚agen?
Ja, v˚agen fyller en extra funktion i s¨akerhetsfronten, den f¨orsv˚arar f¨or folk att utnyttja systemet. Utan v˚agen f˚ar hela systemet en s˚arbarhet, fr˚an ett utf¨ort experiment t¨acktes kamerorna och varor placerades i vagnen. Varorna varken identifierades eller registrerades, d¨armed en st¨old har beg˚atts utan m¨ojlighet f¨or systemet att uppt¨acka fusket.
Problematiken undvikas med hj¨alp av v˚agen. D˚a det resulterar till vikt¨okning om n˚agot placeras i vagnen. Vilket medf¨or att indikeringslampor lyser r¨ott, Vid det fall att systemet inte k¨anner igen vikt¨okningen, i form av inga produkter skannades.
F¨oresl˚a produktf¨orb¨attring
Ska man kritiskt granska arbetet och f¨oresl˚a fortsatt arbete, s˚a finns det en del att vidareutveckla. F¨orst och viktigast att utveckla applikationen med flera v¨ardefulla funktioner. Som navigeringshj¨alp till ¨onskade pro- dukter, sj¨alvk¨orande kundvagn samt applikationens grafiska gr¨anssnitt beh¨over f¨orfinas. Dessa ¨ar baserade p˚a resultatet fr˚an marknadsunders¨okningen (sektion 1.7), d¨ar intresset f¨or navigering till olika produkter ¨ar 32.9% f¨or S motsvarande 30.8% f¨or ungdomarna(V).
Dessutom implementera convolutional neural network(ConvNet)[63] som ett annat alternativ f¨or igenk¨anning av produkter, men absolut inte n¨odv¨andigt. F¨or att ConvNet skall funka s˚a beh¨ovs mycket tr¨aningsdata. Tr¨aningsdata i form av bilder p˚a produkter tagna med Pi-cameran som ’Indata’ och namn eller bild p˚a produkten som ’Output data’. D¨ar man anv¨ander det tr¨anade n¨atverket till att identifiera produkterna. Det finns mycket kod och information ute p˚a n¨atet, dock fanns ingen tid att tr¨ana ett ConvNet. Med tanke p˚a de andra systemen som ocks˚a skulle implementeras, dessutom skriver examensarbetet sj¨alv och l¨aser andra kurser parallellt. P˚a tal om ConvNet, det p˚aminner om ett annat examensarbete, d¨ar gruppen, best˚aende av tv˚a studenter, anv¨ander ConvNet till att utveckla ett v˚ag-system, f¨or att k¨anna igen frukter. Till det anv¨ande gruppen f¨oljande verktyg Raspberry Pi, Rraspberry Touchscreen och Picamera. Jag menar inte att de g¨or samma projekt, utan mer fokus p˚a identifierings delen av f¨oreliggande projekt.
F¨ordelar med ett tr¨anad ConvNet ¨ar att man slipper hela NoSql delen av projektet, d˚a man inte beh¨over g¨ora databasanrop f¨or varje produkt. Dessutom ¨ar den k¨and f¨or sin noggrannhet av identifiering av exakt output, beroende p˚a sin noggrannhet. Ut¨over att den beh¨over mycket tr¨aningsdata, ¨ar man tvungen att
sitta och ¨andra p˚a ’weights’ v¨arden tills man f˚ar ett b¨attre tr¨anat n¨atverk. Dessutom kr¨aver n¨atverket en ber¨akningsstark processor, och i f¨oreliggande projekt delas CPUn redan mellan kameran och v˚agen. Projektet har m¨ojlighet att spara tagna bilder f¨or att tr¨ana ett ConvNet, speciellt d˚a datan (bilderna) ¨ar tagna i samma butik och precis hur kunderna skannar varor.
Genomf¨orandet av projektet utifr˚an givna tids- och budgetramar
Projektets budget var begr¨ansad till det beviljade bidraget fr˚an ALMI, bidraget gav valm¨ojligheter vad det g¨aller komponenter. Summan av den totala kostnaden f¨or utveckling av prototypen ¨oversteg inte kostnads- ramen1.6.1 fr˚an projektets f¨orsta fas, f¨orstudie. D¨armed var projektet inte i ett ekonomiskt underl¨age, trots att n˚agra komponenter kortslutandes av misstag under projektets g˚ang, vilket ¨ar i f¨orvisso medr¨aknat inom kostnadsramen.
Dock ¨onskar jag i efterhand att jag haft mer tid att utveckla en betal¨osning och navigering till olika produkter, vilket ¨ar ¨onskv¨ard enligt enk¨atunders¨okningen (sektion 1.7). Dock visade sig att de kunskaper jag erh¨oll inom Android programmering inte var tillr¨ackliga f¨or att ˚astadkomma m˚alet med projektet. Det ¨
agnades stor del av tiden till att f˚a ¨overblick ¨over Androids tr˚adar och hur dessa skulle implementeras p˚a b¨asta s¨att. Mesta del av tiden gick ˚at att fixa problem som uppstod, under utvecklingstiden. Det uppstod problem med att lagra svenska tecken i databasen. Dessutom att programmera server-tr˚adarna tog mesta del av tiden, Valet att bygga en egen v˚ag ist¨allet f¨or att k¨opa en f¨ardigbyggd elektronisk v˚ag var ocks˚a tidskr¨avande, men annars hade projektbudgeten sett annorlunda f¨ordelad. Skulle projektet g¨oras om, skulle f¨ormodligen samma komponenter anv¨andas, eftersom de fyller alla krav och behov. Dock skulle projektets (inte applikationen) skrivas i c++ f¨or att uppn˚a snabbare exekveringstider.
5.1
J¨amf¨orelse med existerande l¨osningar
I Kap 2.1 redovisades tv˚a existerande l¨osningar s˚asom Amazon-go[11] och self-checkouts generellt. Produkten Smart Cart har sina f¨or- och nackdelar i j¨amf¨orelse med de andra produkterna. Amazon-go ¨ar en revolutio- nerande teknik men ber¨akningskapaciteten och lagringskapaciteten s¨atter gr¨anser p˚a projektets utvidgning till st¨orre butiker, vid fall Amazon ¨ar villiga att dela med sig av tekniken. Utvecklarna bakom Amazon-go har inte avsl¨ojat kostnaden f¨or alla kameror, sensorer och serverunderh˚all men det ¨ar betydligt dyrare ¨an kostnadsf¨orslaget (Kap 1.6.1) f¨or detta projekt.
Sj¨alvscanningen och sj¨alvutcheckning har brister och s˚arbarheter i j¨amf¨orelse med Smart Cart. Sj¨alvscanningen f¨orhindra inte kunder fr˚an att l¨agga oskannade varor i vagnen. D¨armed anst¨aller butiker personal f¨or att utf¨ora slumpm¨assiga kontroller, vilket inte ¨ar n¨odv¨andigt med Smart Cart. Smart Cart s¨akerst¨aller att alla varor ¨ar skannade och registrerade, butiken sparar p˚a l¨onekostnader f¨or kassapersonal. Sj¨alvutcheckning ¨ar i sig smartare l¨osning ¨an Sj¨alvscanningen, d˚a en integrerade v˚ag ¨ar implementerad. V˚ag noggrannheten ¨ar 2g vilket ¨ar 1g h¨ogre noggrant ¨an vad detta examensarbetet har ˚astadkommit. F¨ordelen med Smart Cart ¨over Sj¨alvutcheckning ¨ar att butiken sparar utrymme p˚a att inte ha statiska sj¨alvutcheckning stationer, ist¨allet kan butiken utvidga sitt sortiment.