Designspecifikation. LiTH Autonom bandvagn med stereokamera Gustav Hanning Version 1.0. Status. TSRT10 8Yare LIPs.

Relevanta dokument
Systemskiss. LiTH Autonom bandvagn med stereokamera Gustav Hanning Version 1.0. Status. TSRT10 8Yare LIPs. Granskad

Kravspecifikation. LiTH Autonom bandvagn med stereokamera Gustav Hanning Version 1.0. Status. TSRT10 8Yare LIPs.

LiTH Autonom bandvagn med stereokamera Användarhandledning. Gustav Hanning Version 0.1. Status. Granskad. Godkänd.

Kravspecifikation Autonom Bandvagn

Kravspecifikation. LIPs. Marcus Arvidsson & Jacob Bernhard Version 1.1. LiTH 22 november imap. Status Granskad. Autonom bandvagn 1

Användarhandledning. Redaktör: Patrik Molin Version 1.0. Mobile Scout. Status. LiTH Granskad Godkänd. TSRT71 Patrik Molin

Projektplan. LiTH Autonom bandvagn med stereokamera Henrik Berggren Version 1.0. Status. TSRT10 8Yare LIPs. Granskad

LiTH Mobile Scout. Kravspecifikation. Redaktör: Patrik Molin Version 1.0. Status. Granskad Godkänd. TSRT71 Patrik Molin.

Användarhandledning. LiTH Autonom bandvagn med stereokamera Jacob Bernhard Version 0.2. Status

Systemskiss Minröjningsbandvagn

Testspecifikation. Henrik Hagelin TSRT10 - SEGWAY 6 december 2010 Version 1.0. Status:

Systemskiss. Joachim Lundh TSRT10 - SEGWAY 6 december 2010 Version 1.0. Status:

Systemskiss. LiTH AMASE Accurate Multipoint Acquisition from Stereovision Equipment. Jon Månsson Version 1.0

Designspecifikation Autonom Bandvagn

LiTH. WalkCAM 2007/05/15. Testplan. Mitun Dey Version 1.0. Status. Granskad. Godkänd. Reglerteknisk projektkurs WalkCAM LIPs

Systemskiss. LiTH Kamerabaserat Positioneringssystem för Hamnkranar Mikael Ögren Version 1.0. Status

Systemskiss. Självetablerande sensornätverk med 3G och GPS. Version 0.2. Christian Östman Datum: 15 maj 2008

Testplan. Flygande Autonomt Spaningsplan. Version 1.0. Dokumentansvarig: Henrik Abrahamsson Datum: 14 mars Status.

Kravspecifikation. LiTH Segmentering av MR-bilder med ITK Anders Eklund Version 1.0. Status

Projektplan. Redaktör: Patrik Molin Version 1.0. Mobile Scout. Status. LiTH Granskad Godkänd. TSRT71 Patrik Molin

HARALD Testprotokoll

Projektplan Autonom Bandvagn

Testprotokoll Autonom målföljning med quadcopter

LIPs Martin Lindfors ChrKr Projdir2017_sbd.doc CKr

Systemskiss Autonom målföljning med quadcopter

Systemskiss. LiTH. Autopositioneringssystem för utlagda undervattenssensorer Erik Andersson Version 1.0. Status

HARALD. Version 0.2 Redaktör: Patrik Johansson Datum: 8 maj Status. Granskad - yyyy-mm-dd Godkänd - yyyy-mm-dd

Projektplan. LiTH Segmentering av MR-bilder med ITK Anders Eklund. Version 1.0. Status. Bilder och grafik projektkurs, CDIO MCIV LIPs

LIPs Daniel Axehill ChrKr Projektdirektiv_Saab_v3 CKr

LIPs Fredrik Ljungberg ChrKr Projektdirektiv18_ROV.doc CKr

Testprotokoll. Redaktör: Sofie Dam Version 0.1. Status. Planering och sensorfusion för autonom truck Granskad Dokumentansvarig - Godkänd

Användarhandledning. Redaktör: Jenny Palmberg Version 1.0. Status. LiTH Fordonssimulator. Granskad Godkänd. TSRT71 Jenny Palmberg

Testplan. LiTH. Autopositioneringssystem för utlagda undervattenssensorer Martin Skoglund Version 1.1. Status

Användarhandledning Autonom Bandvagn

HARALD. Systemskiss. Version 0.3 Redaktör: Patrik Johansson Datum: 20 februari Status

Projektdirektiv Hanna Nyqvist Sida 1

Kravspecifikation Autonom målföljning med quadcopter

LiTH 7 december Optimering av hjullastare. Testplan. Per Henriksson Version 1.0. LIPs. TSRT10 testplan.pdf WHOPS 1. tsrt10-vce@googlegroups.

Systemskiss. Redaktör: Anders Toverland Version 1.0. Status. LiTH Fordonssimulator. Granskad Godkänd. TSRT71 Anders Toverland

