Inledning

Denna del innehåller en produktundersökning av programmeringsbiblioteket OpenCV, för användning till pro- grammering av ett visionsystem. Till detta används en webbkamera av konsumentklass.

Syfte

Syftet med undersökningen är att undersöka hur OpenCV är att arbeta med, samt hur pass sannolikt det är att detta kan komma till nytta vid programmeringen av mässdemonstratorns visionsystem. Till detta används en webbkamera av konsumentklass för att försöka minska projektets kostnader, dvs. en webbkamera med lägre noggrannhet gällande färg, kvalitet, och uppdateringshastighet.

3.3.2 Undersökning

Undersökningen innebar att ett program byggdes för att detektera en tennisboll mot en bakgrund bestående av mestadels olika nyanser av vitt, i den lokal som undersökningen ägde rum i. Genom olika algoritmer maskas den bild som webbkameran tar, för att endast lämna tennisbollen kvar i bilden, så att dess position kan bestämmas. Webbkamera

Specikationerna för den webbkamera som användes vid undersökningen listas nedan. ˆ Emtec W1300SN Snake

ˆ Upp till 1024x768 pixlars upplösning (interpolerad). 640x480 pixlar bildsensor, vilket användes i under- sökningen.

ˆ Uppdateringsfrekvens upp till 30 bildrutor per sekund

Just denna kamera har sämre färgupptagningsförmåga, vilket kan vara en nackdel i fallet med mässdemonstra- torn. Den gulgröna färg som en tennisboll har, uppfattas genom kameran mer som gråblek grön.

Datorns inverkan

De för undersökningen relevanta specikationerna för den dator som användes vid undersökningen listas nedan. ˆ Dell Inspiron I6400

ˆ Intel Centrino Duo T2400 processor på 1.83GHz ˆ 987MHz busshastighet

Då kameran ger en bild på 640x480 pixlar med tre färger om vardera åtta bitars djup, blir det totalt 921'600 byte som skall processas i era steg, 30 gånger per sekund, för att komma upp i kamerans maximala uppdaterings- frekvens. Det innebär ett rent dataöde på 27'648'000 byte per sekund för en enda operation. Detta motsvarar 220 Mbit/s. Det bör dock bäras i åtanke att det är ertalet operationer som behöver utföras innan datorn kan tolka koordinater ur bilden. Till exempel måste systemet fungera i olika ljusförhållanden utan alltför stora om- ställningar. Detta kräver ltrering som klarar mer än bara ett specikt fall, och därmed även är mer krävande än ett specikt lter. Det är mycket information som skall processas på kort tid, varför processorhastighet och busshastigheter bör vara höga för att ej få sådana askhalsar. Man bör således vara försiktig med att välja en kamera med för hög upplösning.

Programmering med OpenCV

Ett program för spårning av en tennisboll skrevs för att testa den erbjudna funktionaliteten. Runt om den kod som sköter bildbehandlingen nns även kod för att hålla koll på uppdateringsfrekvensen, både för stunden samt den maximala samt minimala frekvensen under den senast gångna sekunden. Denna information presenteras i samband med den resulterande videoströmmen för att avgöra systemets reaktionsförmåga och snabbhet mer exakt än genom visuell uppskattning.

Programuppstart Först och främst initieras och allokeras minnesplatser för variabler och bilddata, därefter associeras en fångstenhet för video med programmet. Denna fångstenhet måste kunna detekteras av värdope- rativsystemet för att den skall kunna användas av OpenCV. Fönster öppnas för presentation av bilddata. I undersökningens fall presenteras den ursprungliga bilden, så som den kommer från fångstenheten, samt den bearbetade bilden.

Fångst av bildruta Som första steg i loopen för bildbehandling, skall en ny bildruta läsas in från fångstenhe- ten. Därefter kopieras denna bildruta till en extra minnesplats för att möjliggöra beräkningar utan att påverka ursprungsbilden. Dessutom skapas plats för ytterligare två bildrutor. En av dem för en bild i gråskala av samma dimensioner som ursprungsbilden, samt en för en wire-frame representation av bilden senare.

Färglter Den implementation av färglter som användes var en egenutvecklad variant som inte är speciellt sostikerad. Detta betyder att den mycket väl kan göras snabbare, men information om detta har ej vart funnen i någon dokumentation om OpenCV. Denna lösning kontrollerar pixel för pixel om en vald kanals färg är dominerande, så när som på tio enheter. I detta fall användes grön kanal. Dvs. om det är mer grönt än blått eller rött i en pixel, så lämnas denna pixel orörd. Är det mer rött eller blått än värdet för grönt minus tio, så nollställs alla värden för den pixeln vilket resulterar i svart. Då det är åttabitars färgvärden, blir det ett intervall på 0-255, och gränsen på tio enheter motsvarar därmed ca. 1/25-del av färgskalan.

