5.5.5
Diskussion och slutsatser
I tabell 5.13 kan man se att den ursprungliga algoritmen fungerar bra i lera av de testade driftfallen, dock inte i alla. Dess svagheter ses tydligt i igur 5.10c där snrär mycket låg, vilket leder till att algoritmen inte lyckas följa rätt frekvens. Kalmaniltret däremot, klarar av alla de åtta accelerationsförlopppen med låg rmsei samtliga fall.
Även exekveringstiden hos Kalmaniltret är bättre än hos den ursprungliga im- plementationen, detta mycket tack vare de nya fönsterfunktioner som används till FFT funktionen. Det går dock inte att dra slutsatser utifrån detta resultat om hur detta kommer att påverka exekveringstiden på en androidtelefon.
5.6
Effektberäkningar
För att undersöka resultatet av effekt beräkningarna med den framtagna algorit- mer testades just detta.
5.6.1
Utrustning
Experimentet utfördes i en 5-cylindrig Volvo V70 med en androidtelefon som in- spelningsenhet. Mer information om den använda bilen inns i tabell 5.6, där in- formationen är hämtad från Transportstyrelsen (2013). Enbart en androidtelefon användes vid detta experiment och den kan ses i tabell 5.14. MATLAB användes för att analysera den insamlade ljuddatan.
Tabell 5.14: Telefon som användes vid experimentet.
Tillverkare Modell Android version
HTC One X 4.1.2
5.6.2
Metod
För att beräkna den effekt som producerats av fordonet omvandlades den mål- följda frekvensen till hastighet och acceleration genom de ekvationer som anges i avsnitt 3.2.3. Accelerationer med maximalt gaspådrag spelades in för varje växel, inspelningen av accelerationsförloppen skedde enligt avsnitt 5.2.3.
5.6.3
Resultat
Den maximalt beräknade effekten för varje accelerationsförlopp ses i tabell 5.15.
5.6.4
Diskussion och slutsatser
Enligt tabell 5.6 kan fordonet som användes i detta experiment maximalt produ- cera en effekt av 147 kW vilket motsvarar knappt 200 bhp. Som synes i tabell 5.15 är resultatet av effektberäkningarna skilda mellan de olika accelerationsförlop- pen, trots att en kurva som väl motsvarar hastigheten har tagits fram för samtliga utom för det accelerationsförlopp som utfördes på 1:ans växel. Anledningen till
52 5 Deluppgifter
Tabell 5.15: Beräknad maximal effekt hos de inspelade accelerationsförlop- pen med maximalt gaspådrag.
Växel Beräknad effekt
[bhp] 1 11.9 2 114.6 3 168.5 4 88.9 5 67.7 6 52.4
de undermåliga effektberäkningarna är ej fastställt och en vidare utredning bör genomföras, till exempel genom att jämföra utdatan med den som kan erhållas från ett obd-uttag. En annan källa till att det blir en lägre beräknad effekt än vad som angivits av tillverkaren är att luftmotståndet ej tagits i beakt vid dessa beräk- ningar. Vidare är den effekt som anges i databladet från tillverkaren av motorn den effekt som motorn producerar, alltså inte den effekt som för fordonet framåt, då förluster i kraftöverföringen till hjulen gör så att den effekt som för fordonet framåt blir mindre än den angivna effekten för motorn.
Del III
Implementation och resultat
6
Implementation och resultat
I detta kapitel beskrivs hur funktionen för stft samt hur algoritmen för lermåls- följning med Kalmanilter har implementerats i Android. Varje del har egna av- snitt för resultat och diskussion.
6.1
Uppbyggnad
I ett första utförande körs målföljningen efter det att all ljuddata har samlats in, men en viktig del i designen var att det skulle kunna gå att använda sig av de klasser och funktioner som implementeras för att målföljningen i framtiden skulle kunna ske i realtid.
Ett förenklat lödesschema över hela målföljningssystemet ges i igur 6.1.
Inspelning görs och sparas till il
Inspelning läses från il med hjälp av en buffert En fönsterfunktion arbetar på datan Datan proces- seras av stft Lokala maximum för varje fft extraheras Målföljning med Kalmanilter
Figur 6.1: Flödesschema över hela målföljningssystemet.
56 6 Implementation och resultat
6.1.1
Bibliotek
Den ursprungliga implementationen använde sig av de externa biblioteken • AChartEngine (4ViewSoft (2013)) för visualisering av data,
• Commons Math (Apache Commons (2013)) för polynomanpassningar och • JTransforms (Wendykier (2013)) för fft.
Inga nya bibliotek har lagts till i denna implementation.
6.2
Korttidsfouriertransform,
STFT
För stft utvecklades klassen AudioSTFT vars Uniied Modeling Language (uml) visas i igur D.4. AudioSTFT består två separata delsystem, inläsningsbuffert och fönsterfunktioner, och fft görs med hjälp av klassen DoubleFFT_1D från bibli- oteket JTransforms.
6.2.1
Inläsningsbuffert
För att undvika att läsa in samma data från telefonminnet lera gånger imple- menterades en cirkulär buffert för mellanlagring. En cirkulär buffert är en imple- mentation av en kö av typen först-in-först-ut (fifo) och har bland annat följande fördelar:
• tidskomplexiteten för att i bufferten – på valfri plats hämta ett element, – ta bort det första elementet samt – lägga till ett nytt element sist
är O(1), där en ordinär buffert ibland måste skifta ned sina värden till bör- jan av buffertminnet till en kostnad av O(n), vilket lämpar sig bra för en producent/konsument-struktur på användningen av bufferten
och bland annat följande nackdelar: • det är svårare att utöka storleken,
• rumskomplexiteten är O(n + 1) mot O(n) och
• tidskomplexiteten för att ta fram värdet för ett index är fortfarande O(1), men med större magnitud
gentemot en ordinär buffer.
6.2.1.1 Implementation
Android har givetvis lertalet implementationer av köer, till exempel (Android api, 2013, ArrayBlockingQueue), men dessa gjorda för objekt och inte för arrayer innehållande den primitiva datatypen double som fft-funktionen i JTransform
6.2 Korttidsfouriertransform, stft 57 har som inparameter. Det inns även ett antal buffertar implementerade, men ingen av dem är av cirkulär typ. På grund av dessa anledningar implementera- des CircularBufferDouble, vars uml kan skådas i igur D.3, för att se om en prestandaförbättring kunde uppnås.
Algoritm 6.1 För att validera om den egna implementationen av en cirkulär buf- fert gav bättre prestanda användes följande algoritm för varje bufferttyp och för ett antal olika α. För testerna var N = 10000, Nlength= 214och α = 16n ∈[1, 16].
1: buffer ← intialization(Nlength)
2: startTime ← currentTime()
3: for i ← 1 to N do
4: buffer ← buffer.addData([newDataToBuffer])
5: output ← buffer.getData()
6: buffer.discardOldData(α)
7: totalTime = currentTime() - startTime
För att jämföra de olika klassernas prestanda som cirkulära buffertar programme- rades ett testprogram där alla klasser agerade som sådana. Testalgoritmen som står till grund för jämförelsen mellan den egna implementationen, (Android api, 2013, ArrayBlockingQueue) och en ordinär (Android api, 2013, DoubleBuffer), ges som pseudokod i algoritm 6.1. För att minska påverkan av bakgrundspro- gram så kördes testerna av de olika bufferttyperna i samma huvudloop.
6.2.1.2 Resultat
I tabell 6.1 ges resultatet av testerna gjorda med algoritm 6.1. Resultaten är nor- maliserade på medelvärdet av tiden som testerna gjorda på den cirkulära buffer- ten tog. Då alla buffertarna presterade linjärt med överlappet α ges medelvärdet och standardavvikelsen σ i tabellen.
Tabell 6.1: Resultatet av en tidsjämförelse mellan olika bufferttyper. Värdena är normaliserade på medelvärdet av körningarna gjorda på
CircularBufferDoubleoch ger därmed enhetslösa resultat.
Buffert Normaliserat medelvärde σ
CircularBufferDouble 1.00 0.07
DobuleBuffer 0.60 0.04
ArrayBlockingQueue 11.85 0.08
6.2.1.3 Diskussion och slutsatser
Det visade sig tydligt att den av författarna implementerade cirkulära bufferten inte hade samma prestanda som DoubleBuffer. Den kod som användes för an- passa en DoubleBuffer till en cirkulär buffert används vid vidare implementa- tion.
58 6 Implementation och resultat
endast inns funktioner som hanterar enstaka datum i dess gränssnitt, medan de andra klasserna har funktioner optimerade för arrayer av data.
6.2.2
Fönsterfunktioner
Innan en dft görs i stft kan man välja att multiplicera datan med en fönster- funktion.
6.2.2.1 Implementation
Även om resultaten i avsnitt 5.3 visar på att ett rektangulärt fönster ger bra resul- tat så skapades en klasshierarki med tre gränssnitt, två abstrakta klasser och ett antal konkreta implementationer för olika fönster. Klasshierarkin gör det även möjligt att enkelt lägga till nya fönsterfunktioner vid behov, utan att förändra de programavsnitt som använder sig av gränssnitten. Strukturen av hierarkin kan ses i igur D.1.
AbstractWindowtillsammans med WindowInterface är grundpelarna i hie-
rarkin och alla fönsterfunktioner utgår från dessa. Den abstrakta klassen imple- menterar de triviala tilldelnings- och hämtningsfunktionerna för fönsterlängden och en konstruktor som sätter fönsterlängden, men lämnar implementationen av själva fönsteralgoritmen vars resultat returneras av getWindowValues till un- derklasserna.
GeneralizedHammingWindowInterfaceutökar det förra gränssnittet och till-
sammans med AbstractGeneralizedHammingWindow, som är en underklass till AbstractWindow sätter de upp en struktur för familjen av generaliserade hammingfönster. GeneralizedHammingAbstractWindow implementerar sin fönsteralgoritm och den konstruktor som sätter de nya parametrarna α och β.
RectangluarInterfaceär ett tomt gränssnitt. Fastän gränssnittet är tomt har
det en funktion; det möjliggör för stft att hoppa över multiplikationen av datan men att den övriga strukturen av algoritmen är densamma.
6.2.2.2 Resultat
Utöver veriiering av resultaten av getWindowValues mot motsvarande fönster- typer i MATLAB har inga övriga tester gjorts.
6.2.2.3 Diskussion och slutsatser
Hierarkin fungerar som förväntat och gör det enkelt att utöka antalet konkreta fönstertyper och nya fönsterfamiljer.
Placeringen av PeriodicHann och PeriodicTukey i hierarkin kan ifrågasät- tas. Då båda fönstertyperna har ett generaliserat hammingfönster som del av sin fönsteralgoritm, fanns det två alternativ:
• låta klasserna vara underklasser till AbstractWindow och implementera algoritmerna i varje klass för sig eller
6.3 Detektionsextrahering 59