En vindebromodell med bilkontrollsystem basert på indusert spenning i spoler - Instrumentering TFY4190

Transkript

1 En vindebromodell med bilkontrollsystem basert på indusert spenning i spoler - Instrumentering TFY4190 Irene Bakken, Magnus Dahle Institutt for fysikk, NTNU, N-7491 Trondheim, Norge Mai 2013 Sammendrag Det har i dette prosjektet vært konstruert en fysisk modell av en vindebro. Systemet benyttet spoler for å kunne registrere når magnetiske biler kjørte inn på/av broen ved å måle og evaluere indusert spenning i spolene. Modellen i seg selv fungerer relativt godt, men systemet er åpenbart upraktisk i virkeligheten, da spolene krever at bilene er sterkt magnetiske, at de kjører jevnt og over en viss hastighet. Innhold 1 Innledning 1 2 Teori 1 3 Materiale og metode Numerisk modell Fysisk modell Labveiw-kode Main PeakDetector Resultater 6 5 Diskusjon 6 6 Konklusjon 8

2 1 Innledning Prosjektet er en undersøkelse av hvorvidt spoler kan brukes til å registrere forbikjørende lekebiler i en modell av en vindebro. Ideen baserer seg på at et magnetiskt objekt med en hastighet v relativt til en spole, vil indusere en elektrisk spenning, ε, i spolen. Denne elektromotoriske spenningen vil være avhengig av bilens hastighet, og spolens størrelse, form og antall viklinger. Hensikten med prosjektet er å lære seg å planlegge, utføre og dokumentere et eksperiment, samt å benytte seg det man har lært om programmering i LabView og bruk av DAQ. 2 Teori For å kunne registrere om en bil passerer et gitt punkt i veibanen, utstyres bilen med en permanent magnet, slik at bilen med hastighet v, vil indusere en spenning ε i en spole med N viklinger. Den induserte spenningen beskrives utelukkende av Faradays lov [1], ε = N d B(r, t) da (1) dt der B(r, t) er den magnetiske flukstettheten og integralet gjøres over flaten utspendt av spolens tversnitt. Signalet fra spolene leses kontinuerlig av en DAQ-apperatur 1. DAQ-en fungerer hovedsaklig som et bindeledd mellom et analogt signal og en datamaskin, og oversetter signalet til binær, digital kode [2]. 3 Materiale og metode 3.1 Numerisk modell Av henhold til teorien i seksjon 2, utføres en numerisk simulering av en permanent magnet med konstant hastighet gjennom en spole. Denne modellen er laget ved bruk av programmeringsverktøyet python, og viser henholdsvis indusert spenning i spolen som funksjon av magnetens posisjon relativt til spolen, og den maksimale induserte spenningen som funksjon av magnetens hastighet i figur 1a og 1b. S (a) Viser indusert spenning som funksjon av magnetens posisjon, med konstant hastighet v = 20cm/s. (b) Viser den induserte spenningen fra figur 1a sitt toppunkt, som funksjon av hastighet, v. Figur 1: Simuleringen antar spolen som sirkulær med radius R = 5cm og med N = 100 viklinger. Samtidig er spolen plassert i xy-planet med infinitesimal utstretkning i z-retning. Magneten antas også som infinitesimal med konstant hastighet langs z-aksen gjennom spolens sentrum, og med styrke m = 1ẑ Tm Fysisk modell Den fysiske modellen vises i figur 2, og består av to papptårn forbudnet av to separate bilbaner i papir, hver bane med to spoler av oppviklet kobberledning. For den ene veibanen (veibane 1) har man laget en rampe slik at bilen ved slipp får stor nok fart til å kunne trille helt gjennom begge tårnene. Broen 1 Data acquisition 1