Färgkonvertering När en viss färg har maskats ut, kan bilden konverteras till gråskala. Detta reducerar mängden data till en tredjedel, då två färgkanaler utelämnas. Även om konverteringen tar på resurserna, sparas resurser in på vidare hantering av bilden efter detta steg, då det är mindre data att ta hand om. Dessutom fungerar inte alla OpenCV's funktioner på bilder med mer än en kanals färgdjup. Ett par av dessa funktioner behöver nämligen användas efter detta steg.

Tröskelvärdeskonvertering För att underlätta igenkänning av objektet ytterligare, görs bilden som var i gråskala om till svartvit. Detta görs i två steg, det första tar bort de pixlar som är mörkare än ett specikt värde. Detta för att maska bort detaljer i bilden som är mörkt gröna, då tennisbollen har en ljusgrön nyans. I det andra steget tas alla kvarvarande pixlar som är ljusare än ett annat värde bort. Detta för att ta bort en del brus som uppkommer i bilden. Kvar nns ett intervall mellan de satta värdena, som nu alla har samma intensitet.

Erodering För att ytterligare ta bort oönskade detaljer ur bilden, läggs ett eroderande lter på. Detta minskar ytan på de fält som nns kvar efter tröskelvärdeskonverteringen. Nu försvinner ytterligare delar av det brus som kan förekomma. Tennisbollen har en storlek som relativt bruset är så pass stor att denna inte påverkas nämnvärt av detta lter.

Kantdetektering När större delen av bruset är borttaget körs en kantdetektering på den återstående bilden. Denna lämnar en wire-frame som märker ut konturerna på de kvarvarande objekten.

Cirkeldetektering När ltrering och omvandling till wire-frame har utförts, kan cirkeldetektering ske. Detta använder en av OpenCV tillhandahållen algoritm som är relativt krävande gentemot de andra stegen i program- met. Hur lång tid detta steg tar, beror på hur många kanter det nns i den bild som används i detekteringen, en viktig anledning till att ta bort så mycket brus som möjligt innan detta steg. Med dålig ltrering gjorde detta steg att den totala uppdateringsfrekvensen sjönk till närmare 0.2 bildrutor per sekund. Det är fem sekunder mellan var bildruta! Detta är alldeles för långsamt för mässdemonstratorn.

Presentation Slutgiltigt presenteras informationen för användaren. De två fönster som tidigare öppnas, upp- dateras nu med data om dels ursprungsbilden, dels bilden av den wire-frame som genererats. Detta för att göra det möjligt att jämföra dem två för att kunna förbättra algoritmerna. Information om bildrutefrekvensen presenteras även, likväl ritas en ring in i originalbilden för att markera positionen för den cirkel som upptäckts.

3.3.3 Resultat

OpenCV kan mycket väl vara en lösning till det visionsystem som behövs till mässdemonstratorn. Det är mångsidigt och kongurerbart genom att du som programmerare väljer parametrar, ordningsföljd, samt även kan konstruera egna funktioner genom den åtkomst som OpenCV ger till bildobjekten. Mycket användbar funktionalitet nns att implementera, även om inte allt av detta utnyttjades till fullo i denna undersökning. Exempel och tips nns att tillgå från personer som delar med sig av sina kunskaper på Internet.

Diskussion

Det står klart att detektering av cirklar eventuellt ej är rätt väg att gå. Med tennisbollen i kamerans synfält, var bilduppdateringsfrekvensen nere på fem bildrutor per sekund, eller lägre. Det kan fungera bättre med någon typ av blob-detektering, vilket dock ej testades under denna undersökning. En sådan detektering nner större områden med samma färgvärde, istället för cirkeldetekteringens geometriska undersökning. En blob-detektering torde vara snabbare och mindre resurskrävande.

Vidare stod det klart att bildbehandlingen är en resurskrävande uppgift. Aktivitetshanteraren på den da- tor som användes vid undersökningen visade på hög utnyttjandegrad av processorns båda kärnor, särskilt då cirkeldetekteringen utförs. För att få uppdateringsfrekvens på 30 bilder per sekund behövs förvisso optimerad kod, men då mässdemonstratorn ej kommer att benna sig i en kontrollerad miljö måste koden klara av de uktuationer som kan uppstå i form av till exempel ljusförhållanden. Detta kan föra med sig en långsammare kod, vilket då kan viktas upp med ett snabbare system att köra koden på.

