Sammendrag Denne rapporten beskriver hvordan gruppen gikk fram for å fullføre MAS 306 Bachelorprosjekt i mekatronikk 2015. Hovedoppgavens problemstilling omhandler design og produksjon av kameraplattform, motorkontroll ved bruk av sensordata fra Oculus Rift DK2 (OR), stereosyn ved hjelp av to separate kameraer, trådløs kommunikasjon mellom kameraplattform og OR. Tilleggsoppgavens problemstilling omhandlet fastslåelse av dybde i stereobildet fra kameraene. Kameraplattformen ble designet i SolidWorks og produsert i separate deler på skolens 3D-printere. OR var koblet til en datamaskin, mens kameraplattformen med tilhørende motorer og kameraer var koblet til en annen datamaskin. Alt av kommunikasjon mellom disse og deres tilkoblede enheter ble gjort via LabVIEW og et lokalt nettverk. Hovedoppgaven ble fullført, mens tilleggsoppgaven kun ble delvis utført. Tidsbegrensningen gjorde at vi ikke fikk utført alt vi ønsket av funksjoner og mulige forbedringer som gruppen oppdaget underveis. Oppgaven var utfordrende på grunn av den store bredden av temaer, og gruppen har brukt mye tid på å sette seg inn i forskjellige emner i tillegg til å lage det ferdige produktet. 1 Kapittel 8 Implementering Dette kapittelet gir informasjon om motor, kameraer og Oculus Rift DK2 (OR) som er brukt i oppgaven. Hvordan det mekaniske designet er bygd opp, samt utvikling og mulige forbedringer av mekaniske deler blir omtalt. Videre beskrives oppkobling av OR og motorene. Hvordan signaloverføringen fungerer og hvordan kontrollere kamerainnstillingene. Til slutt beskrives kalibreringsprosessen av avstandsmåleren og hvordan den fungerer. Figur 8-1 Kameraplattform 83 8.1 Komponenter 8.1.1 Motor Figur 8-2 Dynamixel MX-64T Dynamixel MX-64 er en servomotor som egner seg bra til styring av roboter (Figur 8-2) [100]. Dynamixelen har tilbakekoblingssystem for både hastighet, temperatur, posisjon, spenning og belastning. I tillegg benyttes en PID kontroll algoritme. Denne kan justeres individuelt for hver servo slik at hastigheten og styrken av motorens respons kan kontrolleres. All sensorstyring og posisjonskontroll håndteres av servoens innebygde mikrokontroller. Dynamixel MX-64 er utstyrt med motoren Maxon RE-MAX [1]. Motoren kan drives med 14.8 V, 12 V eller 11 V. Den har mulighet til 360° kontinuerlig rotasjon med 4096 ulike posisjoner, noe som gir en oppløsning på 0.088°. Dynamixelen benytter TTL (Transistor-Transistor Logic) som kommunikasjonsprotokoll og en COMhastighet på 8000bps ~ 3 Mbps. Laveste driftstemperatur er oppgitt til å være -5°C (Tabell 8-1). Full spesifikasjonsliste kan sees i manualen [100]. Tabell 8-1 Dynamixel MX-64T Dynamixel MX-64T Vekt 126 kg Størrelse 40.2 x 61.1 x 41.1 Materiale Metall gir og plastikk ramme Operativ vinkel 360◦ Maksimal strøm 4.1 A ved 12V Spenning (anbefalt) 12V Maksimalt moment 6 Nm Temperaturgrense -5°C til 80°C 84 8.1.2 Kamera Det ble utlevert et Minoru 3D Webcamera (Figur 8-3). Dette kameraet har to VGA 640x480 CMOSsensorer. Orienteringen og oppløsningen på sensorene oppnår ikke kravene til OR, hvor det trengs to bilder i portrettformat med oppløsning på 1080x960. Figur 8-3 Minoru 3D [101] Senere ble det kjøpt inn to USB2 Microsoft LifeCam Studio (Figur 8-4). Dette kameraet har en fin form som kunne benyttes enkelt uten modifiseringer. Sensoren til kameraene er en OmniVision OV2710 [102] [103] [104] CMOS-sensor med en oppløsning på 1920x1080, som er tilstrekkelig til hva som trengs til OR. Maksimal bildefrekvens for kameraet er 30 bilder per sekund. Field Of View (FOV) er oppgitt til å være 75°. Kameraene roteres 90° slik at korrekt orientering, i forhold til Riftens skjerm, oppnås. Figur 8-4 Microsoft LifeCam Studio [105] 85 Kameraet har automatiske innstillinger, men det kan også styres manuelt med National Instruments Measurement & Automation Explorer (NI MAX) og i LabVIEW (Se Kapittel 8.6). På grunn av begrensninger med programvare og overføringshastighet er det blitt valgt 960x540 med 30 bilder per sekund. Dette gir en bitrate på 373 248 000 b/s i et ukomprimert bilde. Dette er den høyeste oppløsningen som ga en grei bildestrøm. Benyttet video mode er YUY2, som også var eneste valg på den utleverte datamaskinen med Windows 8.1. På maskiner med Windows 7, hadde man flere valg. Kameraet har en nedre driftstemperatur på 0°C [106]. 8.1.3 3D-brille Figur 8-5 Oculus Rift DK2 Oculus Rift DK2 er en type 3D-brille som ble utviklet for bruk til virtual reality i dataspill. OR inneholder akselerometer, gyroskop og magnetometer med en oppdateringshastighet på 1000 Hz, samt et optisk posisjonsestimerings-system med en oppdateringshastighet på 60 Hz [107]. Den optiske posisjonsestimeringen består av et infrarødt kamera med en oppløsning på 752x480 piksler og et nett av 40 infrarøde dioder som ligger under skallet på OR [108] [109]. Sammen gjør sensorene det mulig å fastslå brillenes orientering. OR mottar bildet via en HDMI-kabel, ellers sendes alt av data via USB 2.0. Skjermen i OR er en 5.7 " super AMOLED skjerm, med en oppløsning på 1920x1080, dette er den samme man finner i smarttelefonen Samsung Galaxy Note 3 [108]. Skjermbildet deles i to, noe som gir 960x1080 piksler på hvert øye [107]. Horisontal synsvinkelen er oppgitt til å være på 100o [107]. Den opprinnelige oppdateringshastighet på skjermen er 60 Hz, men OR overklokker denne til 75 Hz slik at et bilde med mykere bevegelse kan oppnås, noe som er med å redusere simulator sickness [108] [107]. 86 8.2 Mekanisk design Kameraplattformen består av en roll/pitch/yaw enhet som styres av tre servomotorer (Figur 8-6). Stort sett er alle delene til plattformen produsert i plast med en 3D printer. Motorene festes til delene med M3 30 mm skruer. Motor 3 Motor 2 2 stk kamerafester med underplate Roll Bolt Glideplate Pitch Fordypning for lodd Yaw Base m/ Motor 1 Figur 8-6: Kamerarigg 3D modell Designvalget er inspirert av gimbalsystemer, hvor hver ring tillater rotasjon rundt en bestemt akse. De fleste gimbalsystemer ser ut som en rekke konsentriske ringer, men det kan også være forskjellig utstyr som dreier rundt en akse [110]. Se Figur 8-7. 87 YAW PITCH ROLL . Figur 8-7: Gimbalsystem [110] Ved å montere kameraene til midten av dette systemet, kan man få dem til å peke i hvilken som helst retning uavhengig av hvordan det omkringliggende miljøet beveger seg [111]. Kameralinsen kan da rotere rundt dens eget gravitasjonssenter, og man får en myk bevegelse når objekter i bevegelse skal følges. Figur 8-8: Oculus Rift rotasjonsakser Figur 8-8 viser rotasjonsaksene til Oculus Rift når den er i bruk. For å få kamerabevegelsen til å være mest mulig lik hodebevegelsen, bygges kameraplattformen opp med tanke på å få kameraene til å rotere om samme akse. Se Figur 8-9. 88 YAW YAW Motor 2 Kamerafeste ROLL PITCH Motor 3 Z Z Motor 1 Y Motor 1 X Figur 8-9: Kameraplattform med rotasjonsakser Tyngdepunktet på kamerariggen er ikke helt sentrert på grunn av vekten av de tre motorene. Størst belastning vil være på aksen til motor 1, derfor er det laget en fordypning i konstruksjonen der man kan legge inn et lodd for å kompensere dersom det viser seg å bli nødvendig. Se Figur 8-6. I bunnen av basen er den en 21x21x4 mm stålplate med et ¼-20 BNC hull for å kunne monteres på kamerastativer (se Figur 8-10). Figur 8-10 Stativfeste 89 8.2.1 Utvikling og forbedring av mekaniske deler I starten av prosjektet skulle delene til riggen lages i sin helhet på fakultetets 3D-printere. Det ble derfor lagt kopier av metalldelene fra Robotis i plast. For å kompensere for en eventuell svakhet i plasten, ble tykkelsen på servohornene økt. Dette var ikke en god løsning. Første servohorn i plast (Figur 8-11) hadde for stort avvik i diameter for aksel. Dette medførte at skruen som går inn i motoraksel og fester hornet til motoren, måtte strammes ofte fordi bevegelsene til motor løsnet skruen. Det endte med at skruen ble presset inn i plasten. Denne delen er laget av plasttype ABSpluss og har lav tetthet for å spare materialbruk. Konstruksjonsmetoden fungerer bra til store deler der mye materiale kan spares. Til små deler, som Figur 8-11, hvor en skrue skal strammes mot plasten, bør en tettere konstruksjonsmetode benyttes. Alternativt kan flaten skruen strammes mot, forsterkes med en metallskive som fordeler lasten. Figur 8-11 Ødelagt plastservohorn En ny del med dimensjon lik akseldiameter på motor ble designet og printet på en ny og mer høyoppløselig 3D-printer (Figur 8-12). Selv om indre diameter er den samme som akseldiameteren, løsnet delen. Dette skyldes mest sannsynlig myk plast, torsjonskrefter og last fra de andre komponentene. 90 Figur 8-12 Plastservohorn og mellomdel. Første del er grå, nummer to til venstre, og den siste bakerst To servohorn i metall ble kjøpt inn, en til hver av motorene med størst moment, roll og yaw. Siden panoreringsdel og rotasjonsdel allerede var produsert og tilpasset de tykke plastservohornene, ble en mellomdel som servohornet i metall kunne festes på designet. Den tredje delen til rotasjonsdelen, vises i Figur 8-13 og Figur 8-14. Denne delen har tre forskjellige skruefester/hull. Figur 8-13 Servohorn i metall og mellomdel Figur 8-14 Servohorn underside 91 På kanten, nærmest servohornet, er det laget et hull som fester servohornet til mellomdelen med M2 10 mm bolter. Øverst er det fire hull hvor skruestenger (M3 30 mm) limes fast, disse låser mellomdelen fast til rotasjonsdelen (roll). I midten er det et hull ned til skruen som fester delen til motoraksel (M3 20 mm). I Figur 8-15, vises metallskive med mellomlegg påmontert motor 2 (roll). Figur 8-15 Servohorn med mellomdel påmontert motoraksel Panoreringsdelen har ikke en mellomdel i plast, men en liten metallskive for å kompensere for skruelengden. Metalldelen er montert direkte på panoreringsdelen (yaw). 8.2.2 Kameraholder Kameraplattformen ble designet med tanke på 1/30-del regelen for interaksial avstand. Se kapittel 4.2.1, formel (4.5). Det ble konstruert en kameraholder som sitter på en plate der avstanden mellom kameralinsene kan varieres fra 45 mm til 100 mm (Figur 8-16). Avstanden til nærmeste objekt som gir bra 3D opplevelse kan da varieres fra 1350 mm til 3000 mm. 92 100mm 45mm Kamerafeste Kamerafeste Glideplate Glideplate Figur 8-16: Interaksial avstand 8.3 Oppkobling av Oculus Rift DK2 OR leveres med to sett linser, et IR posisjonskamera, og tilhørende kabler. I originalinnpakningen medfølger det et ekstra linsepar som kan benyttes dersom man er nærsynt. Det er ferdig montert to kabler i brillene som er samlet sammen i en streng. Midt på strengen finnes en boks der kamera og strøm kobles til. De to kablene fra brillene er en HDMI og en USB. Ved spillgrafikk anbefaler Oculus å koble HDMI kabelen til en stasjonær PC med et eget dedikert skjermkort (ikke integrert i hovedkortet), mens USB kabelen kan kobles til en valgfri port [112]. For live video er ikke eget skjermkort like viktig. IR-kameraet kobles til med en USB-kabel. Mellom kamera og boksen på OR ledningenes streng kobles sync-kabelen (se Figur 8-17). For at OR skal fungere, trengs softwaren Runtime. Det kan lastes ned fra Oculus VRs nettsider1. I oppgaven ble versjon 0.4.4 brukt. 1 https://developer.oculus.com/downloads/ 93 Figur 8-17 Oppkobling av Oculus Rift DK2 I LabVIEW hentes positurinformasjon med et Virtual Instrument (VI) som ble gitt av veileder (Figur 8-18). I programmet «motorTCPsender» (Figur 8-27) blir disse verdiene hentet som lokal variabel fra OR-sekvensen (Figur 8-18), sendt inn i en «Format Into String»-block og sendt videre til server med TCP-kommunikasjon. Dette programmet gjør ikke noe annet enn å sende dataene mottatt fra OR. Behandling blir gjort av «motorTCPmottaker» (Figur 8-28). 94 Figur 8-18 Utlevert vi/dll, roll, pitch og yaw blir hentet av TCP-loopen. Se kap 8.5.1 95 8.4 Oppkobling av motorer For å benytte Dynamixel MX-64, trenger man en strømforsyning på 11, 12 eller 14,8 V, USB2Dynamixel, SMPS2Dynamixel og 3P-kabler. Robotis anbefaler en spenning på 12 V [100]. Oppkoblingen gjøres på følgende måte: Sett Dynamixel USB2 i en ledig USB-port, åpne «device manager». Finn enheten under «ports». Velg avanserte innstillinger på denne enheten, under BM options, settes Latency Timer til 1 msec. Denne reduksjonen medfører at responshastigheten til USB2Dynamixel og motorene går hurtigere [113]. Last ned RoboPlus fra robotis.com2. I oppgaven er versjon 1.1.3.0 brukt. Koble så til en motor og strømforsyningen som vist på Figur 8-19. Strømadapteren kan også plassert mellom USB2Dynamixel og motoren. Figur 8-19 USB2Dynamixel, MX-64, SMPS2Dynamixel I RoboPlus, under expert, velg dynamixel Wizard, søk etter motorene. Benytt DXL 1.0 og basic search, man kan også velge den baudraten som benyttes for å spare tid (Figur 8-21). 2 http://www.robotis.com/xe/download_en 96 Motorene kobles til èn og èn, kontroller at de responderer og gi dem et ID-nummer. Når alle er kontrollert og gitt en unik ID, kan de kobles i serie, kalt en daisy-chain som i Figur 8-20. Kontroller at alle blir identifiesert og kan kontrolleres i RoboPlus. Motorene skal vises slik som i Figur 8-22. Figur 8-20 Motorer koblet i daisy-chain Figur 8-21 RoboPlus motortilkobling 97 Figur 8-22 RoboPlus motorstyring 8.4.1 Motorens Virtual Instrument og kobling til Oculus Rift For å kontrollere motorene i LabVIEW, kan et eksempel fra National Instruments brukes som utgangspunkt. Last ned dynamixelsyncwrite.zip3. Åpne filen Dynamixel RX-Series Sync Write.vi, velg antal motorer, baud-rate og comport. Motorenes vinkel kan nå styres i LabVIEW (Figur 8-23). Figur 8-23 Opprinnelig kontrolpanel for motorstyring i LabVIEW. 3 http://ftp.ni.com/pub/devzone/tut/dynamixelsyncwrite.zip 98 Dette eksempelet er opprinnelig tilpasset Dynamixel RX-serien. Disse motorene har andre spesifikasjoner enn MX-motorene som benyttes. Blant annet har RX en oppløsning på 1023-step og rotasjonsvinkel fra 0° til 300° mens MX har 4095-step og kan rotere fra 0° til 360°. Under POSsubVIen endres verdiene slik som vist i Figur 8-24. Figur 8-24 Posistion_sub.vi Dynamixelen ble koblet opp i LabVIEW etter guide fra National Instuments (NI) [114] . I denne koden ble motorene styrt manuelt, mens oppgaven gikk ut på å få OR til å styre motorene. Dynamixel controll ble derfor koblet fra og en matrise med 3 utganger lagt til. Verdier for roll, pitch og yaw sendes med TCP og hentes med en lokal variabel (Figur 8-25). Signalet ut fra OR er i radianer, dette gjøres om til grader ved å dele på pi og legge til forsterkning og forskyvninger slik at motor får ønsket posisjon. Her ble det forøkt ulike verdier for å se hva som medførte best respons. Både pitch og roll motorene går i utgangspunktet i motsatt retning i forhold til OR. Dette ble løst ved å bytte fortegn på multiplikasjonsblokken. Verdiene i addisjon og multiplikasjonsblokkene er valgt etter empiriske forsøk. Multiplisering med -180 er valgt for roll og pitch, mens 250 er valgt for yaw da denne ikke klarte å bevege seg tilstrekkelig ved en innstilling på 180. Addisjonsverdien brukes for å sette kameraplattformen i rett utgangsposisjon. Når riggen har uønsket posisjon, for eksempel om rotasjonsdelen er 45° forskjøvet når OR står vannrett, kan denne endres til posisjonen er korrekt. Verdiene ble satt til 168 for roll og 198 for pitch og yaw. Med normale hodebevegelser viste det seg at bevegelser i ytterkant medførte uønsket og brå vinkelendringer på motorene. Tester uført ved å bevege hodet i ulike posisjoner viste at reaksjonen kom ved OR-verdier på over 1 radianer og under -1 radianer. Det ble lagt inn en «in range and coerce» blokk hvor x-min ble satt til -1 og x-max ble satt til 1. Verdier innenfor dette intervallet returnerer verdien koblet til «true», mens verdier utenfor returnerer verdien koblet til «false». Dette medfører at bevegelser utenfor intervallet ikke påvirker motorenes bevegelse, men blir stående i loopen å vente på verdier innenfor intervallet. 99 Figur 8-25 Lokale variable hentes fra TCP-mottaker (se Figur 8-28) 100 8.5 Signaloverføring Forskjellige internettprotokoller er valgt fordi de har ulike fordeler og ulemper (se Kapittel 6). Det er benyttet TCP for å sende posisjonsdata fra OR til motorene og UDP for å sende video fra kameraene til OR (Figur 8-26). Pakkene med motordata er små og vi er avhengige av at dataene kommer korrekt frem til motorene, fremfor en lav responstid. Til videooverføring er det valgt UDP fordi hastigheten til overføringen har høy prioritet. Forsinkelser på over ett sekund vil skape ubehag hos operatør. Bildehastigheten prioriteres derfor fremfor oppløsningen. Server Videosignal Stereo kamera UDP Sender Styresignal TCP Mottaker Motor 1 Motor 2 Motor 3 Klient Videosignal UDP Mottaker TCP Sender Oculus Rift OR dll Sensorsignal Figur 8-26 Oversikt over datakommunikasjon 101 8.5.1 Transmission Control Protocoll, overføring av motordata Det er tatt utgangspunkt i eksemplene fra National Instruments, Simple TCP – Sender og Receiver. Den første blokken, TCP Listen, venter på at klienten skal koble seg til. Port er portnummeret som serveren sender, benytter til kommunikasjonen. Dataene fra akselerometeret og gyro går inn i en Format Into String. Lengden på strengen blir lest og sendt først. I den neste blokken sendes strengen til nettverket (Figur 8-27). Figur 8-27 Sender av motordata, lokale variabler hentes fra OR (Se Figur 8-18) TCP Open knytter mottakeren (klient) til senderens (server) adresse og port. Den første TCP Readblokken leser lengden på strengen, denne lengden går så inn på neste TCP Read. Denne forteller hvor mye data som skal mottas. Utgangen til den andre TCP Read, går inn i en Scan From String, denne deler strengen opp i tre utganger som tilsvarer dataene fra roll, pitch og yaw-bevegelsene. Her er det viktig å kontrollere at rekkefølgen er den samme som ble sendt. Blokkdiagrammet for mottaker av motordata sees i Figur 8-28. Figur 8-28 Mottaker motordata. Variablene hentes av motorene 102 For å redusere internett-trafikk, bruker LabVIEW, Nagles Algoritme. Nagles algoritme er en av de grunnleggende algoritmene som ved å kombinere mange små pakker til en stor. Følgene av denne algoritmen er en forsinkelse på dataene hvor små pakker sendes frem og tilbake. Det er mulig å deaktivere denne algoritmen ved å gjøre følgende [115]: Noter IP-adressen til maskinen. Åpne REGEDIT. Under HKEY_LOCAL_MACHINE, finn SYSTEM\CurrentControlSet\services\Tcpip\Parameters\interfaces Velg den mappen/NIC-ID som hare n ip-adresse som samsvarer med pcens adresse Legg til to nye DWORD verdier. Kall dem TCPNoDelay og TcpAckFrequency. Rediger dem og gi dem verdien 1 (på/høy). Logg Registry Editor og ta en omstart på datamaskinen [116] [117]. 8.5.2 User Datagram Protocol, overføring av video Figur 8-29 viser VI for sender og Figur 8-30 VI for mottaker. UDP Open, åpner den porten man sender signalet med. I UDP Write sendes dataene som en streng til en spesifisert IP-adresse og hvilken port mottakeren har åpnet. IP-adressen til mottaker kan ses ved å bruke kommandoen ipconfig i Commando Prompt på mottakermaskinen. Figur 8-29 Sender av video I UDP Open, settes porten man skal motta dataene på. I UDP Read settes den maksimale størrelsen på antall bytes som skal leses. Det er også satt en time-out-verdi. Er det ikke mottatt noen pakker på 5000 ms, avsluttes tilkoblingen. 103 Figur 8-30 Mottaker, bilde 8.6 Kontroll av kamerainnstillinger Kameraene som brukes har mulighet for kontroll av kamerainnstillinger. For å styre innstillingene, trengs to «property nodes», en for å definere hva som skal styres og en for å sette ønsket verdi. Noden utenfor loopen setter hva som skal kontrolleres og noden innenfor kontrollere verdien/nivået. I den første parvise «property noden», settes attributten CameraAttributes::focus::value. Om man ønsker å styre en annen innstilling, byttes «focus» ut med den attributten som tilhører hva man ønsker å styre. Navnet på disse attributtene kan sees i NI MAX. De fleste kameraer har automatisk tilpasning av kamerainnstillinger. I 3D-filming, er det essensielt at begge kameraene har de samme innstillingsverdiene. Lysstyrke, kontrast og hvitbalanse styres derfor manuelt på begge kameraene. For at fokus skal være likt på begge kameraene, settes det ene kameraet som master og det andre som slave. Verdien på master-kameraet leses av og skrives til slave-kameraet i LabVIEW-programmet. Kombinasjonen av master og slave, kan også brukes på de andre innstillingene. Eksponeringstiden settes manuelt i NI MAX til en slik verdi at bildet er skarpt og uten sløring. Dette kan til tider føre til undereksponerte bilder. Lysstyrken kompenserer for undereksponeringen. Ved veldig høye lysstyrkeverdier, oppstår det støy i bildet. Dette kan unngås ved å benytte ekstra belysning eller ved å endre eksponeringsverdien. 104 Det er opp til brukeren hvilke verdier som velges, hvor kameraene er plassert, hvilke lysforhold posisjonen har og hva som observeres. En ulempe med å introdusere styring av innstillingene, er økt forsinkelse på loopen. Det ble observert økt forsinkelse når lysstyrkeverdien ble økt. I Figur 8-32 vises VI-en som styrer kameraene. Denne er tilpasset for lokal styring. Skal styringen foregå via TCP, må en TCP loop som i Figur 8-28 benyttes på mottaker siden, det vil si kamerasiden. Indikatorene byttes til lokale variabler, på samme måte som med motorene. På operatørsiden benyttes tilsvarende loop som i Figur 8-27. Merk at i motordata er det tre verdier mens for kameraverdiene brukes fire. For å sende mer enn tre, øk input til n verdier som skal sendes (Figur 8-31). I tillegg må «format string» endres. «%f %f %f \00» gjelder for tre verdier hvor %f definerer antall verdier. I Figur 8-33 til Figur 8-38, vises eksempler på forskjellige kamerainnstillinger. Figur 8-31 Format into string function 105 Figur 8-32 Kamerastyring 106 Figur 8-33 Høy lysstyrke ved lav eksponering gir støy Figur 8-34 En optimal eksponering med lite støy Figur 8-35 Lav contrast Figur 8-36 Høy kontrast Figur 8-37 Lav fargetemperatur Figur 8-38 Høy fargetemperatur 107 8.7 Kalibrering for avstandsmåling Til kalibreringen av kameraene er det benyttet programfil fra Márk Szabó [118]. Denne ble benyttet da National Instruments eksempel, Calibrate Stereo Vision System, fungerte dårlig. Dette programmet er svært likt National Instruments eksempel-vi, Calibrate Stereo Vision System. Det ble forsøkt å kalibrere med denne, men dette medførte problemer. Ved oppstart av VI-en velges kameraene som skal benyttes. Disse må være plassert horisontalt. Kalibrering med roterte kameraer, slik som benyttet på kameraplattformen, fungerte ikke når avstandsmålingen skulle utføres. Et ark med fargede prikker benyttes. Avstanden mellom prikkenes senterpunkt oppgis i centimeter (Figur 8-39). Figur 8-39 Instillinger for kamerakalibrering I neste fane utføres kalibreringen. Her angis antall bilder man ønsker å ta. Både venstre og høyre kamera visers på to skjermbilder. Det er viktig at alle prikkene på arket er med i første bilde. Bildene tas med forskjellig posisjon, vinkel og avstand mellom arket med prikkene, og kameraene. Etter at bildene er tatt, markerer man den samme prikken i begge bilder. Om kalibreringen er vellykket, lagres en kalibreringsfil som inneholder kalibreringsdataene. Ble kalibreringen mislykket, blir ikke filen lagret og en indikator for utilstrekkelig data vil aktiveres i fanen resultater. I den samme fanen finnes fokallengden, det optiske senteret til kameraene oppgitt i piksler, kvalitetsrangeringer på kalibreringen, Max. Rectification Error, Max. Projection Error og Rectification Quality (Figur 8-40). Oppløsningen under kalibreringen er satt til 640x360 av programskaperen, det ble forsøkt å endre denne, uten hell. 108 Blokkdiagramet for kalibrerings VI-en kan sees i vedlegg 2. Figur 8-40 Resultat fra kamerakalibreringen, med omtrent 6,7cm interaksialavstand 8.8 Avstandsmåling Programmet for avstandsmåling er basert på Márk Szabó’s program [118] [119] [120]. Kalibreringsfilen fra kapittel 8.7 lastes opp. Denne filen inneholder rotasjons, essential, fundamental og Q-matrisene, samt translasjonsvektoren. Disse matrisene kan sees med blokken vist i Figur 8-41. Selve blokken brukes ikke i programmet, foruten å undersøke matrisene. Figur 8-41 IMAQ Get Binocular Stereo Calibration Info VI Fra translasjonsvektoren, kan avstanden mellom kameraene leses. I Figur 8-42 i matrisen, Translation Vector, er avstanden mellom kameraene -6,659 cm i x-retning. Dette stemmer godt overens med målt avstand på 6,7 cm. Y og Z verdien skal, i et perfekt system, være 0 cm. Fra matrisen kan vi se at dette ikke er helt perfekt, men disse verdien er tilnærmet 0 og anses derfor akseptable i et system der funksjonen av avstandsmåling skulle testes. 109 Figur 8-42 Matriser fra kalibrering, utført 8. mai Rotasjonsmatrisen spesifiserer rotasjonstransformasjonen mellom høyre og venstre kamera [121]. Essensialmatrisen transformerer et punkt i venstre koordinatsystem til det høyre koordinatsystem. Den inneholder all informasjon om geometrien til de to kameraene. Fundamentalmatrisen kan bli benyttet til å transformere en pikselkoordinat i venstre bilde, til en pikselkoordinat i høyre bilde. Denne matrisen inneholder den samme informasjonen som essensialmatrisen samt informasjon om kameraenes indre parametere. Q-matrisen kan benyttes til å konvertere pikselkoordinater sammen med forskyvningsverdien til reelle 3D-punkt. Overnevnte matriser sendes inn i blokken, IMAQ Stereo Correspondence (SG Block Matching). Denne blokken lager et forskyvningsbilde ut fra venstre og høyre bilde med semiglobal block matching [122]. Blokken bruker SAD som beregningsmetode. På utgangen, hentes forskyvningsbildet og sendes til en interpolasjonsblokk, IMAQ Interpolate Disparity Image. Denne blokken mykner forskyvningsbildet (Figur 8-43). I IMAQ Get Depth Image From Stereo, lages et forskyvningsbilde i farger med de verdiene satt i «Correspondence Options SGBM». Correspondence Options spesifiserer hvordan blokkmatching-algoritmen beregner forskyvningsinformasjonen ved å bruke stereokorrespondanse. Disse valgene deles inn følgende [123]: Metode spesifiserer hvilken metode som benyttes til å beregne match mellom høyre og venstre bilde. Sum of Absolute Differences (SAD) er foreløpig den eneste støttede metoden (se kapittel 5.2.4). Window Size er størrelsen av vinduet som benyttes til å beregne overensstemmelsespoengsummen ved hver piksel i bildet. 110 Minimum Disparity er den minimale avstanden mellom samme punkt i høyre og venstre utbedrete bilde. Number of Disparities er den maksimale forskyvningen (disparity) mellom samme punkt i det høyre og venstre utbedrede bildet. Vet man den minimale dybden til et inspisert objekt, kan IMAQ Get Maximum Disparity VI benyttes til å beregne denne verdien. P1 spesifiserer ressursbruken av å bytte forskyvningsverdi (disparity) med en enhetsverdi under oppdateringsprosessen basert på nabo-verdiene. P2 spesifiserer mengden av glatting (smoothing) anvendt til forskyvningsbildet. En høy verdi vil glatte mer, men redusere nøyaktigheten. Full Dynamic Programming hvis denne er satt til TRUE, vil blokk-matching-algoritmen utføre flere iterasjon ved å bruke dynamisk programmering. Max Disparity spesifiserer den maksimalt tillatte forskjellen i forskyvningsverdi til en piksel med den nærliggende piksels forskyvningsverdi. Hvis forskjellen (disparity) er større enn denne verdien, vil pikselen få en ugyldig forskyvning. Subpixel når denne er aktivert, beregner den forskyvning med subpiksel-nøyaktighet. Bilinær interpolering bruks til å beregne forskyvning med subpiksel-nøyaktighet. Replace Value er pikselverdien tildelt til ugyldig forskyvning i utgangen, Disparity Image. Figur 8-43 Bilder fra avstandmåling 111 De forskjellige fargene beskriver avstanden fra kameraplanet til objektene. Disse fargene kan oppfattes feil, slik som det røde feltet til høyre i bildet (Figur 8-43). Denne feilen kan skyldes mangel på tekstur og struktur. I det originale programmet til Márk Szabó, ble avstandsmålingen aktivert ved å bevege musepekeren over det området man ønsket å måle. I Virtual Instrument filen (Figur 8-44), oppdateres måleverdien ved et definert punkt kontinuerlig. Figur 8-44 Blokker for kontinuerlig oppdatering av distanse Punktet er definert som X=230, Y=160. Det er også lagt inn et visuelt punkt i bildet for å gi brukeren en indikasjon på hvor i bildet målingen foregår. Dette gjøres med blokken IMAQ Overlay Oval (Figur 8-45). Figur 8-45 Visuelt punkt Resultater fra avstandsmåling kan sees i kapittel 9.6. På grunn av kompatibilitetsproblemer, er avstandsmålingen utelatt fra kamerariggen. Den hovedsakelige årsaken er orienteringen av kameraene (se kapittel 8.1.2). Det ble lagt inn rotasjon av bildet i LabVIEW-programmet, men det fungerte ikke som ønsket. Det kunne vært mulig å orientert kameraene i utgangsposisjon, men dette ville medført at kun halve kamerasensoren blir benyttet. Den andre årsaken er begrensningen på grunn av interaksialavstanden til kameraene. Denne kan maksimalt 112 være 10 cm. I målingene fra kapittel 9.6, kan man se at nøyaktigheten til avstandsmålingen går fra 10 cm til 200 cm med 7 cm interaksial avstand. IMAQ Stereo Correspondence (Block Matching) er lagt inn som et alternativ til Semi Global Block Matching, nevnt ovenfor. Denne ble forsøkt uten hell. Blokkdiagram for avstandsmålingen kan sees i vedlegg 2 Virtual Instruments. 113
© Copyright 2024