LiTH. WalkCAM 2007/05/15. Testrapport. Mitun Dey Version 1.0. Status. Granskad. Godkänd. Reglerteknisk projektkurs WalkCAM LIPs

Testplan Autonom målföljning med quadcopter

Prestandautvärdering samt förbättringsförslag

LiTH Golfspelande industrirobot Designspecifikation. Designansvarig: Mikaela Waller Version 1.0. Status. Granskad Martin

Testplan. Redaktör: Sofie Dam Version 0.1. Status. Planering och sensorfusion för autonom truck Granskad Dokumentansvarig - Godkänd

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund Marcus Widblom Senast ändrad: 13 / 05 / 08

Projektdirektiv Oskar Ljungqvist Sida 1. Kund/Examinator: Daniel Axehill, Reglerteknik/LiU

LiTH Autonom styrning av mobil robot Testplan Version 1.0 TSRT71-Reglertekniskt projektkurs Anders Lindgren L IPs

LiTH, Reglerteknik Saab Dynamics. Testplan Collision avoidance för autonomt fordon Version 1.0

LiTH Autonom styrning av mobil robot Projektplan. Martin Elfstadius & Fredrik Danielsson. Version 1.0

Kravspecifikation. LiTH AMASE Accurate Multipoint Acquisition from Stereo vision Equipment. John Wood Version 1.0.

Användarhandledning Minröjningsbandvagn

LIPs Isak Nielsen ChrKr Projektdirektiv13_ROV.doc CKr

Arbeta med rutter i Tracker MyWay och andra program.

Testplan Erik Jakobsson Version 1.1

Testplan Autonom truck

Projektplan. LiTH AMASE Accurate Multipoint Acquisition from Stereovision Equipment. Johan Hallenberg Version 1.0

Designspecifikation. Redaktör: Patrik Molin Version 1.0. Mobile Scout. Status. LiTH Granskad Godkänd. TSRT71 Patrik Molin

Testplan. Status. David Sandberg, Tobias Lundqvist, Rasmus Dewoon, Marcus Wirebrand Version 1.2. Granskad Godkänd

Capitex dataservertjänst

Operativsystem DVG A06. Definition. Varför operativsystem? - Vad är ett operativsystem?

Kravspecifikation. Självetablerande sensornätverk med 3G och GPS. Version 1.0. Christian Östman Datum: 12 maj 2008

OBS!!! Anslut ej USB kabeln till dator eller GPS innan du först har installerat drivrutinerna för USB kabeln i din dator.

Svensk version. Inledning. Installation av Windows XP och Vista. LW056V2 Sweex trådlös LAN cardbus-adapter 54 Mbps

Kravspecifikation. Vidareutveckling av Optimal Styrning av Radiostyrd Racerbil. Version 1.1 Joel Lejonklou 26 november 2012

LiTH Segmentering av MR-bilder med ITK Efterstudie MCIV. Anders Eklund. Status

SweTrack Animal II. Svensk manual

AALTO CONTROL -SYSTEMET

Testprotokoll Följning av djur Kolmården djurpark

Användarhandledning. Redaktör: Anders Toverland Version 1.0. Status. LiTH Fordonssimulator. Granskad Godkänd. TSRT71 Anders Toverland

Före Kravspecifikationen

Kravspecifikation. Flygande Autonomt Spaningsplan. Version 1.2. Dokumentansvarig: Henrik Abrahamsson Datum: 29 april Status.

Användarhandledning Följning av djur Kolmården djurpark

Designspecifikation. LIPs. Emanuel W Viklund Version 1.0. LiTH 7 oktober imap. Status Granskad Godkänd Jonas Callmer

Metoder (funktioner) Murach s: kap Winstrand Development

Rapportering som krävs utöver LIPS-dokumenten: poster föredrag där projektets genomförande och resultat beskrivs hemsida som beskriver projektet

Systemskiss. Vidareutveckling Optimal Styrning av Radiostyrd Racerbil. Version 1.0 Simon Eiderbrant. Granskad Erik Olsson 20 September 2012

Enchipsdatorer med tillämpningar LABORATION 7, ROBOT

Vanliga frågor och svar

Svensk version. Installation av Windows XP och Vista. LW311 Sweex trådlösa LAN Cardbus-adapter 300 Mbps

Sirius II Installation och Bruksanvisning

Insticksprogram för webbkamera till SalsaJ. Användarmanual

Systemskiss. Michael Andersson Version 1.0: Status. Platooning Granskad DOK, PL Godkänd Erik Frisk

Roboten. Sida 1 av 11

Anslutnings guide (för D-SLR-kameror) Sv

TrackBlock Tracking System Bruksanvisning

Setup Internet Acess CSE-H55N

Systemskiss. Remotely Operated Underwater Vehicle. Version 1.0. Simon Lindblom. 22 september Status

Projektplan. Flygande Autonomt Spaningsplan. Version 1.0. Dokumentansva Datum: 13 februari Dokumentansvarig: Henrik Abrahamsson.

Installationsmanual 501 GPS Tracker