3 heves og senkes manuelt ved hjelp av en tråd. I det ene tårnet har man over høyre veibane (veibane 1) festet en grønn og en rød lysdiode som angir om bilene kan kjøre eller ikke. Bilen som er benyttet er en liten modell av en Lamborghini Gallardo, med en påfestet permanent magnet. DAQ-enheten er av typen DAQ NI USB-6211 fra National Instruments. (a) Viser det helhetlige systemet og koplingen til DAQenheten via koblingsbrettet. (b) Viser plassering av spolene, og øvrige koplinger inne i brotårnet. Figur 2: Viser den helthetlige fysiske modellen og koplinger. For å kunne gi en vurdering av modellen og spolenes anvendelighet, ble det gjort systematiske tester hvor det ble notert antall vellykede bilgjennomkjøringer og om systemet telte riktig antall biler. Statistikken er ført i tabell 1, under seksjon Labveiw-kode Programmets hovedoppgave er å holde styr på hvor mange biler som har passert gjennom hvilke spoler. En bil detekteres ved at mange nok målinger av spenningen indusert i spolen er over en viss verdi. Programmet styrer også signalene som sendes til lysdiodene, slik at det lyser grønt når man kan kjøre over broen og det blinker rødt når man vil stanse bilene så broen kan heves (og mens broen blir hevet/senket). En lampe på frontpanelet i Labview vil lyse grønt når broen skal heves. Se figur 3. Figur 3: Del av frontpanelet i LabView med knappen Ship o-hoi som indikerer at det kommer et skip som vil gjennom, og en lampe Hev bro som lyser grønt når broen skal heves. Her settes også verdiene for paramtere som treshold y, Width limit og High Speed Threshold som forklares i seksjon 3.3.2, samplingrate og kanalene på DAQ-en som signalene hentes inn på. 2

4 3.3.1 Main Koden til hoveddelen av programmet, main, er vist i sin helhet i figur 4. I ruten helt til venstre bestemmes hvilke målinger som skal gjøres av den tilkoblede DAQ-en; den måler spenningen med en valgfri samplingsfrekvens (default: 1500 Hz) på fire valgfrie kanaler (default: ai8,ai1,ai2,ai3 ). Figur 4: Labview-kode til hoveddelen av programmet, main, som styrer biltellingen, lysdiodene og om broen kan heves eller ikke. Dataene sendes inn i en tidsbestemt whileløkke som repeterer seg selv hvert 0.1 sekund inntil man terminerer løkka ved å trykke på stopp-knappen. Dataene som sendes inn samles derfor opp i en todimensjonal tabell med en rad for hver kanal og rundt 0.1 samlingsfrevens kolonner hvor målte verdier fylles inn. Den todimensjonale tabellen deles opp i fire endimensjonale tabeller med verdier fra hver kanal. Se figur 5. Innholdet fra disse fire tabellene blir vist i fire grafer i frontpanalet (eksempel vist i figur 9) og analyseres hver for seg med delprogrammet PeakDetector (hvit boks med rød bølge på), som avgjør om det har passert en bil eller ikke. Før analysen legges siste del av tabellen fra forrige iterasjon inn foran de nye måledataene. Lengden av denne tabellen som legges inn er varierende, av grunner forklart i seksjon PeakDetector sender ut 1 eller 0 når den henholdsvis oppdager/ikke oppdager en bil innenfor sine måledata for én kanal. (Se seksjon for flere detaljer.) Shift-registre holder styr på hvor mange biler som totalt har blitt registrert på hver kanal. Antallene fra to og to kanaler sammenliknes for å sjekke om det er bil(er) på broen eller ikke. For veibane 2 trekkes simpelthen de to tallene fra hverandre før de sammenliknes med null, men for veibane 1 ble det oppdaget en tendens til at spole UT-1 registrerte to biler der det bare var én. For å kompensere for denne feilen, testes det for om antall biler på broen 3

