3d_brille_sammendrag-og

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