ESGRAF. Datablad SDS00009SE Version /02/2015 Integration. Presentationsmjukvara

Kravspecifikation Fredrik Berntsson Version 1.1

TENTAMEN I DYNAMISKA SYSTEM OCH REGLERING

Tack för att du har valt den här routern med XR-teknologi.

Quick start manual. Smart-House Rev 1.1

Programutvecklingsprojekt Projektgrupp Elvin. Detailed Design Document

Vop handledning. Användarhandledning till Vop applikationen. UPPGJORD: Mattias Gyllsdorff GODKÄND:Mattias Gyllsdorff REV: A DATUM:

EV3 Roboten. Sida 1 av 13

Konstruktion av en radiostyrd legobil. Digitala projekt av Arbon Vata Leonardo Vukmanovic Amid Bhatia

Transkript:

Designspecifikation Gustav Hanning Version 1.0 Granskad Status Godkänd Jonas Callmer 2010-10-08 1

PROJEKTIDENTITET 2010/HT, 8Yare Linköpings tekniska högskola, institutionen för systemteknik (ISY) Namn Ansvar Telefon E-post Henrik Berggren Projektledare (PL) 073 066 79 81 henbe341@student.liu.se Gustav Hanning Dokumentansvarig (DOK) 073 569 67 95 gusha410@student.liu.se Anders Bergdahl Designansvarig (DES) 070 964 72 10 andbe752@student.liu.se Richard Wasell Testansvarig (TST) 073 955 72 10 ricwa946@student.liu.se Viktor Pirard 073 445 55 61 vikpi051@student.liu.se Johannes Fri 070 549 97 07 johfr306@student.liu.se Philip Hagelin 076 291 60 08 phiha649@student.liu.se Rikard Norman 076 427 41 62 rikno676@student.liu.se E-postlista för hela gruppen: Hemsida: Kommer senare Beställare: Jonas Callmer, Linköpings universitet, 013 28 40 58, callmer@isy.liu.se Kund: Pelle Carlbom, Saab Dynamics, 013 18 62 13, pelle.carlbom@saabgroup.com Kursansvarig: David Törnqvist, Linköpings universitet, 013 28 18 82, tornqvist@isy.liu.se Handledare: Martin Skoglund, Linköpings universitet, 013 28 18 90, ms@isy.liu.se 2

Innehåll 1 INLEDNING...5 2 SYSTEMÖVERSIKT...5 2.1 GROV BESKRIVNING AV SYSTEMET...6 2.2 INGÅENDE DELSYSTEM...6 3 MASTERENHETEN...8 3.1 ANVÄNDARGRÄNSSNITT...8 3.2 KOMMUNIKATION...11 3.3 BILDBEHANDLING...11 4 SCOUTENHETEN...12 4.1 NAVIGATIONSENHETEN...13 4.1.1 Navigering...14 4.1.2 Estimering...14 4.1.3 Kommunikation...14 4.2 STEREOKAMERAN...16 REFERENSER...19 APPENDIX A - NÄTVERKSPROTOKOLL...20 ID 3 CAMERASETTINGS...20 ID 8 CAMERADATA...21 APPENDIX B - KONVENTIONER...22 DOKUMENTKONVENTIONER...22 KODKONVENTIONER...22 3

Dokumenthistorik version datum utförda förändringar utförda av granskad 0.1 2010-09-27 Första utkastet Alla Alla 0.2 2010-10-04 Enligt kommentar från handledare och beställare Alla Alla 0.3 2010-10-07 Enligt kommentarer från beställare JF,GH HB 4

1 Inledning Saab Dynamics vill ta fram en bandvagn som ska kunna kartlägga olika miljöer autonomt. Projektet inleddes våren 2009 med framtagning av specifikationer, kontrollprogram, nätverkskommunikation, navigationstekniker med mera. Under hösten 2009 utrustades bandvagnen med fjärrstyrning samt motorreglering för framdrivning. Bandvagnen utrustades även med en GPS för att kunna följa en fördefinierad brytpunktsbana. Projektgruppens uppgift är att utöka bandvagnens funktionalitet med hjälp av en stereokamera av typen Bumblebee 2. Bandvagnen ska använda kameran för att ta stereobilder och dessa ska presenteras för användaren. Stereobilderna ska dessutom kombineras till en bild med djup. Projektet bygger vidare på arbetet utfört av projektgruppen O'hara's under våren 2009 och projektgruppen Carpe Locus under hösten 2009. Detta dokument innehåller en översiktlig beskrivning av systemet och dess delar samt en mer ingående beskrivning av varje delsystem. 2 Systemöversikt Systemet är uppbyggt av två delsystem, masterenheten och scoutenheten. Masterenheten används för att kontrollera och övervaka scoutenheten. I figur 1 ses en översiktlig bild över hur systemet är uppbyggt, där scoutenheten definieras av bandvagnen och dess tillhörande delsystem. Den trådlösa kommunikationen sker mellan master- och navigationsenheten. Scoutenhet Masterenhet GPS Navigationsenhet Stereokamera Motorer Odometrar Framdrivningsenhet ARM Figur 1. Översikt av systemet. 5