5 Figur 5: Del av main, se figur 4, som viser hvor den to-dimensjonale tabellen deles opp i fire 1D tabeller, og koden for biltelling for de to spolene i veibane 1. If-strukturen fjerner en bil fra spole UT-1 sin opptelling dersom det er et negativt antall biler på broen. i veibane 1 er negativt. Hvis det er det, rettes dette opp ved å trekke fra den ekstra bilen i biltellingen for veibane 1. Se figur 5. En boolsk variabel som er sann / falsk når det tomt for biler på broen eller ikke, sendes inn til delprogrammet Broheving (boks med bilde av vindebro), som også tar inn en bool som forteller om det er et skip som ønsker å passere eller ikke (ship o-hoi). Dersom det er ønskelig og klart for å heve bro, så sender Broheving ut en bool med verdi sann. Hvis det ikke er noen skip som skal passere eller det er biler på broen, er verdien falsk. Denne verdien visualiseres i frontpanelet som en lampe som lyser grønt/slukner når broen skal/ikke skal heves. Verdien av ship o-hoi sendes også til delprogrammet Trafikklys (hvit boks med prikker og et? - tegn), som sender ut signaler til to kanaler på DAQ-en. For at ship o-hoi er falsk, sendes et jevnt 5V-signal gjennom kanal ao1 og 0V gjennom kanal ao0. Dette gir et jevnt lys i den grønne dioden og intet lys i den røde. For ship o-hoi sann, sendes 0V gjennom kanal ao1 og et firkantsignal med amplitude 5V gjennom kanal ao0. Dette gir et blinkende lys i den røde dioden og intet lys i den grønne PeakDetector Koden for delprogrammet PeakDetector er vist i sin helhet i figur 6. Programmet tar inn en 1D tabell data (default: 1x150), og tre skalarer: treshold y, Width limit og High Speed Threshold, hvis verdier er tilpasset den enkelte spole ved empirisk kalibrering. Funksjonen Threshold går gjennom tabellen data og returnerer indeksen til det første stedet med verdien threshold y, eller indeksen til tabellens siste element, dersom den ikke fant noen. Se figur 7. Da Threshold kan returnere et desimaltall som indeks når verdien threshold y ligger midt i mellom to elementer, rundes indeksen opp, slik at det er indeksen til første element med en verdi over threshold y som sendes videre. Funksjonen Array Subset sender videre bare den siste delen av tabellen, fra og med indeksen til første verdi over threshold y. Verdiene i denne tabellen inverteres og sendes inn i funksjonen Threshold2. Denne funksjonen gjør det samme som Threshold, men på grunn av inverteringen gir den oss i praksis indeksen til første element som er under verdien threshold y. 4

6 Figur 6: Labview-kode til delprogrammet peakdetector som analyserer måledataene og avgjør om det har passert en bil eller ikke. Noen detaljer vises i figur 7 og 8. Figur 7: Koden som vises her fjerner den delen av tabellen data som ligger foran første verdi over grensen threshold y og finner indeksen til første verdi under threshold y. Med mindre siste element i tabellen er over threshold y (aka skillet mellom iterasjonene havnet innenfor målingen av en bil), utføres false -versjonen av if-strukturen. Med funksjonen Array Size og noe småkode sjekker man om Threshold2 sendte indeks av siste element videre. Med koden rett nedenfor, som benytter seg av funksjonen Index Array, sjekker man om denne siste verdien var høy nok til å være del av målingen av en bil. Når operasjonene inni false -boksen utføres, se figur 8, splittes først tabellen i to. Den første delen inneholder nå bare verdier over threshold y, mens den andre biten inneholder resten av tabellen. Denne siste biten sendes videre ut til neste iterasjon, så man kan lete etter biler innenfor disse dataene også. Dersom man ikke har noen verdier over threshold y i tabellen data, er det en tom tabell som sendes videre. Tabell-biten med høye måleverdier, måler man lengden av. Man finner også elementet med høyest verdi. Dersom lengden er under den gitte verdien Width limit, antas det at det var støy som førte til de høye målingene. Lengden av tabell-biten må være over Width limit eller man må ha at maksimalverdien er over High Speed Threshold (som er en god del høyere enn threshold y) for at tallet 1 istedenfor 0 skal sendes videre ut til 1 or 0 cars. Det siste alternativet tar for seg tilfeller der en bil kjører så fort at man får en uvanlig høy, smal topp. Det som skjer inni true -boksen (se svart ramme, figur 6) er at ingen biler telles, selv om man i disse tilfellene kanskje er midt i målingen av en bil. Den siste delen av tabellen, fra første element over threshold y og ut, vil alle være over threshold y. Denne biten sendes videre til neste iterasjon, hvor man kanskje eller kanskje ikke legger på mange nok nye punkter over threshold y til at det blir telt som 5