I viss mån kan miljön kontrolleras, genom att kameran riktas mot en kontrollerad bakgrund, lämpligen den fångstutrustning som används. Dock kvarstår att olika ljusförhållanden kan få den boll som används att framträda i olika nyanser.

Dessutom hade den vid undersökningen använda webbkameran så pass dålig färgåtergivning att ljusare nyanser av färger i vissa fall övergick till en ljusgrå nyans.

Slutsats

Till projektet med mässdemonstratorn kan OpenCV mycket väl användas, programmeringsmässigt nns poten- tialen. Den webbkamera som användes lämnar dock önskemål om bättre färgåtergivning, för att bättre skilja färger åt, över hela färgskalan, och därmed bättre kunna hantera variationer i belysningen. En upplösning runt 640x480 är önskvärt med avseende på hanterbar datamängd.

Den relativt låga uppdateringsfrekvensen som uppnåddes med programmet i undersökningen, kan säkerligen förbättras något med bättre algoritmer. Dock tillkommer det kod runtom för beräkning av motorhastigheter och positionsangivelser för dessa. Dessutom skall data läsas in från utrustningen runt om, i form av ändlägesgivare och nödstoppssignal. Dessa tillägg tar också på systemets prestanda, varför processorhastigheten på den dator som systemet skall köras med bör överstiga de 1,83 GHz som datorn i undersökningen kördes på. Undersök- ningsdatorn hade dubbla kärnor, vilket den slutgiltiga datorn även den borde ha. Även minnesresurserna kan spela roll vid behandling av de datamängder som sker, även operativsystemet skall yta på bra i bakgrunden. Undersökningsmaskinens RAM-minne om 1 GB får således ses som ett minimum.

Rekommendation

Följande komponenter rekommenderas således: ˆ OpenCV

ˆ PC-dator med minikrav:

 2 GHz+ med dubbla kärnor  2 GB+ RAM-minne Addendum

Efter undersökningens avslut framkom ett alternativ till webbkamera i Playstation Eye. Playstation Eye är en kamera specikt framtagen för bildtolkning i Sony's spelkonsoll Playstation 3. Den är kapabel att mata ut 60 bildrutor per sekund vid 640x480 pixlar och 120 bildrutor per sekund vid 320x240 pixlar. Drivrutinerna som är framtagna för anslutning till Windows är freeware vid anslutning av 1 - 2 kameror. Anslutning av era kameror kostar pengar. Drivrutinerna ger tillgång till manuell kontroll av kamerans alla parametrar så som bildstorlek, bildhastighet, skärpa, vitbalans, och slutartid. Detta är funktioner som åternns också i industriella kameror men som tyvärr saknas på de esta konsument-webbkameror.

Kapitel 4

Modell

4.1 Övergripande design

Systemet skall kunna ta emot en boll som kastas mot det. Detektering av bollen sker med hjälp av en kamera monterad framför personen som kastar bollen, riktad mot hårdvaran som skall ta emot bollen.

4.2 Mekanisk design

Systemet bygger på en enda lång sluten rem som drivs av två fasta motorer. Detta till skillnad från ett tradi- tionellt x/y-system där motorerna till axel 1 och 2 arbetar var för sig med sin egen axel, och axel 1 måste ytta vikten av både axel 2 och dess motor. I gur 4.2 syns det hur de två motorerna samarbetar för att åstadkomma rörelse i x- och y-led. När de båda drivna hjulen roterar åt samma håll rör sig nyttolasten i x-led, när de roterar åt varsitt håll rör sig lasten i y-led.

En rotation av det ena hjulet två 'steg', kan likställas med att båda hjulen först roterar ett steg åt samma håll och sedan ett steg åt varsitt håll. Ur detta kan man härleda att lasten rör sig ett steg i x-led och ett steg i y-led om bara det ena hjulet rör sig. Med hjälp av arctan(1 steg/1 steg) fås 45 grader. Det visar sig alltså att det går att konstruera ett koordinatsystem med frikopplade axelrörelser om man lutar det 45 grader mot remmarnas riktning istället för att lägga det parallellt med dem.