2.1 Grov beskrivning av systemet Det första delsystemet (masterenheten) är en laptop som används för att styra bandvagnen. Det andra delsystemet (scoutenheten) är själva bandvagnen. Dessa två delsystem kommunicerar med varandra via ett trådlöst nätverk. Scoutenheten är i sin tur uppbyggd av två delsystem: navigationsenheten och framdrivningsenheten ARM. De sensorer som ingår är en GPS och en stereokamera som är kopplad till navigationsenheten och två odometrar som är kopplade till ARM-processorn. En översikt av informationsflödet mellan delsystemen finns i figur 2. Eftersom robotens funktionalitet i framtiden kan utökas med IMU och visuell odometri finns även information om detta med. Resultatet från den visuella odometrin skickas som ImageData till scoutenhetens mobilitetsmodul där även fusionering av sensordata sker. 2.2 Ingående delsystem De ingående delsystemen är: Masterenheten, se kapitel 3 Scoutenheten, se kapitel 4 o Navigationsenheten o Framdrivningsenheten ARM 6

Masterenheten Användargränssnitt Status GPSData WheelData IMUData Images Manual Automatic CameraSettings Nätverksmodul ImageData Bildbehandlingsmodul CameraData GPSData Status WheelData CameraData IMUData Manual Automatic CameraSettings ImageData Odometrar GPS IMU WheelData GPSData IMUData GPSData WheelData CameraData Sensormodul Nätverksmodul CameraSettings GPSData IMUData WheelData Status Manual Automatic ImageData Mobilitetsmodul CameraSettings Stereokamera CameraData Fordonsmodell Figur 2. Översikt av informationsflödet. Scoutenheten 7

3 Masterenheten Masterenheten utgörs av en laptop, där ett användargränssnitt körs under ett Linux-baserat operativsystem. Från användargränssnittet skickas kommandon till scoutenheten via WLAN (figur 3). Bandvagnen kan endera köras i autonomt eller manuellt läge. I autonomt läge skickas en av användaren specificerad brytpunktsbana till bandvagnen. Bandvagnen följer sedan denna bana så bra som möjligt. I manuellt läge skickar användaren styrkommandon direkt till bandvagnen. Masterenhet Figur 3. Masterenheten kommunicerar med scoutenheten via WLAN 3.1 Användargränssnitt Det användargränssnitt (GUI) som kommer att användas på masterenheten har utvecklats av de tidigare projektgrupperna O'hara's och Carpe Locus. Användaren kan med hjälp av GUI:t ansluta till bandvagnen och därefter skicka och ta emot data från bandvagnen. Programmet är utvecklat i C++ och använder Qt-biblioteket för det grafiska gränssnittet. Vid start av programmet möts användaren av ett anslutningsfönster där ip-adressen till navigationsenheten skrivs in. Efter att anslutningen är upprättad kan styrkommandon skickas till roboten. Dessutom kan en brytpunktsbana definieras i GUI:t och skickas till roboten som sedan utför förflyttning efter banan. I manuellt läge skickas styrkommandon direkt till roboten. Användaren kan via ett hastighetsreglage ställa in önskad hastighet för roboten. Med hjälp av tangentbordet kan sedan användaren styra roboten. När en tangent trycks ner sänds hastighetsinformation och rotationshastighet till roboten via det trådlösa nätverket och roboten utför sedan förflyttning enligt det önskade kommandot. Gränssnittet visar också sensordata från roboten. Gränssnittet ska vidareutvecklas så att bilder från stereokameran kan presenteras för användaren. Både originalbilderna från kameran och bilder som visar djupet med en färgskala ska kunna visas. Mer information om bildbehandlingen finns i avsnitt 3.3. Eftersom bilderna från kameran ska taggas med position och vinkel ska man kunna se var bilder har tagits i kartdelen av gränssnittet. Funktionalitet för att spara en rutt tillsammans med de bilder som tagits ska också implementeras. 8

För att identifiera ett rörligt objekt aktiverar användaren trackingmode i ViewGui. Scout kommer då att stanna och bilder tagna vid olika tidpunkter kommer att jämföras för att kunna avgöra om något objekt rört sig. När det går att säkerhetsställa att ett objekt har rört sig räknas avståndet till objektet ut och dess väg genom robotens synfällt börjar lagras i datalagringsklassen ScoutData. Ett nytt datalagringsobjekt kommer att skapas innehållande objektets position, tidpunkt, samt bildparet som togs vid denna tidpunkt. Objektets väg genom bilden kan ritas ut i en karta om den funktionaliteten väljs i användargränssnittet. När användargränssnittet utökas så kommer den kodkonvention som projektgruppen Carpe Locus tagit fram följas. Även objekthanteringen kommer följa den satta strukturen. De nya objekt som kommer skapas är ViewGui Visar ett stereobildpar, kan även visa djupet representerat i en färgskala om så önskas. CameraOption Visar de nuvarande inställningarna för kameran, t.ex. FPS (bilder per sekund) och upplösning. Inställningarna kommer även gå att ändra från detta objekt. ImagePair En klass för att fusionera ett bildpar med position,vinkel och tidpunkt då bilderna togs. Denna information kommer bli nödvändig att ha då en tidigare körning ska spelas upp. En hel del av de objekt som tidigare grupper skapat kommer behöva utökas med mer funktionalitet. Klasstrukturen visas i figur 4 där gröna rutor visar helt nya klasser och klasserna finns också beskrivna i tabell 1. 9

