Fysiska komponenter

Detta avsnitt avser beskriva de förväntningar och uppnådda resultat kring systemets fysiska komponenter. Detta innefattar systemets träffyta och Raspberry-enhet, samt den precision som systemet uppnår med dessa komponenter.

5.2.1 Träffyta

I uppdragsgivarens kravspecifikation beskrevs ett system innehållande en träffyta, i form av en tavla (se bilaga A.2). På denna yta skulle användarträffar registreras av monterade mikrofoner. Systemet förväntades därför från projektutvecklarnas håll innehålla en sådan träffyta, men i kravspecifikationen framgick det inte om träffytan skulle förses av uppdragsgivaren eller monteras av projektutvecklarna; under ett av de regelbundna återkopplingsmöten som hölls med uppdragsgivaren framgick det att en träffyta kunde förses om utvecklingen lyckades hinna nå en punkt där en sådan ansågs nödvändig.

Ingen sådan träffyta försågs eller monterades i slutändan; de omonterade mikrofonkomponenterna (se Figur 5.1) kopplades istället direkt till systemets Raspberry-enhet. Ljudankomster till mikrofonerna registreras, och signaleras genom en av deras portar binärt till enheten.

Figur 5.1: Omonterade, numrerade mikrofoner, samt en markerad träffpunkt p

5.2.2 Raspberry-enhet

Enheten läser med hjälp av en applikation in mikrofonernas binära signaler som representerar de ljudankomster de registrerar, som sedan mäter tidsintervall utifrån dessa. Dessa tidsintervall omvandlas med hjälp av multilaterationsberäkning till approximerade positioner där träffar antas ha träffat.

När dessa komponenter testas med upprepade träffar på samma position p (se Figur 5.1) visar sig dessa uppmätta tidsintervall, samt den ljudankomstordning som registreras utifrån de mottagna signalerna inte vara konsekventa nog mot vad som antas bör gälla utifrån upprepade sådana försök. I bilaga B finns resultat där både ankomsttider och ankomstordning fluktuerar mellan träffarna. Dessa resultat visar att de fysiska systemkomponenter som försetts från projektstarten inte är precisa nog, och att själva resultaten således är opålitliga.

5.2.3 Systemets precision

Systemets precision misstänktes redan i kravspecifikationen vara undermålig med endast en implementerad Raspberry-enhet (se bilaga A.2.1). Dessa prestandabrister förväntas en TDC kunna uppväga, genom att registrera de signalerade ljudankomsterna från mikrofonkomponenterna snabbare och mer precist. Detta skulle i sin tur leda till mer exakta approximationer av användarträffar. En sådan enhet placeras då mellan träffytan och Raspberry-enheten, som illustreras i den utökade systemdesignen i Figur 5.2.

Figur 5.2: Utökad design av det elektroniska skyttesystemet

5.3 Molnet

Detta avsnitt avser beskriva de förväntningar och resultat kring de systemkomponenter som är knutna till molnet. Detta innefattar det API som bryggar applikationen i Raspberry-enheten och databasen, samt den databas som skapats som en molntjänst i Azureportalen.

5.3.1 API

Ett API behövde placeras mellan Raspberry-enheten och databasen, då enhetens UWP-applikation inte självmant kan ställa SQL-förfrågor. API:t har således i uppgift att ta emot HTTP-begäranden från enheten, och skicka respektive SQL-förfråga till databasen; denna uppgift uppfylls i nuläget.

5.3.2 Databas

Enligt uppdragsgivarens kravspecifikation ska vissa mätvärden sparas i en SQL-databas (se bilaga A.2). I specifikationen finns inga preferenser om databasen ska vara en molnlösning eller en lokal sådan. Under projektet togs därför beslutet utifrån jämförelser mellan lösningarna (se avsnitt 3.5.1) att databasen skulle skapas som en molnlösning i Azureportalen. En sådan databas skapades, och är i nuläget kopplad till systemet. I databasen finns möjlighet att spara och hämta ut data i relevanta delar av systemet. Denna data består av träffentiteter innehållande en träffs x- och y-koordinater, den identitet kopplad till enheten som skickat datan, samt det nummer i träffordningen som träffen innehar.

5.4 Visningsklient

I uppdragsgivarens kravspecifikation finns en önskan om att en visningsklient utvecklas. Visningsklienten fick utvecklas med vilken teknik som helst under Microsoft-plattformen (se bilaga A.2.2), så ett antagande gjordes därefter att utveckla den som en WPF-applikation. Enligt kravspecifikationen skulle visningsklienten beräkna en träffs approximerade position på träffytan (se bilaga A.2.2); eftersom detta under projektets gång valdes att hanteras i Raspberry-enhetens applikation sker således inte detta i visningsklienten. Ytterligare utvecklingsoptioner gavs i kravspecifikationen (se bilaga A.2.4), och visningsklienten uppfyller i nuläget de två första: den har möjlighet att visualisera träffar och beräknade träffresultat i sitt användargränssnitt. Utöver detta beräknar applikationen ett medelresultat för alla träffresultat, samt medelkoordinater för alla träffar. Dessa koordinater används för att visualisera en medelträff tillsammans med övriga träffar i användargränssnittets träffyta; de beräknade resultaten presenteras i två resultatrutor i användargränssnittet.

Figur 5.3 illustrerar den slutgiltiga visningsklienten. Flera röda träffar samt en gul medelträff visualiseras i dess träffyta, och tillhörande träffresultat presenteras i en lista till höger om träffytan. Notera att det presenterade medelresultatet är skilt från medelträffen; medelresultatet beräknas utifrån träffresultat, och medelträffen utifrån träffkoordinater.

Figur 5.3: Illustrerad visningsklient

Visningsklienten kunde testas innan hela systemet kopplades ihop genom att hämta simulerade träffvärden från databasen som ursprungligen skickats dit från en utvecklad testapplikation. Denna applikation delar utseende och viss funktionalitet med visningsklienten. Testapplikationen kan, genom att en användare positionerar träffar i dess träffyta, utläsa de simulerade träffarnas koordinater och skicka dessa till databasen tillsammans med en bestämd enhetsidentitet samt det nummer träffen innehar i träffordningen.