7 Figur 8: Koden som vises her henter ut den delen av tabellen som bare inneholder verdier over threshold y og måler lengden på den, samt finner maksimal verdi innenfor den. Dersom lengden er over Width limit eller maksverdien er over High Speed Threshold, får 1 or 0 cars verdien 1. Ellers 0. Resten av tabellen sendes videre til neste iterasjon. en bil. Denne biten av koden sørger for at dersom halvparten av målingene gjort ved en bilpassering havner i én tabell, mens resten tas med i neste iterasjon, blir det telt som én bil og ikke to eller ingen. 4 Resultater For totalt 113 testkjøringer i veibane 1 ble det notert ned hvorvidt bilen klarte å kjøre gjennom begge tårnene, og i så fall om programmet registrerte korrekt antall biler. Hvis feil antall biler ble registrert, ble type feil notert. Resultatene er vist i tabell 1. Tabell 1: Viser statistikk for de 113 testkjøringene. Bilen kjørte enten rett igjennom, eller kollidete underveis. Man var hovedsaklig interesert i vellykkede gjennomkjøringer og hvorvidt programmet telte riktig antall biler i disse tilfellene. # kollisjoner 51 # vellykkede gjennomkjøringer 62 # tellefeil blant gjennomkjøringene 5 De fem tilfellene der man fikk en tellefeil ved vellykket gjennomkjøring var alle av samme art; da bilen kjørte ut det siste tårnet i veibane 1, fikk man et utslag i spolen i motsatt kjørebane som ble feiltolket som en bil. For en vellykket gjennomkjøring uten noen hindrende kollisjoner, vises et typisk utslag for alle fire spolene i figur 9. Det var ingen problemer med lyssignalene. 5 Diskusjon Statistikken i tabell 1 viser at den fysiske modellen kunne vært bedre konstruert for å få flere vellykkede gjennomkjøringer, men også at for de vellykkede gjennomkjøringer hadde biltellingssystemet en relativt stor feil på 8%. Ved 5 av 61 vellykkede gjennomkjøringer hadde man en tellefeil, men disse fem tilfellene var også identiske. Med bedre valgte verdier av grensen for spenningen threshold y og antall målepunkter over nevnte grense, Width limit, for den aktuelle spolen (spole INN-2), kunne denne feilen vært redusert eller til og med fjernet. Hadde man hatt tid til det, ville man forsøkt å heve threshold y for spolen, og sett om det hjalp. 6

8 Figur 9: Viser utslag i alle fire spolene ved en vellyket gjennomkjøring i veibane 1. Henholdsvis fra toppen, og ned viser grafene signalet fra spole INN-1, UT-1, INN-2 og UT-2, hvor tallet viser til veibanen. INN-1 og UT-2, befinner seg i det første tårnet, UT-1 og INN-2 i det andre tårnet. Ved for lang kjøretid av programmet er det mulig at kan det oppstå uhensiktmessig kræsj som følge av minnelekasje. Dette har ikke blitt opplevd, men programmet leser signalene fra spolene kontinuerlig og analyserer dataene fortløpende. Analysen foregår inni en tidsinstilt while-loop, og kommer dataene inn raskere enn de behandles, kan det tenkes at det kan oppstå problemer. Programmet er også utsatt for diverse støy. Først bakgrunnsstøy, som blir tilnærmet neglisjerbar relativt til styrken på signalet. Deretter støy som følge av variable hastighet av bilen. Fordi den induserte spenningen er direkte avhengig av tidsendringen i den magnetiske fluksen gjennom spolen, se likning 1, vil endringer i bilens hastighet ha stor påvirkning på signalet fra spolen. I vår modell er bilen er utsatt for uregelmessig oppbremsningen som følge av kollisjon med veggene rundt, samt ujevnheter i selve veibanene. Dette fører til at det resulterende signalet ikke vil se ideelt ut som som illustrert i figur 1a, men heller ha flere lokale topppunkter. Dette korrigerer programet for ved å kontrollere at vi må ha en mengde data over threshold y forklart i seksjon 3.3.2, for at signalet skal gjenkjennes som en bil. Feil oppstår likevel dersom det er tilstrekkelig med støy eller en såpass ujevn hastighet på bilen at signalets toppunkt deles i to eller flere brede topper. Er man riktig uheldig, kan både flere eller ingen av disse toppene tolkes som en bil, slik at man får flere eller ingen biler registrert der det bare kjørte én igjennom. Det ble nevnt i seksjon at spole UT-1, i det siste tårnet for veibane 1, ofte telte to biler. Det skyldtes at man akkurat her ofte fikk to brede topper per bil. Det ble rettet opp i dette ved å sjekke om man hadde et negativt antall biler på broen, en noe svak løsning som avhenger at det bare er én bil på broen av gangen. Dette er altså kun en løsning som fungerer for den konkrekte, fysiske modell bygget for dette prosjekt, og som man ikke ville benyttet seg av dersom man hadde som hensikt å bygge en realistisk modell. Lokale topper innenfor signalet fra én bil, kan sees i graf nummer tre fra figur 9. 7