UserInterface GL- Widget Auto- Gui Manual Gui Net- work- Gui Sensor- Gui Scout- Data Satellite- Panel View- Gui Map- Gui Cameraoption Image- Pair Break- Gui Track- Gui Status- Gui Figur 4. Klassstrukturen för användargränssnittet. NetworkGui ManualGui AutomaticGui SensorGui StatusGui MapGui TrackGui BreakGui ScoutData GLWidget SatellitePanel ViewGui CameraOption ImagePair Klass som skapar ett fönster för nätverksanslutning. Klass som skapar ett gränssnitt för manuell styrning. Klass som skapar ett gränssnitt för autonom styrning. Klass som tar in och visar sensorinformation för operatören. Klass som skapar ett fönster som tar in och visar statusinformation för operatören. Klass som ritar ut robotens position relativt start. Klass som skapar ett fönster som möjliggör för operatören att ladda in en förgenererad bana. Klass som möjliggör inmatning av brytpunkter. Sparar information om roboten som position och GPS-data samt innehåller brytpunktslistan. Huvudklassen för att rita ut satellitkartan. Klass som visar knappar i satellitvyn. Klass som visar ett stereobildpar Klass som visar nuvarande kamerainställningar Klass som sätter ihop bilder med tid, plats och vinkel Tabell 1. Klasserna för användargränssnittet. 10

3.2 Kommunikation Masterenheten kommunicerar med scoutenheten via WLAN där data skickas i båda riktningarna. För att kommunicera med scoutenheten, som fungerar som server, ansluter masterenheten till scoutenheten genom att ange navigationsenhetens ip-nummer. Tidigare projektgrupper har tagit fram ett protokoll för överföring av data mellan scout- och masterenheten. Vi ska bygga vidare på detta protokoll men utöka antalet meddelandetyper så att vi även kan skicka stereobilder och ge styrkommandon till kameran. 3.3 Bildbehandling Masterenheten kommer att behandla stereokamerans bilder innan de presenteras. Exempelvis ska masterenheten ta emot ett stereobildpar från navigationsenheten. Med hjälp av programvaran som följer med kameran (Triclops SDK) ska en bild skapas som visar djupet med en färgskala, utifrån stereobildparet. Triclops SDK har vissa medföljande bibliotek (stdio.h, stdlib.h,triclops.h,digiclops.h pnmutils.h) som består av olika funktioner som man har tillgång till. De olika funktionerna vi kommer att nyttja är framförallt följande: Funktion: Beskrivning: ppmreadtotriclopsinput Läser in en bild från fil digiclopsgettriclopscontextfromcamera Läs av kameramodulens inställningar triclopssetdisparity Ställer in djupintervallet för kameran triclopspreprocess Förbehandlar bilden triclopsstereo Stereobehandlar bilden triclopsgetimage Skapar en djupbild från ett context triclopssaveimage Spara djupbilden depthimage.data Räknar ut djupet för en viss pixel Tabell 2. Funktioner vi använder oss av från Triclops SDK Programmet kommer ha följande uppbyggnad: 1. Läs in bibliotek 2. Initiera Triclopscontext, samt övriga variabler 3. Konfigurera önskade kamerainställningar 4. Hämta bilder 5. Behandla bilder 6. Räkna ut djup för bilden 7. Generera en djupbild Med dessa funktioner så kommer vi utifrån ett stereobildpar kunna skapa en bild vars färgskala representerar djupet i bilden. Denna bild kommer sedan presenteras i användargränssnittet. I mån av tid så kommer även en 3D-värld att försöka skapas utifrån insamlade stereobildpar under en körning. 11