Stommen till den mekaniska konstruktionen består till stora delar av aluminiumproler av märket Kanya PVS - Basis 50. Det är ett prolsystem som med hjälp av ett ankarsystem är väldigt lätt och snabbt att montera ihop, med en insexnyckel som enda nödvändiga verktyg. Den rörliga delen av konstruktionen består av tre linjärskenor/vagnar av märket Lineartrace T-Race Monorace 28, ett system bestående av stålskenor och vagnar med hjullager för låg friktion. I gur 4.3 syns det hur det rörliga systemet är monterat i stommen. I guren syns även hur motorerna med sina drivande hjul och de xerade resp. rörliga hjulen är monterade. Motorerna är av typen JVL MAC-800; en trefas motor med inbyggd encoder och kraftelektronik. Observera att guren visar konstruktionen från baksidan för att exponera alla detaljer.

4.3 Elektrisk design

Den elektriska designen delas upp i signal och kraft, för att tydliggöra de olika områdena.

4.3.1 Signaldistrubution

Kommunikation mellan dator och motorer sker via RS232 gränssnitt. Ett separat gränssnitt per motor säkerstäl- ler att adressering ej skall ställa till det för motorernas rörelser. Kameran för visionsystemet ansluts via USB. Övrig kommunikation mellan datorn och systemet sker med parallellporten via ett egenutvecklat I/O kort för givare och kontaktorer.

Större delen av all den kommunikation som förekommer i systemet, sker med 24 V signaler. Positionsgivarna är av Reed-typ och optiska. De har inbyggd elektronik och indikering, och ger ut en positiv signal vid aktivering. Denna signal tas in på åtta av de tio parallella ingångar som PIO-kortet tillhandahåller. Kontaktorernas status kan detekteras via de två kvarvarande ingångarna. Till detta används en normalt öppen hjälpkontakt per kontaktor för att även detektera kabelbrott. I fallet med nödstoppet indikerar detta utlöst nödstopp, varefter systemet stoppas. Ett av nödstoppen placeras på styrskåpet, det andra vid kameran utanför enheten.

Figur 4.1: Övergripande design

F Frirullande hjul (xerad position)

D Drivande hjul - kopplade till varsin motor (xerad position)

R Rörliga hjul - rörliga i förhållande till F och D men xerade i förhållande till varandra X X-axel - den påförda rotationen och den resulterande rörelsen i x-led

Y Y-axel - den påförda rotationen och den resulterande rörelsen i y-led Figur 4.2: Principbeskrivning av system med lång rem.

Figur 4.3: Stommen till det mekaniska systemet.

Figur 4.5: Kraftdistrubution.

En av de utgångar som PIO tillhandahåller, styr kontaktorn för motors-ON, dvs. den kontaktor som kon- trollerar spänningssättningen av motorerna i andra hand efter nödstoppskontaktorn. Datorn kan dock ej styra kontaktorn direkt, utan signalen måste först konrmeras manuellt med hjälp av nollspänningsbrytaren, som en extra säkerhetsåtgärd. Den andra utgången styr den lampa som indikerar att styrdatorn vill aktivera motorerna. På detta vis kan olika signaler ges vid olika tillstånd  ett blinkande ljus då styrdatorn vill aktivera motorerna, samt ett fast sken när de är aktiverade.

Utlöst nödstopp indikeras även med en lampa på styrskåpet. Även styrdatorn kan läsa av och meddela nödstoppens status.

4.3.2 Kraftdistrubution

Systemet matas av 230 V enfas växelspänning. Matningen antas vara avsäkrad för 10 A alternativt 16 A. Internt delas systemet upp i två individuellt avsäkrade delar för att minimera risken att överström till motorerna får den externa avsäkringen att utlösas och därmed släcka ned hela systemet.

Kraftmatningen till motorerna passerar först nödstoppskontaktorn för att säkerställa att kraften till dem kopplas från vid nödstopp. Därefter passerar de motors-on kontaktorn för att det ej skall gå att aktivera moto- rerna utan en tillkopplad styrdator.

Motorernas elektronik matas med en separat 24 V likspänning för att motordata skall bibehållas i intakt form trots spänningsbortfall i 230 V-matningen som följd av nödstopp. Denna 24 V matar även givare och kontaktormanövrering via PIO kortets högnivåsida.

Styrdatorn matas från samma säkring som PSU'n för 24 V, och matar i sin tur kameran via USB, samt lågnivåsidan av PIO kortet med 5 V.

4.4 Mjukvarudesign

Mjukvarudesignen delas upp i visionsystem, hårdvarugränssnitt, och användargränssnitt. Samtlig mjukvara skrivs i språket C, med hjälp av utvecklingsmiljön Microsoft Visual Studio 2008 Professional Edition.