9 Parameteren High Speed Threshold brukes som nevnt i seksjon til å håndtere biler som kjører så fort at antall målepunkter over threshold y blir for få i forhold til Width limit. Denne biten av programmet kunne vært fjernet da det ble laget en rampe som gjør at bilene kjørte i omtrentlig samme hastighet hver gang, men siden den er et viktig element i de tilfellene da hastigheten varierer mer, og den ikke var i veien, ble den ikke fjernet. High Speed Threshold må være valgt ganske høy, da bare ett punkt over denne grensen er nødvendig for å registrere det som en bil, noe som gjør den svært sårbar ovenfor støy rundt grensen. Da man gjorde valget av sensorer for bilregistreringen, valgte man spoler av nysgjerrighet framfor brukervennlighet. Det var klart fra første stund at det for bilregistrering i virkeligheten ville være et urelastisk valg, da en slik spole i virkeligheten måtte være stor nok til å også slippe gjennom store kjøretøy som trailere. Kostnadene for å bygge fire slike spoler istedenfor å benytte andre typer bevegelsessensorer, er antakelig nok i seg selv til å forklare hvorfor de ikke ville blitt brukt. Det tviles også på om en vanlig bil, og for å ikke snakke om små kjøretøy som mopeder, ville være magnetiske nok til å gi tydelige utslag. Underveis i prosjektet ble man også klar over andre problemer, som støyen nevnt i forrige avnsnitt. Det at man må kjøre over en viss hastighet, gjør at systemet ville vært ubrukelig ved første tegn på kø. Det ble ikke testet hvordan tellesystemet ville fungere for to biler som kjørte tett innpå hverandre, men det er sannsynlig at dette ville medføre til nye problemer som ville måttet blitt tatt hånd om. Dersom man hadde hatt tid, skulle man gjerne ha funnet bilens hastighet idet den passerte gjennom en spole. Denne skal enkelt kunne bli beregnet ved å studere toppunktet til den induserte spenningen. Av figur 1b, ser vi at det ideelt sett er en linær sammenheng mellom den indusertespenningens toppunkt og objektets hastighet. Systemet vil derfor kunne estimere farten på bilen ved ett målepunkt, i motsetning til fotoceller som vil kreve to. Man kunne også beregnet gjennomstnittshastigheten over broen ved å notere seg tidspunktet hver bil passerte den enkelte sensor. Automatisk kontroll av broheving med en liten motor og bevegelsessensorer til å registrere innkommende/fraseilende skip var andre utbedringer av modellen som ble vurdert, men ikke gjennomført. 6 Konklusjon Modellen i seg selv var ganske vellykket. Dens største feil var den store sannsynligheten for at bilen ikke klarte å kjøre rett igjennom, som var konstruksjonen av modellen sin skyld. Tellesystemet som var programmert i LabView og tilpasset modellen, fungerte relativt bra med en statistisk feil på 8%. Modellen kunne muligens med flere tester og et par innstillinger vært bedre. Modellen er ikke realistisk og er ikke ment å være det. Det er først og fremst valg av sensorer som gjør det slik, da spolene krever at bilene er sterkt magnetiske, kjører jevnt og over en viss hastighet. Ulemper som at spolene måtte vært veldig store, og antakelig kostbare i forhold til andre løsninger, kommer i tilegg. Altså vil bruk av spoler for å registrere gjennomkjørende, magnetiske lekebiler ikke være den beste løsningen. Referanser [1] Griffiths, David J. - Introduction to Electrodynamics. Third edition, San Francisco, [2] Div. forfattere - TFY4190 Insturmentering. Trondheim,