Andra funktioner som ska skapas är att bilden ska kunna komprimeras och taggas med information om när, var och med vilken vinkel bilden togs. Informationen i taggen erhålls direkt från scoutenheten men måste eventuellt användas i programmeringen när bildparet ska sparas, för att kunna laddas in senare, som enskild bild eller som del i en rutt. Denna information ska även kunna visas i interfacet. Beroende på hur arbetet fortskrider ska masterenheten med hjälp av bilderna ska kunna skilja mellan den statiska världen och objekt som rör på sig. Detta kan utföras med hjälp av eller i kombination med mjukvaran Censys3D SDK, som används för att ge målföljningsinformation. Om tid finns ska även ett program för att visualisera en 3D-värld uppbyggd av stereobilderna tas fram. Eventuellt kan det egna programmet kombineras med Triclops. Denna mjukvara rättar till bilderna och utför stereobearbetning samt levererar i realtid djupbilder med hjälp av stereovision-teknik. Det gör att man kan mäta avståndet till varje giltig pixel i en bild. Programmet genomför en MMX-optimerad version av korrelationsalgoritmen Sum of Absolute Difference som enligt leverantören genererar en snabb och noggrann djupkarta. Själva kontrolleringen av kameran och bildtagningen sköter masterenheten via programmet FlyCapture SDK som finns på scoutenheten. Tanken är att denna mjukvara installeras på navigationsenheten, men att alla kamerakommandon ska komma från masterenheten och helst vara integrerade i användargränssnittet. Med FlyCapture kan man ta bilder med en överföringshastighet på 800 Mb/s. Det finns även ett API-bibliotek med demoprogram och källkodsexempel som kan utnyttjas för att bygga egna bildbehandlingsprogram om tillfälle ges och behov finns. 4 Scoutenheten Scoutenheten består av en bandvagn av typ MMP30 samt en dator som använder operativsystemet Linux. På bandvagnen sitter två stycken DC-motorer, en på vardera sida, som driver enheten. Plattformen innehåller även två batterier som via en spänningsregulator tillhandahåller spänning till motorer och övrig elektronik i bandvagnen. Scoutenheten är utrustad med odometrar på motorerna och en GPS. Under projektet kommer även en stereokamera att installeras. Scoutenheten består av två stycken delsystem: Navigationsenheten samt framdrivningsenheten ARM. Kommunikation mellan scoutenheten och omvärlden sker genom navigationsenheten till masterenheten via WLAN. En översikt av scoutenheten kan ses i figur 5. 12

GPS Navigationsenhet Stereokamera Motorer Odometrar Framdrivningsenhet ARM Figur 5. Översikt av scoutenheten. 4.1 Navigationsenheten Navigationsenheten består av datorn som är fastsatt på bandvagnen. Den har tre huvudsakliga uppgifter: Sköta kommunikationen mellan masterenheten och scoutenheten Beräkna styrsignaler till framdrivningsenheten utifrån nuvarande position, hastighet och önskad position. Samla in sensordata från odometrar, GPS och kamera. De tidigare projektgrupperna har använt en bärbar dator som navigationsenhet. I detta projekt ska den bärbara datorn bytas ut mot en industridator av typen Nexcom NICE 3100. Det innebär att funktionaliteten från den bärbara datorn måste överföras till industridatorn. Målet är att i framtiden kunna byta ut även industridatorn mot en mindre dator som kan sitta inuti robotchassit. Eftersom industridatorn saknar skärm och tangentbord måste scoutenhetens initiering ske automatiskt till skillnad från tidigare projekt. Dessutom ska industridatorn om möjligt använda bandvagnens batterier som spänningskälla då den ej har ett eget batteri. I nuläget används odometrar och GPS för att skatta robotens position och riktning. Eftersom scoutenheten kommer få extra informationen från kameran kan denna komma att användas för att förbättra skattningarna, t.ex. med SLAM-teknik. Navigationsenheten använder sig av ett Socket-objekt och kan därför kommunicera med flera enheter samtidigt. Navigationsenheten är kopplad via USB till framdrivningsenheten och till masterenheten via WLAN. 13

4.1.1 Navigering Navigering sker på olika sätt beroende på om användaren valt manuellt eller autonomt läge. I manuellt läge navigerar scoutenheten enligt de tangentbordskommandon som skickas från masterenheten. I autonomt läge följer bandvagnen en fördefinierad brytpunktsbana. För att klara detta används ett kalmanfilter och en PD-regulator. 4.1.2 Estimering Ett Extended Kalman filter (EKF) används för att skatta bandvagnens tillstånd utifrån GPSoch odometerdata samt en enkel modell över bandvagnens dynamik. Ett vanligt kalmanfilter räcker inte eftersom bandvagnens vinkel kommer in olinjärt i dynamiken. I filtret har bandvagnen fem tillstånd: X = x y v θ ω Här är x och y bandvagnens koordinater, v är dess hastighet, θ och ω är vinkel respektive vinkelhastighet. Rörelsemodellen som används är 4.1.3 Kommunikation x t+1 = x t + T s v t cos θ + ωt s 2 y t+1 = y t + T s v t sin θ + ωt s 2 v t+1 = v t θ t+1 = θ t + ω t T s ω t+1 = ω t Navigationsenheten kommunicerar med masterenheten via WLAN, framdrivningsenheten och GPS:en via USB och stereokameran via firewire. För att kunna kommunicera med flera enheter samtidigt använder sig navigationsenheten av sockets. Scoutenhetens kommunikation kommer ske på följande sätt: Master Från masterenheten initieras en anslutning som bekräftas från scoutenheten. Tidigare har denna bekräftelse utförts manuellt ty man har haft en bärbardator som navigationsenhet. Bekräftelsen kommer nu behöva ske automatiskt eftersom industridatorn inte ska behöva ha en skärm inkopplad för att upprätta en förbindelse mellan enheterna. GPS GPS-modulen skickar över GPS-koordinater till navigationsenheten via USB. Kommunikationen med GPS-enheten kommer inte förändras något från vad tidigare projektgrupper skapat. 14

Kamera Bilder ska kunna tas emot från kameran till navigationsenheten och ska sedan skickas vidare till masterenheten. Om kommunikationen begränsas mellan navigationsenheten och masterenheten så ska bilder temporärt kunna undanlagras på navigationsenheten. Navigationsenheten ska även kunna förmedla styrkommandon från masterenheten till kameran. När scoutenheten körs i manuellt läge, köas inte bilderna, så scoutenheten försöker alltid skicka det senast tagna bildparet. När scoutenheten körs i automatiskt läge, köas bilderna så att åtminstone en bild/s skickas, detta för att kunna bygga en bra omvärldsbild. Framdrivning Kommunikationen mellan navigationsenheten och framdrivningsenheten fungerar så att navigationsenheten skickar över börvärden till regulatorerna i framdrivningsenheten via USB. Framdrivningsenheten skickar på begäran från navigationsenheten tillryggalagd sträcka och hastighet för de två banden. Eftersom systemet nu även måste klara av att överföra bilder som innehåller stora mängder information kan det uppstå begränsningar i kommunikationen. Vid behov så kommer det därför att skapas en prioritetskö mellan de enheter med begränsad kommunikation, där styrningen prioriteras. Varje meddelande består av en header följt av ett antal databytes. Headern består i sin tur av tre variabler bestående av meddelandetyp, längd utöver headern samt en checksumma. I appendix A visas en lista över möjliga meddelandetyper samt en beskrivning av dessa. 15

4.2 Stereokameran Kameran som används av scoutenheten är en Bumblebee2 BB2-08S2C stereokamera från Point Grey som tillsammans med medföljande programvara kan användas för att skapa 3Dbilder. Kameran är utrustad med en firewire-port samt en GPIO-port. I projektet kommer firewire-porten användas, för överföring av data, kamerakontroll samt strömförsörjning av kameran. Strömförbrukningen är 2.5 W vid 12 V och tillåten spänningsmatning är 8-30 V. Stereokamerans specifikationer i detta avsnitt är hämtade från Point Greys hemsida [1]. Till en början fästs kameran med kardborre för att lätt kunna monteras på och av, senare kan en skruvanordning tänkas användas. Kameran ska placeras framtill på bandvagnen, där den har stort synfält och där den vid eventuell vältning skyddas baktill av den höga industridatorn. Industridatorn fästs med dubbelhäftande tejp till en början, senare kanske denna kan komma att skruvas fast i bandvagnens topplock. Kameran använder två CCD-sensorer för att ge en balans mellan 3D-data kvalitet, bearbetningshastighet och storlek. Den kan ta bilder med en maximal upplösning på 1024x768 pixlar i 20 fps. Kamernas HFOV (Horizontal Field of View) är 43-97 : 43 för 6 mm-lins, 66 för 3.8 mm-lins, 97 för 2.5 mm-lins. Kamerans Signal to Noise Ratio (SNR) är 60 db. I figur 6 visas hur exakt beräkningar av 3D-punkter är för olika avstånd. Här användes en 3.8mm Bumblebee2 kamera med en stereo upplösning på 1024x768. När avståndet ökar minskar noggrannheten kraftigt och vid ett avstånd på 40 meter ligger noggrannheten på ca 4 meter, vilket innebär en noggrannhet på ca 10 %. 16

Figur 6. Noggrannhet för beräkning av 3D-punkter som funktion av avstånd. [1] Namn flycapturecreatecontext flycapturedestroycontext flycaptureinitialize flycapturesetcameraproperty flycapturestart flycapturestop flycapturegrabimage flycapturesaveimage flycaptureerrortostring flycaptureconvertimage Beskrivning Skapar ett FlyCaptureContext och allokerar det minne som behövs. Tar bort ett FlyCaptureContext. Initialiserar kameran på bussen och associerar den med ett FlyCaptureContext. Sätter en given kameraegenskap. Startar bildhämtningsprocessen. Stannar bildhämtningsprocessen. Hämtar den senast tagna bilden. Skriver bildbufferten till hårddisk. Returnerar en beskrivning för given FlyCaptureError Omvandlar ett godtyckligt bildformat till ett annat. Tabell 3. FlyCapture funktioner Själva kontrolleringen av kameran och bildtagningen sköter programmet FlyCapture SDK som finns på scoutenheten. Tabell 3 visar de funktioner som vi utnyttjar från FlyCapture. Först av allt måste ett FlyCaptureContext-objekt skapas för att kunna hantera en kamera över en buss. Detta objekt ska sedan finnas med som parameter i de funktioner som har koppling 17

till kameran. Därefter kan man initialisera kameran på bussen och associera denna med det skapade context-objektet. För att sedan kunna hämta bilder från kameran ska flycapturestart användas, här sätts vilken upplösning och bildtagningshastighet man vill ha. Den senast tagna bilden hämtas och sparas i en bildbuffer genom funktionen flycapturegrabimage. För att spara bilden på hårddisken används flycapturesaveimage. Alla bilder sparas som standard i PPM-format, bildbehandlingen vill också ha detta format. PPM är väldigt ineffektivt format och skapar därför stora bildfiler. För att inte överföringshastigheten mellan enheterna ska bli en flaskhals kommer därför bilderna komprimeras med flycaptureconvertimage och sedan omvandlas tillbaka till PPM-format på masterenheten. De flesta funktioner returnerar ett FlyCaptureError för att meddela om det har gått bra eller misslyckats. För att kunna läsa detta meddelande används funktionen flycaptureerrortostring. 18

Referenser LiTH [1] Point Greys hemsida för Bumblebee 2 http://www.ptgrey.com/products/bumblebee2/ 2010-09-22 [2] Projektgruppen Carpe Locus tekniska dokumentation [3] Triclops programmerings manual http://www.cs.ucdavis.edu/~amenta/3dphoto/triclops.pdf 19

Appendix A - Nätverksprotokoll Kommunikationen mellan scout- och masterenhet sker över WLAN via TCP/IP. Ett meddelande består av en header följt av data. Headern består i sin tur av tre variabler på vardera 32 bitar, se tabell 4. Variabel Typ Beskrivning Msg ID int32 ID för meddelandet Msg Size uint32 Antalet databytes efter header Msg Sum uint32 Checksumma Tabell 4. Headerformat. Checksumman är en summering av alla bytes i det skickade meddelandet exklusive headern. En lista över de olika meddelandetyperna visas i tabell 5. Mer detaljerad information om de nya meddelandena kan ses i sektion. För övriga meddelanden finns ytterligare information i Carpe Locus tekniska dokumentation [2]. Riktning nedan anger från vilken enhet meddelanden sänds. Id Meddelandetyp 0 HeartBeat 1 Manual 2 Automatic 3 CameraSettings 4 GPSData 5 WheelData 6 IMUData 7 Status 8 CameraData Tabell 5. Specifikation av meddelandetyper. ID 3 CameraSettings Riktning: Master Scout Används för att ändra stereokamerans inställningar från masterenheten. Flaggan stop bestämmer om kamera ska vara på (0) eller av (1). Tre olika upplösningar kan väljas med hjälp av flaggan resolution. Om flaggan är 0 används hög upplösning (1024x768), om den är 1 används istället den lägre upplösningen 640x480 eller 2 så används 320x240. Antalet bilder som kameran tar per sekund kan väljas fritt i intervallet 0 20 fps. Typ Header int int double Namn Header stop resolution fps Tabell 6. Specifikation av kamerainställningsmeddelandet. 20

ID 8 CameraData Riktning: Scout Master Används för att skicka ett stereobildpar samt den position och vinkel scoutenheten hade då bilderna togs. Typ Header Vect double double Image Image Namn Header position angle time leftimage rightimage Tabell 7. Specifikation av kamerameddelandet. 21

Appendix B - Konventioner För att dokument och kod ska se enhetlig ut har vi valt att använda samma konventioner som de tidigare projektgrupperna. Dokumentkonventioner Följande dokumentkonventioner har användas: Inget stycke får sakna inledande text. Kodkonventioner Följande kodkonventioner har används: Engelska används vid all namngivning. Klasser har formen av substantiv i singularis, t.ex. Odometer eller namnet på modulen t.ex. NetworkModule. Metoder har formen Verb alternativt VerbSubstantiv, t.ex. Send, GetAngle. Klass- och metodnamn använder PascalCase, vilket innebär första tecknet i varje ord versalt. Datamedlemmar, lokala variabler samt parametrar använder camelcase, t.ex. operationlist. Inga understreck i namn på varken klasser, datamedlemmar eller metoder. Indentering är två positioner, mellanslag (space) inte tab. Curly-braces placeras på egen rad med samma indentering som föregående instruktion, sk. Allman indent style. Ett mellanrum runt operatorer, dock inte före eller efter parenteser i funktionsdefinitioner och funktionsanrop. För integrala typer används direkt anrop med värde, för större typer används konstantreferenser eller pekare. Samma för returtyper. 22

I kodruta 1 följer ett exempel på hur kod i C++ har formateras. class MyClass : public ABase { public: int MyMethod(int thisisaparameter, const AnotherClass &anotherclassinput); private: AnotherClass data; } int MyClass::MyMethod(int thisisaparameter, const AnotherClass &anotherclassinput) { data = anotherclassinput; if(thisisaparameter <= 4) { return thisisaparameter * 2; } return thisisaparameter + 4; } Kodruta 1. Exempel på hur kod i C++ ska formateras. 23