Teknisk dokumentation - isy.liu.se · Styrkort NI PCI-6024E Kopplingsplatta, BNC-2110, med tillh...

Teknisk dokumentationLiU Racetrack

Version 1.0

Forfattare: Salko BjelevacDatum: 15 december 2014

Status

Granskad Projektgruppen 2014-12-12Godkand Isak Nielsen 2014-12-15

Kursnamn: Reglerteknisk projektkurs E-post: [email protected]: FAST Dokumentansvarig: Salko BjelevacKurskod: TSRT10 Forfattarens e-post: [email protected]: LiU Racetrack Dokument: Teknisk dokumentation.pdf

Projektidentitet

E-post: [email protected]: http://www.isy.liu.se/edu/projekt/tsrt10/2014/racetrack/

Bestallare: Isak Nielsen, Linkopings universitetTelefon: 013-28 28 04E-post: [email protected]

Kund: Daniel Axehill, Linkopings universitetTelefon: 013-28 40 42E-post: [email protected]

Kursansvarig: Daniel Axehill, Linkopings universitetTelefon: 013-28 40 42E-post: [email protected]

Projektledare: Kristin BergstrandTelefon: 070-63 66 388E-post: [email protected]

Handledare: Kristoffer Lundahl, Linkopings universitetTelefon: 013-28 66 23E-post: [email protected]

Gruppmedlemmar

Namn Ansvarsroller Telefon E-post(@student.liu.se)

Kristin Bergstrand (KB) Projektledare (PL) 070-63 66 388 kribe281Mans Klingspor (MK) Informationsansvarig (IA) 070-55 25 053 mankl061Joachim Larsson (JL) Mjukvaruansvarig (MA) 073-06 71 511 joala815John Wilhelms (JW) Testansvaring (TA) 070-40 84 358 johwi572Erik Hedberg (EH) Designansvarig (DA) 070-51 22 275 erihe251Salko Bjelevac (SB) Dokumentansvarig (DOC) 076-22 66 599 salbj522Marcus Trulsson (MT) Hardvaruansvarig (HA) 073-35 45 432 martr316Oskar Ljungqvist (OL) Leveransansvarig (LA) 070-57 71 868 osklj052

Dokumenthistorik

Version Datum Forandringar Sign Granskad1.0 2014-12-15 Godkand OL Projektgrupp


Innehall

1 Inledning 1

1.1 Syfte och mal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Anvandning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Systemoversikt 2

3 Hardvara 3

4 Mjukvara 4

4.1 Mjukvarumiljo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.2 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.3 Utveckling under 2014 ars projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5 Kommunikation mellan datorerna 5

5.1 Kommunikationsprotokoll for RRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.2 Kommunikationsprotokoll for GPGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.3 Kommunikationsprotokoll for styrningsinformation av lastbilen . . . . . . . . . . . . . . . 7

6 Delsystem: Malfoljning 8

6.1 Utveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6.2 Markorpositioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6.3 Skattning av dollyvinklar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6.4 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7 Delsystem: Hinderhanteringssystem 11

7.1 Implementering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7.1.1 Klass for geometriska figurer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7.1.2 Hinderklass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7.1.3 Sensorklass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7.1.4 Hinderdetektering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7.2 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

8 Delsystem: Beslutssystem 13

8.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

8.2 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

9 Delsystem: Referensgenerering 15

9.1 Lokala trajektorier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

9.2 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

9.2.1 Optimeringsproblemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

9.2.2 Bilmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

9.2.3 Regulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

9.2.4 Samplingsstrategier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

9.2.5 Rapidly-exploring Random Tree (RRT) . . . . . . . . . . . . . . . . . . . . . . . . 20

9.3 Korlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

9.3.1 Sakerhetslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

9.3.2 Racinglage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.4 Det implementerade RRT-programmet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.4.1 Uppstart av programmet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.4.2 DEV MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.4.3 RUNNING WITH SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.4.4 Under simulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.4.5 Skillnader mellan simuleringsmiljo och racetracksystem . . . . . . . . . . . . . . . 23

9.4.6 Hantering av dynamiska hinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

9.5 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

9.6 Utvecklingsmojligheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

10 Adaptiv anpassning av hastighetsprofilen 26

10.1 Optimeringsproblemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

10.2 Parametrisering av optimal trajektoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

10.3 Gaussian Processes for Global Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . 31

10.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

10.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

10.6 Utvecklingsmojligheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

10.7 Avslutande ord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

10.8 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

11 Delsystem: Reglering 45

11.1 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

12 Delsystem: Manuell styrning av lastbil 45

12.1 Raspberry Pi och D/A konverterare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

12.2 Skickande av styrsignaler fran datorn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

13 Delsystem: Visualisering och GUI 46

13.1 Utseende och funktionalitet for GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

13.2 Projektion pa bilbanan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

14 Delsystem: Simulator 50

14.1 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

14.2 Simuleringssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

14.2.1 Fordonsmodeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

14.2.2 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51


LiU Racetrack 1

1 Inledning

Systemet som beskrivs i detta dokument har utvecklats under flera tidigare ars projekt,senast OSAAR2013. Systemet bestar i korta drag av en bilbana med radiostyrda bilarsamt utrustning for att folja och styra bilarna ifran en dator. Systemet ska i framtidenanvandas i demonstrationssyfte, men aven i utbildnings- och forskningssyfte.

Systemets hardvara, mjukvara och de funktionella delsystemen beskrivs utforligt i dettadokument. Da systemet ar en utveckling fran tidigare ar, laggs fokus framforallt pa dedelar av systemet som tillkommer i och med detta projekt, Fast and Adaptive SteeringTechnology, (FAST). En oversikt av de tidigare projekten ges nedan.

• Sommarprojekt 2011 - Systemet byggdes.

• TSRT10 2011 - Fokus pa reglering och optimal trajektoria.

• Sommarprojektet 2012 - Fokus lag pa att forbattra bilmodellerna.

• TSRT10 2012 - Regleringen och den optimala banan forfinades.

• Sommarprojekt 2013 - Malfoljningen forbattrades. Projektor installerades.

• TSRT10 2013 - Visualiseringen utvecklades bland annat. Projektorn implementera-des och GUI:t utvecklades.

For en mer ingaende beskrivning av det befintliga systemet hanvisas till de tidigare tek-niska dokumentationenerna, framforallt till den tekniska dokumentationen fran No Oscil-lation Corporation, projektet ifran ar 2013 [3].

1.1 Syfte och mal

Syftet med projektet var att utveckla det befintliga systemet genom att implementera nyfunktionalitet samt utveckla redan befintlig sadan. Projektet skulle bidra till att i framti-den gora systemet anvandbart inom forskning men ocksa attraktivare for demonstrering,till exempel vid studiebesok.

1.2 Anvandning

Systemet ska efter detta projekt fortsatta att anvandas inom forskning, i undervisnings-syfte och vid demonstrationer av avdelningen for reglerteknik pa ISY.

1.3 Definitioner

Har defineras flodesscheman och begrepp som anvands i dokumentet.

Trajektoria: Den beraknade korvagen som ges av referensgenereringssystemet.

Hinder: Hinder ar objekt pa banan som markerar ej tillaten korvag for bilen. Hinderkan vara statiska eller dynamiska. De kan vara virtuella och visualiserade pa banan medprojektorn eller fysiska genom lastbilen eller blockformade objekt. Hindren har en breddpa maximalt 10 cm placerade ortogonalt mot banriktningen. De dynamiska hindrena kanrora sig i alla riktningar.


LiU Racetrack 2

Aktiva hinder: Aktiva hinder ar hinder som befinner sig i bilens planerade korvag.

Omkorning: Omkorning innebar att avvika fran den forberaknade referenstrajektoriankring banan for att folja en beraknad omkorningstrajektoria. Nar hindret ar passerat skabilen sedan manovrera tillbaka till den ursprungliga trajektorian och sedan fortsatta attfolja denna.

Flodesscheman: Flodesscheman anvands for att tydliggora olika system och processer.Figur 1 forklarar vad symbolerna i sadana scheman betyder om inte annat anges.

Figur 1: Forklaring av de symboler som huvudsakligen kommer att anvandas iflodesdiagrammen i det har dokumentet.

2 Systemoversikt

Den enklaste uppdelning av systemet som kan goras ar att dela in systemet i en del somska styras, samt en del som utfor styrningen. Malfoljningssystemet samlar den nodvandigainformationen och resultatet visualiseras av visualiseringssystemet. Systemet kan ocksa de-las upp i delsystem som alla finns i denna rapport. Det som styrs ar radiostyrda bilar ochen radiostyrd lastbil, pa en bana tillverkad i skumgummi. Styrningen av bilarna sker franen dator som med hjalp av IR-kameror kan folja bilarna. Med hjalp av en inkoppling pabilarnas fjarrkontroller kan datorn skicka styrsignaler till fordonen men lastbilen kan avenstyras fran dator via tangentbordet. En projektor gor att datorn kan visualisera motta-gen information direkt pa banan. Datorn kan aven simulera hur bilarna skulle reagera paolika styrsignaler. Huvuddelen av systemets komplexitet finns alltsa i koden som datornexekverar.

Systemet kan ocksa delas upp i delsystem efter funktionalitet, se Figur 2. Tre av delsy-stemen representerar den funktionalitet som konceptuellt finns i sjalva bilarna; beslutssy-stemet som avgor vilka val bilen ska gora, referensgenereringen, som genererar den vagbilen ska forsoka folja i varje givet ogonblick, samt regleringen vars syfte ar att fa bilenatt folja den valda vagen. I detta ars projekt har referensgenereringssystemet utokats medRapidly exploring Random Tree (RRT) och Gaussian Processes for Global Optimization(GPGO).

Ytterligare tva delssystem behovs for att hantera den information bilen behover for attgora ratt val. Malfoljningen identifierar objekt pa banan och kan darmed aven kan ge bileninformation om vilket tillstand den har. Malfoljningen identiferar aven andra objekt, som


LiU Racetrack 3

da utgor hinder for den aktuella bilen och darmed hanteras av hinderhanteringen. Hinder-hanteringen tar delvis emot information fran malfoljningen samtidigt som den hanteraranvandardefinierade virtuella hinder. Hinder pa banan kan sedan detekteras av bilensvirtuella hindersensorer, vilket sker genom kommunikation mellan beslutssystemet ochhinderhanteringssystemet.

Visualiseringen visar information om systemets tillstand via projektorn och pa datorskarmensamt tillater anvandaren att interagera med systemet via ett GUI under korning. Visua-liseringssystemet utgor ytterligare ett delsystem i systemet FAST.

Eftersom en del av projektet ar att integrera en radiostyrd lastbil i systemet beskriver viaven den funktionaliteten som ett delsystem.

Figur 2: Funktionell oversikt av systemet, dar de delsystem systemet delats upp i mar-kerats med gront. Referensgenereringen valjer vilken bana regleringen skall forsoka folja.Regleringen staller ut styrsignaler antingen till de fysiska bilarna eller till simulatorn.Malfoljningssystemet skattar bilarnas tillstand samt foljer fysiska hinder.

3 Hardvara

Den hardvara som fanns att tillga i projektet vid start:

• Bilbana

• Tre radiostyrda bilar, Kyosho dnano [7]

• Radiostyrd lastbil innefattande dragbil, dolly och slap

• Handkontroller

• Tva IR-kameror

• Projektor

• PC: rt-pc-11

• PC: rt-pc-03

• Styrkort NI PCI-6024E

• Kopplingsplatta, BNC-2110, med tillhorande kablar


LiU Racetrack 4

Den hardvara som har lagts till under projektets gang ar;

• Raspberry Pi B+ med tillbehor

• SparkFun I2C D/A-omvandlare - MCP4725

• Microchip I2C D/A-omvandlare - TC1321EOA

• Extra natverkskort i rt-pc-11 och rt-pc-03

• Natverksswitch med ett antal ethernetsladdar

• Hinder, pappersbit 10 x 10 cm med IR-markorer

• Hinder, pappersbit 5 x 5 cm med IR-markorer

For att uppfylla kraven for styrning av lastbilen var ny hardvara tvungen att inhandlas.Initialt fordes diskussioner kring att anvanda styrkort NI PCI-6723. Da National Instru-ments har ett hogt pris for denna produkt och poangterade att deras support inte ar tillfor studenter eller projekt som inte anvander deras egen mjukvara LabVIEW undersoktesalternativ. Det alternativ som ansags mest attraktivt var att anvanda I2C bussen paen Raspberry Pi for att stalla ut signaler till D/A omvandlare. Efter att ha undersokttidsatgangen att stalla ut en analog utsignal fran ett kommando over natverket till rasp-berry Pi datorn och skicka tillbaka ett meddelande om utford atgard pa samma natverkkunde slutsatser dras kring systemets tidsatgang. Tidsatgangen for detta var oftast straxunder 4 ms. Systems andamal ar att mojliggora reglering for autonomt korning av lastbi-len, systemets uppmatta tidsatgangen anses acceptabel da den i relation till resten av styr-systemets tidsatgang ar liten. I Figur 3 kan det nuvarande systemets hardvaruppbyggnadses.

Figur 3: Schematisk bild av hur systemet med tillagd hardvara kommunicerar.

4 Mjukvara

Detta avsnitt beskriver hur mjukvaran ar strukturerad och hur den har utvecklats underdetta projekt. Fokus har legat pa att strukturera upp koden.


LiU Racetrack 5

4.1 Mjukvarumiljo

Programmet for det overgripande systemet ar skrivet i programmeringsspraket C++.Utvecklingsmiljon ar en PC med Windows 7.0 och koden kompileras genom MicrosoftVisual C++ 2010.

Mjukvaran ar beroende av foljande externa bibliotek:

• NI-DAQmx fran National Instruments, for att hantera styrkortet.

• OpenCV, ett fritt mjukvaruprojekt for bildbehandling.

• FlyCapture2 fran Grey Research for att hantera IR-kamerorna.

4.2 Struktur

Da delsystemen arbetar parallellt med varandra ar mjukvaran uppdelad i fyra sa kalladetradar.

• Gui thread: Trad for anvandargranssnittet.

• Run thread: Trad for malfoljningssystemet.

• Regulator thread: Trad for reglersystemet.

• Draw thread: Trad for visualiseringssystemet.

Utover det overgripande systemet som beskrivits ovan har tva nya program utvecklats.

• RRT: (Rapidly exploring Random Tree) anvands for att berakna ny referenstrajek-toria vid omkorning och ar skrivet i C++.

• GPGO: (Gaussian Process for Global Optimization) anvands for att adaptivt forbattravarvtiderna for bilen och ar skrivet i Matlab

Dessa tva program kors pa separata datorer och kommunikation mellan programmen ochhuvudprogrammet sker med en natverksswitch.

4.3 Utveckling under 2014 ars projekt

For att i framtiden kunna satta sig in i koden snabbt, underlatta felsokning samt imple-mentering av ny funktionalitet har ett stort arbete lagts pa att stada och strukturera omkoden. Detta tillsammans med att filer har delats in i delprojekt har lett till att kodeni nagon man kan betraktas som modular. Dock aterstar en hel del arbete for att kodenverkligen ska vara modular och en hel del arbete aterstar ocksa om man ska kunna kallakoden objektorienterad.

5 Kommunikation mellan datorerna

For okad moduluppbyggnad har systemet utvecklats till att vara uppdelat pa flera dato-rer, en kommunikationslank har satts upp for att dessa ska kunna kommunicera. Dennakommunikationslank ar ett lokalt natverk i laborationssalen. For att mojliggora dettaanvands natverkskort tilldelade statiskt IP-adresser som ar kopplade med ethernet sladd


LiU Racetrack 6

till en natverksswitch. I Tabell 1 ses de tilldelade IP-adresserna till respektive dator.

En extern dator som kopplas till systemet kan valja ett statiskt ip enligt 192.168.0.xxexkluderat de redan anvanda, natverksmasken ska sattas till 255.255.0.0.

Dator Statisk IP-adressRt-pc-03 192.168.0.9rt-pc-11 192.168.0.99Raspberry pi 192.168.0.1Extern dator 192.168.0.xx

Tabell 1: I denna tabell presenteras de statiska IP-adresser datorerna i laborationssalentilldelats for det lokala natverket. For en extern datorn innebar xx ett tal mellan 0-99uteslutet de redan anvanda numren for de andra datorerna.

For att kommunikationen inte ska fastna i brandvaggar har porten 27015 exkluderats franbrandvaggen pa datorn rt-pc-11. Denna dator har darfor kunnat goras till en TCP-serverdit TCP-klienter kan ansluta pa denna port nar Racetrack-systemet kors.

Den kommunikation som idag fors over det lokala natverket kan ses i Tabell 2. Kommu-nikationsprotokollen for denna information behandlas nedan.

Kommunikation mellan datorer Typ av informationRt-pc-11, rt-pc-03 RRT-informationRt-pc-11, extern dator GPGO-informationRaspberry pi, rt-pc-03 Styrnings-information for lastbilen

Tabell 2: I denna tabell presenteras vilken information som skickas mellan vilka datorer.Den dator som skrivs forst agerar server, den andra klient. Den externa datorn maste hamojlighet att kora Matlab 2014b for att kunna kora GPGO kommunikationen.

Figur 4: Schematisk bild av hur RRT- och GPGO-informationsutbyte initieras. For attansluta en TCP-klient som har mojlighet att kommunicera skickas INIT CONNECTION.Darefter skickas packet i bada riktningarna med forst packet type och sedan client typefor att specificera vilken information som nu kommer skickas. Darefter skickas den avseddainformationen.

5.1 Kommunikationsprotokoll for RRT

For att skicka RRT-information maste det schema som beskrivs i Figur 4 anvandas for attinitiera sandningen. I Tabell 3 presenteras de konstanter som initierar RRT overforing av


LiU Racetrack 7

information. Efter RRT kommunikation ar initierad kommer specifik RRT-information attskickas en gang. Denna information ar specifik for vilken riktning informationen gar. Franrt-pc-11 till rt-pc-03 skickas bilen och hindrets position vid upptackandet av ett hinder.Fran rt-pc-03 till rt-pc-11 skickas trajektorian for omkorning da en sadan har beraknats.Forst skickas da langden av antalet trajektoria punkter darefter X,Y och θ varden fortrajektorian.

For att se hur detta definieras i koden studera NetworkData.h, struct Packet SERVER to RRToch struct Packet RRT to SERVER. Det ar viktigt att NetworkData.h ar definierad li-kadant pa server och klient sidan av kommunikationen och att alla packetvariabler arinitierade.

Kommunikationkonstanter for RRT VardeINIT CONNECTION 0RRT EVENT 1RRT CLIENT 0

Tabell 3: I denna tabell presenteras de konstanter som skickas for att initiera en RRTinformationsoverforing. RRT EVENT och RRT CLIENT behover skickas varje gang nyRRT information ska overforas.

5.2 Kommunikationsprotokoll for GPGO

For att skicka GPGO-information maste det schema som beskrivs i Figur 4 anvandasfor att initiera sandningen. I Tabell 4 presenteras de konstanter som initierar GPGOoverforing av information. Efter GPGO kommunikation ar initierad kommer specifikGPGO-information att skickas en gang. Denna information ar specifik for vilken rikt-ning informationen gar. Fran en extern dator som kor GPGO till rt-pc-11 skickas forsten 1001 lang vektor innehallande en hastighetsprofil. Dessa kommer i rt-pc-11 att skri-vas till textfilen GPGO-vVec.txt och lasas in av programmet precis innan bilen kor forbimallinjen. Fran rt-pc-11 till en extern datorn som kor GPGO skickas en varvtid nar ettvarv med en uppdaterad hastighetsprofil har avklarats.

For att se hur detta definieras i koden studera NetworkData.h, struct Packet SERVER to GPGOoch struct Packet GPGO to SERVER.

Kommunikationkonstanter for GPGO VardeINIT CONNECTION 0GPGO EVENT 3GPGO CLIENT 1

Tabell 4: I denna tabell presenteras de konstanter som skickas for att initiera en GPGOinformationsoverforing. GPGO EVENT och GPGO CLIENT behover skickas varje gangny GPGO information ska overforas.

5.3 Kommunikationsprotokoll for styrningsinformation av lastbi-len

Kommunikationen for styrning av lastbilen sker mellan rt-pc-03 och Raspberry Pi datorn.Raspberry Pi datorn ar en TCP-server och rt-pc-03 ar TCP-klient, kommunikationen sker


LiU Racetrack 8

pa port 27016. Den information som behover kommuniceras for att kunna styra lastbi-len ar kor framat/bakat, styr hoger/vanster och storlek for dessa styrsignaler. Detta harimplementerats genom att skicka en character buffer med 5 varden fran rt-pc-03, darforsta biten beskriver om denna styrsignal ar for korning framat/bakat eller for styrninghoger/vanster. Om denna bit ar en nolla adresseras korning framat/bakat, darefter lasesde resterande 4 bitarna som en styrsignal med ett varde i intervallet 0-3000, detta mot-svarar en utsignal pa 0-3.2 V, dar 1480 motsvarar 1,6 V vilket innebar stillastaende. Omden forsta biten ar en etta adresseras styrning hoger/vanster, darefter lases de resterande4 bitarna som en styrsignal med ett varde i intervallet 0-4000, detta motsvarar en utsignalpa 0-3.2 V, dar 1850 ar 1,6 V vilket innebar styrning rakt fram. Varfor de tva styrsignal-sintervallena skiljer sig at beror pa att digital- till analog-korten ar av tva olika fabrikatoch samma funktion anvands for att adressera bada tva och da skiljer de sig at lite iadresseringen.

6 Delsystem: Malfoljning

Malfoljningssystemet har som uppgift att detektera fordon och hinder pa banan och skattadess tillstand. Det bestar av tva IR-kameror och en observator. IR-kamerorna ar monte-rade i taket ovanfor bilbanan och pa fordonens tak sitter reflexmarkorer. Informationenfran IR-kamerorna anvands som matsignal i observatoren som skattar bilens tillstand.Malfoljningssystemet tar hansyn till markorernas placering i rummet i tre dimensioner. IFigur 5 ges en oversikt av Malfoljningssystemet.

For mer detaljerad information av malfoljningssystemet hanvisas lasaren till den tekniskadokumentationen ifran foregaende ars projekt [3].

Figur 5: Denna figur illustrerar malfoljningssystemets interaktion med sin omgivning. Somframgar ar skillnaden mellan hur hinder och bilar hanteras liten.

6.1 Utveckling

Systemet har utokats och har nu formagan att folja hinder med godtycklig dynamik, vilketprincipiellt ar detsamma som att folja en bil utan kand dynamisk modell. For att kunnafolja dynamiska hinder pa ett bra satt anvander sig systemet av en generell modell som lattkan andras och anpassas till olika situationer, till exempel en konstant hastighetsmodell.For att malfoljningssystemet ska kunna se skillnad pa olika hindertyper har varje objekten speciell geometri pa reflexmarkorerna, och information om reflexmarkorernas position


LiU Racetrack 9

for varje hinder finns hardkodade i filen CarMarkerCameraIdentParam.cpp. Under rubri-ken Markorpositioner nedan har de nya och uppdaterade reflexmarkorgeometrierna forfordon och fysiska hinder beskrivits. En annan funktionalitet som har implementerats arvinkelskattning for lastbilekpiaget, vilket det star mer om i Avsnitt 6.3.

6.2 Markorpositioner

Nedan beskrivs de nya markorpositionerna for lastbilsekipaget och for de fysiska hindren.Markorpositionerna for de sma bilarna har inte andrats och tas inte upp har, men finnsbeskrivna i foregaende ars tekniska dokumentation [3].

Lastbil (ID 3) x [m] y [m] z [m] Slap (ID 4) x [m] y [m] z [m]Markor 1 0.073 -0.023 0.101 Markor 1 0.118 0.0 0.095Markor 2 0.04 0.024 0.103 Markor 2 0.088 -0.034 0.095Markor 3 0.04 -0.024 0.013 Markor 3 -0.1 0.031 0.095Markor 4 -0.072 0.0 0.018 Markor 4 -0.1 -0.031 0.095

Dolly (ID 5) x [m] y [m] z [m] Hinder 1 (ID 6) x [m] y [m] z [m]Markor 1 0.0 0.04 0.089 Markor 1 0.04 0.0475 -0.018Markor 2 0.017 -0.020 0.089 Markor 2 -0.04 0.0475 -0.018Markor 3 -0.017 -0.04 0.089 Markor 3 -0.02 -0.0275 -0.018

Markor 4 0.04 -0.0475 -0.018

Hinder 2 (ID 7) x [m] y [m] z [m]Markor 1 0.018 0.02 -0.018Markor 2 -0.018 0.02 -0.018Markor 3 -0.018 -0.02 -0.018Markor 4 0.02 -0.02 -0.018

Tabell 5: Tabell over de uppdaterade positionerna for fordon och fysiska hinder. Forovriga fordons positioner, se [3]. Positionerna ar markorernas positioner i ett kroppsfastkoordinatsystem med origo i fordonets eller hindrets centrum.

6.3 Skattning av dollyvinklar

For att skatta dollyvinklarna α och β for lastbilsekipage i Figur 6 har tva olika formleranvants. Den ena tar hansyn till dollyns position och den andra gor det inte och des-sa formler beskrivs nedan. Beskrivningen av vinkelestimeringen ar i detta dokument liteforenklad for att inte komplicera lasandet men i filen angles.cpp finns koden for vinkeles-timering tillganglig for narmare inspektion.

For att skatta α och β utan dollyns position har (1) - (2) anvants

α � arctan

�p1y � p2yp1x � p2x

� θ1 (1)

β � arctan

�p1y � p2yp1x � p2x

� θ2 (2)

dar θ1 och θ2 ar lastbilens respektive slapets vinkel i globala koordinater och p1x, p1y ochp2x, p2y ar bakre punkten pa lastbilen samt framre punkten pa slapet, se Figur 6.


LiU Racetrack 10

Figur 6: Illustration av lastbilsekipaget, innefattande lastbil, dolly och slap. Vinklarnasom ska estimeras ar α och β. I figuren syns ocksa det globala koordinatsystemet, det villsaga bilbanans koordinatsystem.

For att gora skattningen sakrare kan aven dollyns position tas med i berakningarna, enligt(3) - (4), dar medelvardet av vinkeln mellan lastbil slap samt mellan lastbil och dolly ellerslap och dolly beraknas. Dollyns vinkel har inte tagits hansyn till och det ar nagot som iframtiden skulle kunna implementeras och formodligen oka prestandan nagot.

α �arctan

�p1y�p2yp1x�p2x

� arctan


2

� θ1 (3)

β �arctan


� arctan


2

� θ2 (4)

dar p3x och p3y ar dollyns mittpunkts position i X- och Y-led, se Figur 6.

For att utvardera prestandan for vinkelestimeringen utfordes tester da lastbilsekipagetstod still pa bilbanan. Resultaten av testerna kan ses i Tabell 6 for vinkelskattning utandollyposition och i Tabell 7 for vinkelskattning med dollyposition.

Fall nr: α r�s β r�s Skattad α r�s Skattad β r�s1 -30 -30 -30�1.2 -30�1.22 -30 0 -30�1.2 0�1.23 -30 20 -30�1.2 20�1.24 0 -30 0�1.2 -30�1.25 0 0 0�1 0�16 0 20 0�1.2 20�1.27 20 -30 20�1.2 -30�1.28 20 0 20�1.2 0�1.29 20 20 20�1.2 20�1.2

Tabell 6: De vinklar som ska skattas for lastbil och slap utan hjalp av dollyns position.De skattade vardena skrivs ut som ett genomsnittligt varde och en maximal avvikelse.

Slutsatsen som kan dras av Tabell 6 ar att vinkelskattningen ger lika bra resultat for olikavinkelkombinationer och att avvikelsen endast ar �1.2. Tabell 7 visar att prestandan kanforbattras ytterligare da dollyns position tas med i berakningarna. Da blir avvikelsenendast �1. Att precisionen inte blir hogre an sa tror vi har mycket att gora med attkamerornas precision bara ar 2mm, vilket bidrar till skattningsfel.


LiU Racetrack 11

Fall nr: α r�s β r�s Skattad α r�s Skattad β r�s1 30 -30 30�1 -30�12 -20 0 -20�1 0�13 -10 20 -10�1 20�1

Tabell 7: De vinklar som ska skattas for lastbil och slap med hjalp av dollyns position. Deskattade vardena skrivs ut som ett genomsnittligt varde och en maximal avvikelse.

6.4 Granssnitt

Malfoljningssystemets granssnitt presenteras i Tabell 6.4.

Insignaler BeskrivningBilder Bilder fran IR-kamerorna.UtsignalerPosition pX,Y q, hastighet vx, vy, vinklar θ, α, β Information om objekt skickas till de

andra delsystemen

Tabell 8: I denna tabell presenteras alla in- och utsignaler som malfoljningsystemetanvander sig av och genererar.

7 Delsystem: Hinderhanteringssystem

Hinderhanteringssystemets uppgift ar att hantera information om alla fysiska och virtuellahinder pa bilbanan. Beslutssystemet som sitter i bilen skickar en forfragan till hinderhan-teringssystemet om det finns nagra hinder inom bilens valbara omrade. Om sa ar falletfar beslutssystemet ta del av information om de aktuella hindrena, exempelvis positionoch utbredning.

7.1 Implementering

Hindersystemet har implementerats enligt foljande.

7.1.1 Klass for geometriska figurer

Hinder och bilens virtuella sensorer representeras som geometriska objekt. For dettaandamal ar klassen Shape skapad som en virtuell klass. Foljande konkreta, geometris-ka figurer arver fran denna klass:

• Circle: Enkel cirkelskiva.

• Trapezoid: Fyrhorning med tva parallella sidor (ej lika langa) och tva likbenta”ben”. Mer specifikt: Denna klass representerar en likbent parallelltrapets.

• Square: Enkel rektangel. Att klassen inte heter Rectangle som battre skulle beskri-va klassen beror pa en namnkonflikt med en inbyggd Windows-funktion.

Dessa geometriska figurer har utbredning men ar inte bundna till nagon fix position. Detva sistnamnda har dock varsin medlem i form av en vinkel som hjalper till att orienterafiguren i det globala koordinatsystemet.


LiU Racetrack 12

7.1.2 Hinderklass

Hinder implementeras genom klassen Obstacle. Hinder har alltid formen av en rektangelvarfor klassen har en medlem som ar av klassen Square. Detta ger hindret sin geomet-riska utbredning i det faktiska systemet. Dessutom har hinder en position i det globalakoordinatsystemet som anges i form av koordinater i X- och Y -led. Hinder kan bade varastatiska och dynamiska. For ett dynamiskt hinder (som kan rora pa sig) har klassen tvamedlemmar i form av vektorer, trajectory_x och trajectory_y som anger den trajek-toria hindret ror sig utefter i X- respektive Y -led. For att skilja olika typer av hinderat har klassen Obstacle en medlem obstacle_type i form av ett heltal. Detta hjalperanvandaren att dela upp hindren i olika kategorier sasom virtuella, fysiska, statiska ochdynamiska eller skraddarsydda typer av hinder.

7.1.3 Sensorklass

Varje reglerad bil har numera en aktiv medlem fran klassen Sensor. Denna klass har enmedlem som anger vilken sensortyp som ar aktiv och de olika sensortyperna som ges iform av klassen Shape. Dessutom har klassen en lista over vilka typer av hinder som kandetekteras och dessa bestams av anvandaren vid initiering. Anvandandaren anger sjalvvilka bilar som ar reglerade och darmed i behov av virtuella sensorer.

7.1.4 Hinderdetektering

For att avgora om ett hinder ar innanfor en bils sensoromrade anvands en teknik sombygger pa Seperating Axis Theorem. Satsen lyder i sin enkelhet att givet tva konvexa,geometriska figurer (alla figurer i Shape-klassen ar konvexa) overlappar varandra om ochendast om det inte gar att dra en rat linje mellan dem. Denna metod anvands myc-ket inom spelprogrammering och implementationen av densamma ar enkel. Algoritmenar dessutom snabb och helt saker (hinder detekteras alltid om sensoromrade overlapparhindrets utbredning).

7.2 Granssnitt

Insignaler BeskrivningPosition, hastighet, utbredning Far information om fysiska hinder pa

bilbanan fran malfoljningssystemet.UtsignalerPosition och utbredning av ett specifikt hinder Skickar information om hinder i bilens

hindersensorers valbara omrade till be-slutssystemet.

Tabell 9: I denna tabell presenteras alla in- och utsignaler som hinderhanteringssystemetanvander sig av och genererar.


LiU Racetrack 13

8 Delsystem: Beslutssystem

Detta avsnitt beskriver den beslutsfattande delen i bilen. Malet med beslutssystemet aratt kunna reagera pa hinder som bilen far information om.

Figur 7: Illustration av detektion av hinder. Ett hinder kommer in i bilens avstandssensoreroch information om hindret laggs in i beslutssystemets lista over hinder i bilens synfalt.

8.1 Implementation

Implementationen av detta system har gjorts i filen regulator.cpp. Dar har beslutsfattan-det for vad bilen ska gora da ett hinder detekteras av dess sensorer implementerats, seFigur 8. De olika besluten och handelserna kommer har forklaras mera detaljerat.

Detekterat hinder?: Hinderlistan for bilarna pa banan itereras igenom. Ar hinderlistantom ser bilen inget hinder. Ar den inte tom ser bilens sensorer ett hinder. Ar hinderlistaninte tom for den kontrollerade bilen har ett hinder detekterats och detta block returnerar“ja”.

Stanna bilen: Den kontrollerade bilen stannas genom att satta en flagan som heterSTOP CAR till “true” for dennes kontrollobjekt “totcontroller”. Flaggan satter utsigna-len for gaspadraget till -1. Systemet kommer aven borja skicka information om bilen ochhindrets position till en eventuell RRT-klient.

Omkorningstrajektoria mottagen?: Systemet kommer i varje loop att fraga om kom-munikationen har tagit emot nagon uppdaterad trajektoria. Om inte detta har skettkommer systemet fortsatta skicka bilen och hindrets position tills detta uppfylls. KorsRRT-klienten pa rt-pc-03 kommer denna efter att ha tagit emot information om bilen ochhindret att svara med en omkorningstrajektoria om en sadan ar mojlig att rakna ut ochdetta block kommer da returnerar “ja”.

Folj ny trajektoria langsamt: Nar en ny trajektoria ar mottagen kommer denna sparastemporart. Systemet fragar vilket index pa optimala referenstrajektorian som ar narmastbilens position. Detta index (refererars vidare som startindex) anvands som utgangspunktfor att skriva over den optimala referenstrajektorian med den mottagna fran RRT’n. Nardetta ar utfort satts en flagga som heter SLOW MOVE till “true” i den kontrolleradebilens kontrollobjekt. Denna tillater langsam framfart (hardkodad hastighet i totcontrol-ler.cpp). Nu kommer den kontrollerade bilen att folja den mottagna RRT trajektorianlangsamt.

Har hindret passerats?: Sa lange hindret inte har passerats kommer bilens position att


LiU Racetrack 14

jamforas med startindex adderat med mottagna trajektorians langd. Overskrider bilensposition startindex adderat med trajektorians langd anses hindret passerat.

Las in optimala trajektorian: Nar hindret har passerats lases den optimala trajektori-an over de positioner dar RRT-trajektorian har skrivits. Normal hastighet kommer sattastill bilen genom att satta SLOW MOVE till “false” och kommunikation med RRT-klientstangs av.

Fortsatt kora i normallage: Har kor bilen i normallage och kan ta emot GPGO -kommunikation eller starta denna besluts process om sensorerna detekterar ett hinder.

Figur 8: Flodesschema over hur beslutsystemet reagerar pa hinder.

8.2 Granssnitt

I Tabell 10 visas den information som detta delsystem behover fran andra system ochvilka utsignaler detta genererar.


LiU Racetrack 15

Insignaler BeskrivningHinder Far information om hinder inom bilens

hindersensorers valbara omrade franhinderhanteringssystemet.

Bilens tillstand Information om bilens tillstand for attkunna jamfora absolut position av hin-der och bil

RRT-trajektoria X,Y och θ varden som beskriver enomkorningstrajektoria kring ett hinder.

UtsignalerBeslut Skickar beslut till referensgenererings-

systemet vilken typ av trajektoria somska genereras

Visualisering Skickar information till visualiserings-systemet att t.ex. rita ut att ett hinderar upptackt av bilen.

Tabell 10: I denna tabell presenteras alla in- och utsignaler som beslutssystemet anvandersig av och genererar.

9 Delsystem: Referensgenerering

Referensgenereringssystemets uppgift ar att generera de referenstrajektorier som reglersy-stemet ska reglera bilen efter. Referensgenereringssystemet styrs av beslutssystemet, somfattar de principiella besluten om hur bilen ska bete sig. Figur 10 illustrerar strukturen forhur flodet planeras att utformas. I normalfallet matas en forberaknad optimal trajektoriain till reglersystemet, men nar ett hinder upptacks i bilens planerade korvag tar ett lokaltsystem i bilen over referensgenereringsarbetet for att generera en ny, tillfallig trajektoriarunt hindret. Tills dess att hindret ar passerat foljer bilen denna lokala trajektoria istalletfor det optimala banvarvet. Figur 9 illusterar bilbanan och den forberaknade optimalatrajektorian.

Datn for den optimala trajektorian innehaller aven vilka vinklar och hastigheter som bilenteoretiskt skulle ha da den kor langs den optimala trajektorian. Da bilen har svart attfolja trajektorian pa det satt som ar optimalt har darfor istallet hastigheterna ersattsmed en lag hastighet som systemet sedan successivt forsoker optimera genom metoderfran maskininlarning, vilket beskrivs i Avsnitt 10.

9.1 Lokala trajektorier

Beraknandet av de lokala trajektorierna ar tankt att implementeras med hjalp av envagplaneringsalgoritm kallad Rapidly exploring Random Tree (RRT). I korthet kan detbeskrivas som att man pa ett smart satt simulerar vad olika styrsignaler vid olika fram-tida tidpunkter skulle ge for resultat, med andra ord en slags heurestik. Denna typ avavsokningsmetodik har tidigare provats och visat sig mycket lyckad i exempelvis [5], [9]och [6]. I de tva senare har RRT anvants just for att berakna trajektorier for bilar, ochi framfor allt [6] har det visats att det ar mojligt att generera en lamplig trajektoria tillbilen i realtid med denna metodik.

Om ett hinder som ar placerat ivagen for den optimala trajektorian har hittats ska RRT:nberakna en ny trajektoria, med avsikten att fora bilen runt hindret och sedan hjalpaden tillbaka till den optimala trajektorian. Problematik som finns med konceptet RRT


LiU Racetrack 16

Figur 9: Bilbanan avbildad med den forberaknade optimala trajektorian utritad i blatt.

Figur 10: Oversikt av referensgenereringssystemet. Referensgenereringssystemet valjermellan att fortsatta leverera den forberaknade optimala trajektorian till reglersystemetoch att rakna ut en ny lokal trajektoria for att kunna passera hinder. Den blaa rombensymboliserar beslut som tas av beslutssystemet.

ar att det ar berakningskravande och i svara fall tar det realtivt lang tid att finna enlamplig trajektoria. Genom att dela upp problemet i delmal gar det dock att paskyndaplaneringen. RRT:n slumpar positioner pa banan pa en smart satt och sedan, med hjalpav bilens kinematik, beraknas en styrlag for att folja en mojlig cirkelbage till positionen.Denna slumpgenerering kallas hadanefter for en sampling. Styrlagen som anvands for attberakna trajektorian for den bilmodell som simuleras i RRT:n kallas Pure Pursuit ochbeskrivs i [4] och bygger enbart pa ren geometri. Denna algoritm har implementerats iC++ av Niclas Evestedt och har sedan anvants av denna grupp for att nicha koden forvart endamal. En skarmdump av programmet kan ses i Figur 11


LiU Racetrack 17

Figur 11: Figurerna visar en skarmdump fran Niclas Evestedts RRT-simulator. I dettafll simuleras en omkorning av ett hinder. Bilen star i detta fall still och beraknar entrajektoria forbi hindret till malet pa andra sidan (gul cirkel). Nar en trajektoria (helrodlinje) har hittats paborjas omkorningen och under omkorningen forbattras den tanktatrajektoria successivt fran ny information och nya samplingar. De gula linjerna ar desamplade referenspunkterna som Pure pursuit regulatorn har reglerat mot.

9.2 Teori

Den grundlaggande teorin bakom konceptet RRT ar omfattande och beskrivs utforligt iexempelvis [5]. I detta dokument kommer bara den konceptuella strukturen for algoritmenatt tas upp. I [6] forslas det att det ar enklare att sampla ett slutet stabilt system ochsaledes sampla referensvarden till en regulator istallet for att sampla faktiska styrsignalertill systemet. For att framat-simulera system anvands en kinematisk bilmodell som sedanaterkopplas med en vagplanerande regulator sa givna referenspositioner kan foljas, enillustration av det slutna systemet som darmed erhalls kan ses i Figur 12.

Figur 12: Figuren visar det sluta systemet som anvands for en framat-simuleringar medRRT. Givet en referens punkt raknar regulatorn ut en lamplig styrlag till bilen.


LiU Racetrack 18

9.2.1 Optimeringsproblemet

Denna sektion definerar vagplanerings-problemet. Givet ett system som beskrivs av enolinjar modell

9pptq � fppptq,uptqq, pp0q � p0 (5)

dar p och u ar modellens tillstand respektive styrsignaler och p0 ar initialtillstandenvid tiden t � 0. Givet att det finns bivillkor for bade tillstanden och styrsignalerna somfangas av bivillkoren U respektive Xfreeptq. Bivillkoret U beskriver eventuella stysignalsbe-gransningar och Xfreeptq beskriver omgivningen dar det ar tillatet att befinna sig. Vidarehar vi kravet att pptf q P Xgoal som anger att vi har ett krav pa sluttillstandet vid tident � tf . Optimeringsproblemet kan slutligen formuleras som; berakna styrsignalsekvensenuptq, t P r0, tf s, tf P r0,8q som minimerar

minimizeu

tf � Γppptf qq

subject to

#9pptq � fppptq,uptqq, pp0q � p0, pptf q P Xgoal

pptq P Xfreeptq, uptq P U

(6)

dar Γppptf qq ar ett straff pa systemets sluttillstand. Givet konstant hastighet oversattsminimeringsproblemet till ett kortastevag-problem med en tillaggskostnad for systemetsslutkonfiguration pptf q.

9.2.2 Bilmodell

I RRT-programmet anvands en enkel kinematisk beskrivning av bilen. Den kinematiskamodellen (7) som anvands bestar av tre tillstand p � rX,Y, θsT ; bilens position pX,Y q somar position av mittpunkten av dess bakre axeln i globala koordinater och bilen orienteringθ med avseende pa det globala koordinatsystemet. L ar langden mellan bilens fram- ochbakaxel. Insignalerna till bilen ar hastigheten v och styrvinkel γ , u � rv, γsT . Alla dessatillstand och styrsignaler ar illuserarade i Figur 13.$'&

'%9X � v cos θ9Y � v sin θ9θ � Gsspvq

vL tan γ

(7)

dar

Gss �1

1��

|v|VCH

(8)

Gss ska beskriva inverkan av slip vid en given hastighet och VCH har valts till 20 [cm/s] ut-an nagra tester mer an vid simulering och ska valjas sa att underlagets friktion sa bra sommojligt modelleras. Inverkan av Gss ar att bilen kommer understyra vid hoga hastigheter.Den kinematiska modellen (7) ar sedan diskretiserad med euler-framat approximation avderivata vid implementering. I och med att (8) ar ett statiskt samband behover den intediskretiseras.

9.2.3 Regulator

For att kunna sampla referenspunkter till vart slutna system vid simulering av trajektorieranvands en vag foljande regulator kallad Pure-pursuit. Den arbetar med ett look-ahead


LiU Racetrack 19

Figur 13: Figuren illusterar alla de tillstand, styrsignaler och designparametrar somanvands av bilmodellen och regulatorn Pure-pursuit vid simulering av en trajektoria medRRT:n.

avstand R och givet en referenspunkt den vill na (I Figur 13 benamnt som px, yq) beraknasen styrlag for att na denna punkten. Eftersom att bilen hela tiden kommer forflytta sigkommer aven referenspunkten att gora det samma och man erhaller en mjuk rorelse. Justorre look-ahead avstad desto mjukare bana. Om look-ahead avstandet valjs for kort kanstabilitet inte garanteras och det ar saledes en avvagning mellan foljsamhet och robusthet.

Styrlagen erhalls genom rena geometriska samband och en harledning har gjorts nedan(Se Figur 13 for definition av variablerna som anvands):

x� d �r (9a)

x2 � y2 �R2 (9b)

y2 � d2 �y2 � pr � xq2 � r2 ô (9c)

r2 � 2rx� x2 � y2loomoon�R2

�r2 ñ r �R2

2x�

R2

2R sin θe�

R

2 sin θe(9d)

Dar r ar onskad kurvradie. Vidare med hjalp av sambandet v � �r 9θ (Negativt tecken pagrund av att θ ar definerad positiv moturs.) och (7) far vi till slut onskad styrlag (10) dar


LiU Racetrack 20

θe ar riktingsavvikelsen mot malet.

γ � � arctan

�L

r

� � arctan

�2L sin θeRGss

(10)

Denna styrlag anvands for att sluta loopen vid framat-simuleringar.

9.2.4 Samplingsstrategier

Som ovan namnt samplas referenspositioner till var regulator vid framat-simulering. Den-na sampling kommer besta av en lista med tre olika kommandon per element px, y, vcmdqidar i P t1, ..., nrefu ar mal placerade med jamna mellanrum for att pure-pursuit regulatornska fa ett glidande mal att folja. Den sista referenspunkten ar den som samplas och se-dan skapas stodpunkter bakat iterativt. vcmd bestams deterministiskt sa att sista referenspunkten far hastighet noll. Sampling av px, yqnref

gors med olika samplingsstrategier ochde tva som anvands ar gaussisk-sampling och arc-sampling. Gaussisk-sampling som medhjalp av nagon referens position px0, y0q ar given av�

xy

�nref

�

�x0 � σxnxy0 � σyny

�(11)

dar σx och σy ar standard avvikelse i respektive led och ar design parametrar. ni ar enstandard gaussisk slumpvariabel. Arc-sampling ar lite annurlunda och lyder: Givet enrefrensposition px0, y0, θ0q ges den samplade punkten av

�xy

�nref

�

�x0y0

�� r

�cos θsin θ

�dar

#r � σr|nr| � r0

θ � σθnθ � θ0(12)

dar σr och σθ ar standard avvikelse i radial och i omkrets rikting och ni ar aven har enstandard gaussisk slumpvariabel.

9.2.5 Rapidly-exploring Random Tree (RRT)

Med utgangspunkt i en kombination av [5], [9] och [6] har strukturen for en forenkladalgoritm av var RRT tagis fram och visas i Algoritm 1. I algoritmen initieras forst varRRT och det skapas en RRT-planerare som innehaller en tom tradstruktur, en bilmodell,(del)mal och en karta over alla for bilen kanda hinder och vaggar pa banan.

Algorithm 1 Body to RRT

1: initiate RRT2: while RRT is activated do3: Uppdate vehicle states and obstacles4: while t ∆T do5: ExpandTree();6: end while7: if Trajectory is found then8: Send trajectory to server9: end if

10: end while


LiU Racetrack 21

Efter att var RRT har initierats byggs losningstradet genom att sampla referensvardentill var vagfoljande regulator. Detta gors under en begransad tid ∆T och efter detta sautvarderas tradet och om en trajektoria har hittats till malet sa skickas denna via TCP tillhuvudprogrammet. Efter detta sa upprepas proceduren igen med uppdaterade tillstandpa bilen och hindret erhalls via TCP fran huvudprogrammet. Funktionen ExpandTree()

som beskriver hela RRT funktionaliteten ar beskriver i psedukod i Algoritm 2.

Algorithm 2 ExpandTree():

1: xrand Ð SampelpGoal position, position of car, Sampel strategyq;2: if xrand P Xfree then3: Generate a random variable between 0 and 1 called Optimize4: if Optimize ¡ 0.7 then5: Xnear Ð NearpTree structure, xrandq;6: for xnear P Xnear do7: Try to connect with nearest neighbour8: end for9: else

10: Try to connect xrand with root of the tree11: end if12: end if13: if fesibleTrajectoryFound() then14: BestNode Ð GetBestNode(Tree structure);15: end if

Denna funktion borjar med att genera en ny samplad referensposition givet en samplings-trategi som gor med funktionsanropet Sampel(). Nar ett sampel har genererats kontrol-leras det sa att samplet hamnade inuti tillatet omrade Xfree, vilket definieras som allapunkter som ar inuti banan som inte ar inuti ett hinder. Nar ett lampligt sampel har ge-nererats kommer 70% av gangerna samplet forsoka paras ihop med rooten av tradet ochresterande 30% av gangerna undersoks vilka nara grannar som redan finns i tradstrukturensom gors med funktionsanropet Near(). Om det saknas grannar kommer istallet roten tilltradet att valjas som foralder om detta ar mojligt. Alla nara grannar genomsoks for atthitta den billigaste foraldern att koppla ihop sig med. Samtidigt kontrolleras att ingethinder mellan sampels omojliggor ihopkoppling. I slutet av varje iteration kontrollerassedan om vi har hittat en trajektoria som tar oss till vart mal eller delmal. Slutvillkoretpa funktionen feasibleTrajectoryFound() avgor ifall en nod ska bedomas som frammeeller ej. Detta avgors beroende pa om nodens tillstand ar tillrackligt nara malets onskadetillstand i bade aspekten position och vinkel.

9.3 Korlagen

Det finns tva olika korlagen som ger olika typer av beteenden for fordonet vid omkorningeller vid vajning av hinder, sakerhetslage och racinglage. Vilket lage som ar aktivt bestamsav anvandaren i anvandargranssnittet. Korlagena har olika samplingsstrategier i RRTprogrammet, och just nu anvands bara sakerhetslaget nar programmet kommunicerarmed racetracksystemet. Att kunna anvanda bade ett racinglage och ett sakerhetslage iracetracksystemet ar nagot som vi ser som en potentiell vidareutveckling.

9.3.1 Sakerhetslage

I sakerhetslagen paborjas en omkorningen endast nar RRT:n har lyckats att generera enfull trajektoria forbi hela objektet. Detta gor att det inte existerar en tidspress under sjalva


LiU Racetrack 22

berakningen av trajektorian eller att paborja en omkorning eftersom hela trajektorianredan ar fardigraknad vid start av omkorningen. Samplingsstrategin i sakerhetslaget aratt enbart hitta en saker vag fram till nasta checkpoint. Detta resulterar i en sakrareomkorningsprocedur eftersom fordonet inte behover chansa pa att RRT:n ska hitta enfullstandig omkorningstrajektoria.

9.3.2 Racinglage

I racinglaget dar RRT:n ska anvandas for att berakna en omkorning staller hardare kravpa prestanda med avseende pa snabbhet. For att paskynda referensgenereringen ska samp-lingstrategin dela upp sin sokning mellan en korvag fram till nasta checkpoint, och tillcheckpointen efter det. Pa det viset kommer omkorningen att kunna ske snabbare an isakerhetslagen, pa bekostnad av att kanske inte den allra snabbaste vagen hittas.

9.4 Det implementerade RRT-programmet

Algoritmerna for RRT har implementerats i racetracksystemet. I denna del kommer sy-stemets RRT applikation att presenteras. RRTs uppgift ar att givet fordonets tillstandoch information om hinder berakna en omkorningstrajektoria.

9.4.1 Uppstart av programmet

Programmet som kor RRT hittas pa rt-pc-03 (den nya datorn) i mappenC:/Temp/OSAAR/RRT/RRT 2014 Final. For att starta programmet oppnar man fi-len 1project solution.sln. Programmet realiserar Algoritm 1 och 2 som beskrivs iteoriavsnittet. I MAIN.cpp valjer anvandaren ifall RRT ska koras mot racetracksyste-met eller i utvecklingsmiljon. Detta gors genom att definiera antingen DEV MODE ellerRUNNING WITH SERVER. Vill man gora andringar i programvaran for DEV MODE vara akti-verat for att enkelt kunna testa sina andringar i simuleringsmiljon.For att starta programmet ar det enklast att trycka ctrl + F5 fran projektet. Det medforatt programmet kor exekveringsfilen i release-mappen.

9.4.2 DEV MODE

I utvecklingslaget kors programmet i en simuleringsmiljo istallet for att det kommuniceramed racetracksystemet. Sjalva miljon ar konstruerad att likna racetrackbanan sa mycketsom mojligt, vilket har gjorts genom att mata bilbanan och utforma banan i simulerings-miljon i samma form och storlek. Simuleringsmiljon illustreras i Figur 14.

9.4.3 RUNNING WITH SERVER

Detta laget startar kommunikationslanken med racetracksystemet. Nu kommer bilen pabanan, nar dess sensorer detekterar ett hinder, att invanta en trajektoria fran RRT. Foratt skicka en omkorningstrajektoria till racetracksystemet kor man RRT applikationenefter det att ett hinder detekterats.

9.4.4 Under simulering

Under den simulerade korningen har de samplingsstrategier som beskrevs i teoriavsnittetimplementerats. Hur de samplade referenspunkterna och deras stodpunkter ser ut och


LiU Racetrack 23

Figur 14: Simuleringsmiljon for RRT applikationen. Banan ska i storsta mojliga man efter-likna korvagen for det fysikaliska systemet for att kunna berakna en omkorningstrajektoriamed samma begransningar som finns i racetracksystemet.

hjalper regulatorn att styra mot malet syns i Figur 15. Genom att hogerklicka pa skarmenkan man valja olika visningslagen.

9.4.5 Skillnader mellan simuleringsmiljo och racetracksystem

Det finns vissa skillnader mellan det fysikaliska systemet och simuleringen. Viktigt attkomma ihag nar man genomfor andringar i RRT programmet ar att strackor uttrycks icentimeter [cm] och hastighet i centimeter per sekund [cm/s], men i ovrigt ar koordinat-systemen identiska.

9.4.6 Hantering av dynamiska hinder

For att hantera dynamiska hinder skattas hindrets position framat i tiden med hjalp avkonstant hastighets antaganden och kollisionskontroll gor sedan med tiden pa bade hindretoch bilen. En omkorningstrajektoria kan endast fullfoljas om det inte finns nagon kollisioni nagot samplingsogonblick.

9.5 Granssnitt

Vilka in- och utsignaler som delsystemet behover beskrivs i Tabell 11.

9.6 Utvecklingsmojligheter

Det finns flera utvecklingsomraden for referensgenereringssystemet. Utover att arbeta pakommunikationslanken mellan RRT och racetracksystemet for att fa systemet mer robust,foreslar vi foljande:

• Testa lampligare samplingsstrategier for att hitta battre vagar runt hinder.


LiU Racetrack 24

Figur 15: Referenspunkter och stodpunkter i RRT programmet. De bla linjerna illustrerarreferens- och stodpunkter medan den gula linjen ar det trad som ger den billigaste vagenmellan fordonets position och malet. Den roda linjen ar den vag som fordonet kommer attfolja. Sampelstrategin tillater grenarna att kopplas ihop vilket hjalper fordonet att hittaen vag till malet.

Insignaler InformationArray med med hinder Hindrets position, orientering, storlek

och dynamik.Bilens tillstand Position och hastighet.UtsignalerGenererad trajektoria Flagga for fardig genererad trajektoria.Trajektoria Den beraknade trajektorian som bestar

av positioner med tillhorande girvinkelpa bilen i varje punkt.

Tabell 11: I denna tabell presenteras alla in- och utsignaler som RRT:n anvander sig avoch genererar.

• Implementera racinglage for att kunna genomfora snabbare omkorningar genom attplacera ut lampliga delmal.

• Det finns funktionalitet for att soka mot bade den kommande och nastkommande


LiU Racetrack 25

(del)malet (RacingMode). Detta bor kunna utnyttjas genom att delmal placeras utforhoppningsvis ska da aven hinder i svara kurvor ska kunna undvikas snabbt ochsnyggt.

• Fa till integreringen i racetracksystemet battre. Exempelvis for att trajektorian of-tare ska kunna uppdateras. I nulaget laggs bara en ny trajektoria in en gang ochsedan uppdateras den inte.

• Byt fordonsmodell i RRT programmet mot en modell som i storre utstrackningliknar den racerbil som anvands i racetracksystemet.

• PID-regulatorn som anvands av Racetrack skiljer sig tyvarr for mycket fran pure-pursuit reglatorn som gor att bilen i verkligheten inte klarar folja foreslagen trajek-toria. Antingen maste man gora trajektorian fran RRT:n mer konservativ eller bordet bytas regulator i racetracksystemet mot en regulator som faktiskt reglerar medhjalp av framtida information fran trajektorian.


LiU Racetrack 26

10 Adaptiv anpassning av hastighetsprofilen

Som namnts i tidigare avsnitt finns en trajektoria beraknad som under vissa forutsattningarmotsvarar ett optimalt satt att kora runt banan, aven kallad den optiamala trajektorian.Trajektorian innehaller positioner samt vilka vinklar, vinkelhastigheter och hastigheterbilen optimalt skall ha for att kunna ta sig runt banan pa kortast mojliga tid. Det hardock visat sig att systemet har svart att folja trajektorian med de optimala hastigheter-na. Detta antas bero pa att den modell av bilen som anvandes vid framtagandet av denoptimala trajektorian inte representerar verkligheten tillrackligt bra.

I forra arets projekt implementerades en adaptiv hastighetsprofil med mal att minimeravarvtiden. Principiellt fungerade den pa sa satt att da trajektorian foljs bra okas hastig-heten successivt och om avvikelsen till trajektorian ar stor sanks hastigheten. For vidaredetaljer hanvisas lasaren till forra arets tekniska dokumentation [3]. Denna implemente-ring skedde ad hoc och fungerade inte helt tillfredstallande. En av arets uppgifter vardarfor att utveckla en ny adaptiv algoritm med hjalp av valdokumenterade metoder franlarande system.

10.1 Optimeringsproblemet

Den uppgift som systemet ska losa genom anvandning av adaptiva metoder kan beskri-vas som ett optimeringsproblem. Vi vill minimera tiden det tar for bilen att kora ettvarv runt bilbanan. Detta genom att valja hastighetsprofilen optimalt, sa den ar ar-gument till malfunktionen. Vart optimeringsproblem karakteriseras av att det tar langtid att evaluera malfunktionen, det vill saga att kora ett varv kring banan. Vi behoverdarfor en algoritm som valjer varje hastighetsprofil till utvardering med omsorg. Eftertips fran amnesexperter har vi anvant oss av metoden Gaussian Processes for GlobalOptimization (GPGO) [8], som forfattarna till artikeln havdar ar val lampad till dennatyp av problem. Metoden tillampar ett ramverk med gaussiska processer for att beskrivaden okanda malfunktionen. Mer bakgrund kring gaussiska processer i ett bredare ma-skininlarningssammanhang finns i [11]. Vi har fatt stor hjalp av Andreas Svensson franUppsala Universitet som fungerat som teknisk expert for GPGO.

10.2 Parametrisering av optimal trajektoria

For att metoden GPGO ska vara anvandbar kravs att rummet av mojliga insignaler intehar for hog dimension. Det har darfor varit nodvandigt att parametrisera hastighets-profilen, som i dagslaget har 1001 punkter, sa att dess utseende helt bestams av farreparametrar. En styckvis affin approximation anvands for att utoka antalet parametrar till1001. Detta genom en linjar interpolation mellan tva parametrar i taget. Figur 16 ochFigur 17 visar hur hastighetsprofilen for den forberaknade optimala trajektorian ser utrespektive var dessa paramatrar fysiskt befinner sig pa banan.


LiU Racetrack 27

Figur 16: Optimal hastighet beraknad fran tidigare ars projektkurs. En styckvis affinapproximation anvands for att utoka antalet parametrar till 1001.

Figur 17: Grafisk illustration var de tretton parametrar som beskriver den optimala tra-jektorian fysiskt befinner sig pa bilbanan.


LiU Racetrack 28

Under lang tid parametriserade vi hastighetsprofilen efter den optimala trajektorian vilketfungerade, men inte helt tillfredstallande. Genom testning av forra arets adaptiva imple-mentation analyserade vi hastighetsprofilen. Vi kom fram till att den optimala trajektorianej speglar verkligheten val med avseende pa vilka parametrar som beskriver utseendet pahastighetsprofilen, se Figur 18. Med avseende pa detta parametriserade vid hastighets-profilen med femton parametrar, se Figur 19, vilket fungerade markant battre. Se Figur20 for en illustration var de femton parametrarna befinner sig fysiskt pa bilbanan.

Figur 18: Jamforelse av ett den optimala trajektorian och ett varv kort pa bilbanan medforra arets adaptiva hastighetsprofil.


LiU Racetrack 29

Figur 19: Hastighetsprofil for ett varv pa bilbanan evaluerat med forra arets adaptivahastighetsprofil. En styckvis affin approximation anvands for att beskriva kurvan. Dettaokar antalet parametrar fran 15 till 1001.


LiU Racetrack 30

Figur 20: Grafisk illustration var de femton parametrar som beskriver hastighetsprofilenfor ett varv, utraknat fran forra arets adaptiva ad hoc implementation, fysiskt befinnersig pa bilbanan.


LiU Racetrack 31

10.3 Gaussian Processes for Global Optimization

Gaussian Processes for Global Optimization baseras pa att rummet av kandidater till denokanda malfunktionen beskrivs i termer av gaussiska processer. Om vi later x vara enhastighetsprofil och ypxq varvtiden som fas da hastighetsprofilen anvands sa kan vi skriva:

ppy|xq � N py;µpxq,Kpx, x1qq �∣∣2πKpx, xq∣∣� 1

2 e�0.5py�µpxqqTKpxq�1py�µpxqq

dar K � Kpx, x1q ar den kovariansfunktion beskriver kovariansen hos varvtiden mellan tvaolika hastighetsprofiler och µpxq ar vantevardet av varvtiden for en viss hastighetsprofil.

Eftersom vi inte kanner µ eller K maste ingenjorskunskaper anvandas for att skapa funk-tioner som hjalpligt beskriver dessa forhallanden. Da det finns ett visst osakerhetsmattsa valjer vi funktioner som ar parametriserade och infor fordelningar for dessa paramet-rar, kallade hyperparametrar och betecknade θ. Hyperparametrar ar alltsa parametrarsom paverkar systemet, men som vi inte ar intresserade av, men anda maste ta med iberakningarna. En av utmaningarna ar hur kovariansfunktionen Kpx, x1q ska valjas. Detfinns en uppsjo av olika kovariansfunktioner foreslagna i [11] och vi har valt ’squaredexponential’:

Kpx, x1q � expp�1

2|x� x1|2q

I ovanstaende exempel ar faktorn 12 nagot som i teorin typiskt ingar i hyperparametrar θ.

Genom att anvanda notation fran [8] kan vi nu skriva sannolikheten for varvtid y� vid enej annu testad hastighetsprofil x� som:

ppy�|x�, θ, I0q � N py�;mθpy�|I0q, Cθpy�|I0qq

dar:

mθpy�|I0q � µθpx�q �Kθpx�, x0qKθpx0, x0q�1py0 � µθpx0qq

Cθpy�|I0q � Kθpx�, x�q �Kθpx�, x0qKθpx0, x0q�1Kθpx0, x�q

I0 ar en informationsmatris som inkluderar all tidigare erfarenhet, inklusive de funktions-utvarderingar som gjorts. De hastighetsprofiler som tidigare utvarderats betecknas x0 ochderas resulaterande varvtider y0.

Inneborden av det ovanstaende ar att vi fatt ett uttryck for vantevardet och kovariansenav varvtiden som en oprovad hastighetsprofil kommer att resultera i. Vi ser aven att omvi tidigare har utvarderat andra hastighetsprofiler, kommer vi med hjalp av kovarians-funktionen K att kunna anvanda de matningarna for att justera vart vantevarde och gorasakrare forutsagelser.

Iden med GPGO ar att optimera over dessa forutsagelser, sa att vi alltid utvarderar denhastighetsprofil som kommer att ge oss den basta blandningen av ny information och chanstill lag vartid. For att kunna gora detta kan vi definiera forlusten, λpx�q, pa foljande satt:

λpx�q �

"y� : y� minpy0qminpy0q : y� ¡ minpy0q


LiU Racetrack 32

Vi vill valja xs� sa att nasta funktionsutvardering y�px�q minimerar den forvantadeforlusten, Erλpx�s. Eftersom vi vet vad y0 ar och har uttryck for fordelningen hos y� kanvi ta fram uttryck for fordelningen hos λpx�. Att ta fram detta uttryck ar lite omstandigt,men kraver inget mer an vanlig sannolikhetslara och kannedom om normalfordelningar,for detaljerna hanvisar vi till [8]. Kontentan ar att eftersom fordelningen hos y� beskrivs avnormalfordelningar sa gor fordelningen av λ ocksa det, och ar da val lampad for numeriskoptimering.

Men for att minimera Erλpx�qs med avseende enbart pa x� behover hyperparametrarna θmarginaliseras bort ur sannolikhetsfordelningarna. Denna marginalisering ar svar att goraanalytiskt, och maste darfor approximeras numeriskt, till exempel med Bayesian MonteCarlo (BMC) metodik.

Nar vi alltsa har ett uttryck for Erλpx�qs sa kan vi minimera det numeriskt och valjaatt utvardera det x� (det vill saga den hastighetsprofil) som minimerar den forvantadeforlusten. Vi kallar denna forlustfunktion for V:

V px|I0q � η � pmθ � ηqΦpη;mθ, Cq � CN pη;mθ, Cq

dar:

η � minpy0q

Eftersom vi inte i varje iteration forsoker uppna en sa lag varvtid som mojligt blir dennametod friare att undersoka hastighetsprofiler som skulle kunna vara riktigt bra men ocksariktigt daliga, och kommer darfor att pa ett battre satt gora en avvagning av vad mani maskininlarningssammanhang kallar ”exploit” (att optimera varvtiden) och ”explore”(att lara sig mer om funktionen). Se Figur 21- 24 nedan hur GPGO principiellt fungerarmed en parameter. For detaljer hanvisas lasaren till GPGO dokumentationen [8].


LiU Racetrack 33

Figur 21: Principiell beskrivning hur GPGO i en parameter fungerar. Prickad svartlinje beskriver den okanda malfunktionen som vi vill optimera. Roda linje beskrivervantevarden for evaluerade varden, det vill saga hur vi tror att malfunktionen ser utgivet gammal information. Det rosa omradet beskriver kovarians for evaluerade varden.Bla linje beskriver forlustfunktionen som vi vill minimera. I x � 1.6 har vi samplat forutoch ar darfor sakra pa hur fuktionen ser ut i denna punkt (liten kovarians). Minimum paforlustfunktionen ar har x � 0.


LiU Racetrack 34

Figur 22: Da x � 0 var minimum pa forlustfunktionen samplar vi har. Detta leder till attkovariansen minskar i x � 0. Vi blir alltsa mer sakra hur den okanda malfunktionen serut for varje sampel. Vi far nu en ny forlustfunktion som minimeras. Denna gang liggerminimum pa x � 3.7.


LiU Racetrack 35

Figur 23: Da x � 3.7 var minimum pa forlustfunktionen samplar vi har. Detta leder tillatt kovariansen minskar i x � 3.7.Vi far nu en ny forlustfunktion som minimeras. Dennagang ligger minimum pa x � 6.


LiU Racetrack 36

Figur 24: Da x � 6 var minimum pa forlustfunktionen samplar vi har. Detta leder till attkovariansen minskar i x � 6. Som synes far vi mer och mer information hur malfunktionenser ut for varje sampel. Aven om varvtiden inte blir battre direkt sa ar all information brainformation med avseende pa att vi far mer information om malfunktionens utseende.


LiU Racetrack 37

10.4 Implementation

Vi har implementerat GPGO i Matlab pa en extern dator. Vi anvander oss av Matlab-biblioteket Gaussian Processes for Machine Learning (GPML) [11]. Genom att anvandaGPML-biblioteket skots en hel del av teorin av biblioteket [10]. Svarheten har varit attskapa en brygga mellan teorin i GPGO och funktionaliteten i GPML. Vi skickar datamellan den externa datorn och rt-pc-11 over TCP (Transmission Control Protocol). Pro-grammet ar modulart uppbyggt och det enda som kravs ar en Ethernet-kabel samt attandra installning till statiskt IP pa den externa datorn. Huvudprogrammet i C++ part-pc-11 startas forst och nagon gang under korning startar anvandaren GPGO genomatt exekvera det forsta blocket i filen main.m. GPGO borjar da att rakna ut en hastig-hetsprofil. Nar hastighetsprofilen ar utraknad och vi anvant en splinefunktion for att okaantalet parametrar till 1001 skickas den till rt-pc-11. GPGO-implementationen vantar dapa att fa tillbaka en varvtid. Se Figur 25 for en grov skiss over GPGO-implementationen.Filstrukturen pa GPGO-implementationen ser ut enligt Figur 26.

Figur 25: Gransnitt for GPGO-implementationen pa extern PC och rt-pc-11 over TCP .


LiU Racetrack 38

Figur 26: Filstruktur over implementationen av GPGO i Matlab med tillhorande beskriv-ning av varje fil.


LiU Racetrack 39

Som synes finns det tva textfiler som lases in vid uppstart. Dessa ser ut enligt Figur 27och Figur 28. Vid nerstangning av programmet maste anvandaren spara ner nya vardenmanuellt genom att kora det andra blocket i GPGO-implementationen i filen main.m.Detta for att anvandaren ska gora ett aktivt val att spara ner nya varden for att forhindraatt daliga varden sparas ner vid exempelvis oavsiktligt avbrott av korning.

Figur 27: I filen Velocity paramaters.txt specificeras evaluerade hastighetsprofiler och lad-das in vid start av programmet. Filen har en ny hastighetsprofil per rad och varden pa alla15 parametrar finns pa varje rad, skiljt av ett kommatecken. Till exempel hastighetsprofil1 har hastigheten 4.91 i parameter 1 och hastigheten 2.079 i parameter 2.

Figur 28: I filen Laptime.txt specificeras varvtider av evaluerade hastighetsprofiler speci-ficerade i filen Velocity parameters.txt. Filen har en ny varvtid per rad och langden pa debada textfilerna maste overenstamma. Till exempel hastighetsprofil 5 fick en varvtid pa8.1 sekunder.

Huvudprogrammet finns i main.m och bestar av tva block. Det forsta blocket innehallerinitiering, huvudloopen, kommunikation och spline. Det andra blocket innehaller en funk-tion for att spara varden om resultatet ar tillfredstallande. Se Figur 29 for en schematiskbild av huvudprogrammet.


LiU Racetrack 40

Figur 29: Schematisk bild over implementationen av GPGO i Matlab. I bilden syns ini-tiering, huvudloopen med modifiering av upplosningsvektorn och optimering i form av-gridsokning och numerisk optimering

Koden ar valkommenterad men specifika detaljer som nya anvandare behover veta tas upphar. For ovriga implementationsspecifika fragor hanvisas lasaren till kallkoden respektivedokumentation for GPGO [8] och GPML [10][11].

num of param = 15Antalet parametrar vi optimerar over.

hb vec = [. . . ]’Kolumnvektor med en ovre grans for hastigheten i varje parameter.

lb vec = [. . . ]’Kolumnvektor med en undre grans for hastigheten i varje parameter. Notera attlangden av hb vec och lb vec maste vara lika med antalet parametrar.

res vec = [3 4 3 2 3 2 2 3 3 2 2 2 2 2 2 ]’Kolumnvektor med upplosningen pa varje parameter som gridsokningen ska un-dersoka. Denna uppdateras automatiskt genom hjalpfunktionen modify res vec.m.


LiU Racetrack 41

hyp2Vi definierar hyperparametrar genom att bland annat lagga in vantevarde- och ko-variansfunktion i en strukt med namnet hyp2.

num of iterations = 4Antalet ganger som huvudloopen ska itereras innan en utrakning ar klar. En gridsokningoch en numerisk optimering per iteration. Idag tar fyra iterationer ungefar 2-3 se-kunder och en onskvard ovre grans minimum av den basta varvtiden.

xpos = [1 70 134 172 247 290 361 414 461 531 627 671 749 800 886 1001 ]Index pa parametrarna pa den optimala trajektorian. Langden pa vektorn mastevara lika med antalet parametrar.

testsetKor Matlab-funktionen linspace beorende pa lb vec, hb vec och res vec. Skapar enmatris over varden som gridsokningen ska testa.

get all combinations(num of param, testset, res vec)Funktionen get all combinations.m skapar en kombinationsmatris over alla kombi-nationer av varden i matrisen testset.

gp(. . . )Inbyggd funktion i GPML-biblioteket som raknar ut vantevardena och kovarianserfor kombinationsmatrisen viktat med alla gamla hastighetsprofiler och varvtider.Det ar alltsa mθpy�|I0q och Cθpy�|I0q vi far ut har. Detta ar var gridsokning.

fmincon(. . . )Inbyggd funktion i Matlab som minimerar var forlustfunktion V. Begynnelsevardettill fmincon ar resultatet fran var gridsokning.

modify res vec.mHjalpfunktion som analyserar resultatet mellan gridsokningen och den numeriskaoptimeringen for att modifiera res vec. Genom att andra pa res vec varje iterationgors gridsokning pa nya omraden som kan tankas vara intressanta att testa. Tankenar att om differansen mellan resultatet av var gridsokning och den numeriska opti-meringen ar liten ar vi sakrare pa dessa parametrar an de parametrar som har hogdifferans. Vi minskar da upplosningen pa dessa parametrar och kan oka pa andra.Detta for att kombinationsmatrisen inte ska vaxa okontrollerat.

Styckvis affin approximationDen optimala trajektorian bestar av 1001 punkter. Darmed maste de parametrarsom optimeringen tagit fram anvanda en linjar interpolation for att fa upp antaletparametrar till just 1001. For att kunna anvanda den linjara interpolationen laggervi till en parameter pa slutet. Den utokade parametern har samma varde som pa-rameter 1 da den forsta och sista punkten pa trajektorian har samma koordinater.Resultatet blir en styckvis affin approximation.

Langd pa x0 och y0 - gammal informationHur manga gamla varden kan vi vikta in innan det kostar for mycket berakningstid?Vid runt 80 gamla varvtider marks stor skillnad jamfort med farre an 50 varden,men uppfyller fortfarande kravet att rakna ut en ny hastighetsprofil pa mindre anett varv. Dock ar det inget problem i sig att berakningarna tar langre tid. Det kanvara vart att ta bort dubblerad information fran x0 och y0 for att gora rum for nydata. Dock har det visat sig att programmet har lart sig systemet val innan vi narupp i hogt antal data. Av denna anledning ar det upp till anvandaren att spara dendata som ar viktig efter korning.


LiU Racetrack 42

10.5 Resultat

I Figur 30 ser vi varvtider med dagens implementation av GPGO. Den forsta toppen be-skriver att GPGO staller ut maximala hastigheter i alla parametrar eftersom det rimligtvisbor ge en bra varvtid. Resultatet blir dock en valdigt dalig varvtid da bilen inte haller sigpa den optimala trajektorian. Hastigheterna sanks da och resultatet blir battre. GPGOfortsatter da att undersoka hastigheter i narheten av den som gick bra. Det syns tydligtatt bilen utnyttjar ”exploit and explore”, aven om varvtiden blir bra sa kommer GPGOfortsatta att utforska andra hastighetsprofiler. Basta varvtid med denna implementationar ungefar 7.5 sekunder.

Figur 30: Resultat over varvtider korda med hastighetsprofiler utraknade med GPGO

10.6 Utvecklingsmojligheter

Det finns stora utvecklingsmojligheter och manga parametrar att trimma for framtidaprojektgrupper. Nedan listas saker som vi tror skulle forbattra prestanda pa GPGO.

Straffa avvikelse fran referenstrajektoriaDetta ar nasta naturliga steg och vi tror att mycket tid finns att tjana har. Genomatt skicka med avvikelsen fran systemet via TCP till GPGO-implementationen kanen funktion ytot � varvtid � konstant � avvikelse bildas och sparas ner som y0.Avvikelsen skulle kunna tankas att vagas in som som den totala arean (integralen)av avvikelsen, den storsta avvikelsen eller avvikelsen i kvadrat pa respektive punkt.


LiU Racetrack 43

lb vec, hb vec, res vecDessa varden kan trimmas beroende pa observationer och ingenjorskunskap.

modify res vec(. . . )Hur upplosningen ska andras beroende pa resultat ar helt en ingenjorslosning ochfunktionen kan goras intelligentare.

ParametriseringAntalet parametrar vi optimerar over och var dessa befinner sig pa den optima-la trajektorian kan andras. Det ar en avvagning mellan berakningshastighet ochnoggranhet.

HyperparametrarVi har inte lagt tid pa att testa olika kovariansfunktioner eller vantevardesfunktioner.Alla variabler som tillhor hyperparametrarna ar varden som valdes tidigt i projektetoch det vore intressant att undersoka hur mycket valet av dessa varden paverkarsystemet.

Styckvis affin approximationVi anvander idag en linjar interpolation for att fa upp antalet parametrar fran 15till 1001. Det kan tankas vara intressant att undersoka hur andra typer av interpola-tion paverkar systemet, exempelvis splinefunktioner. Denna forandring gors enkelti main.m-filen daremot ar det svarare att utvardera hur mycket battre/samre re-sultatet blir. Tanken att anvanda en linjar interpolation bygger pa att vi tror attdet ar fordelaktigt att snabbt variera mellan gas och broms jamfort med att goramjuka overgangar i gaspadrag. Genom att anvanda den linjara interpolationen fassnabbare variationer i hastighetsprofilen.

Antal iterationer av huvudloopen och kombinationsmatrisenVi kor idag huvudloopen (gp() till fmincon) fyra ganger och kombinationsmatrisenar satt pa 500000 kombinationer per varv. Detta kan trimmas och aven detta enavvagning mellan berakningshastighet och noggranhet.

GPGPU-implementationDet som ar tekniskt mest avancerat men som troligen hade gett bast resultat hadevarit att gora en GPGPU (General Purpose Graphics Processing Unit) implemen-tation av gridsokningen i GPGO. Istallet for att kora en karna pa CPU:n skullekombinationsmatrisen kunna forstoras men styckas upp och kora pa olika karnorpa grafikkortet. Utrakningarna beror idag inte pa varandra och ar hogst parallel-liserbar. Noggrannheten i hastighetsprofilen som skickas till systemet skulle troli-gen da bli markant mycket battre. Dock kan det innebara problem att oversattaGPML-biblioteket tillsammans med ovriga matematiska delar till C. Vill man intega hela vagen kan man utveckla den nuvarande Matlab-implementationen genomatt kora parfor-loopar istallet for for-loopar genom lite omstrukturering i koden foratt anvanda datorns alla CPU-karnor.

10.7 Avslutande ord

Vi har fatt GPGO att fungera i praktiken och byggt en grund som ar latt att bygga vidarepa. Det ar av stort intresse att lagga in straff pa avvikelsen fran referenstrajektorian forframtida projektgrupper. Det finns stora utvecklingmojligheter, specificerade ovan, och vitror att GPGO lampar sig valdigt val for en adaptiv hastighetsprofil i projektet Racetrack.


LiU Racetrack 44

10.8 Granssnitt

I Tabell 12 sammanfattas de in- och utdata som GPGO-implementationen anvander sigav.

Insignaler BeskrivningVarvtid Tiden det tar for bilen att kora ett varv

runt bilbanan med senast anvand has-tighetsprofil

Utsignaler BeskrivningNasta hastighetsprofil Parametrarna for den hastighetsprofil

som ska anvandas nasta varv.

Tabell 12: Tabell over gransnittet for GPGO-implementationen


LiU Racetrack 45

11 Delsystem: Reglering

Reglersystemets uppgift ar att fa bilen att sa val som mojligt folja den givna referenstrajek-torian. Det bestar av tva delsystem som styr bilens gaspadrag samt styrvinkel. Systemenbestar i huvudsak av ett antal PID-regulatorer och en framkopplingslank. I detta projekthar inte regleringen utvecklats och beskrivs darfor inte utforligt. For narmare beskrivningav regleringen, se [3].

11.1 Granssnitt

I Tabell 13 ges en oversikt over in- och utsignaler inom reglersystemet for styrservot.

Insignaler Beskrivningθavge , ravge Medelvardesbildad avvikelse i av-

stand fran trajektorian samt me-delvardesbildad girvinkelavvikelse frantrajektorian.

9θ Girvinkelhastighet.Utsignaler Beskrivningus Styrsignal (till styrservot).

Tabell 13: Sammanfattning av in- och utsignaler inom reglersystemet for styrservot.

I Tabell 14 ges en oversikt over in- och utsignaler inom reglersystemet for hastighetsre-gleringen.

Insignaler Beskrivningre Avvikelse i avstand fran trajektorian9θ Girvinkelhastighet.X, Y Position i x- och y-led.Utsignaler Beskrivningus Styrsignal (gaspadrag).

Tabell 14: Sammanfattning av in- och utsignaler inom reglersystemet for hastighetsregle-ringen.

12 Delsystem: Manuell styrning av lastbil

Detta avsnitt beskriver hur systemet har utokats for att mojliggora manuell styrningav lastbilen fran nagon av laborationssalens datorer. Malet med detta var att ge godaforutsattningar for att framover kunna utveckla ett reglersystem som styr lastbilen fran endator. Detta har byggt mycket pa den nya hardvaran i systemet beskriven i Avsnitt 3. DarRaspberry Pi och de digital till analog konverterarna ar ena delen och kommunikationenover det lokala natverket till en dator den andra.


LiU Racetrack 46

12.1 Raspberry Pi och D/A konverterare

En Raspberry Pi tillsammans med digital till analog konverterare har kopts in och pre-standa testats som beskrivet i Avsnitt 3. Raspberry Pi’n kor operativsystemet Raspbian- Debian Wheezy med default anvandaren och losenordet, “pi” respektive “raspberry”.Raspberry Pi’n och digital till analog korten kommunicerar over I2C bussen med 400 kHZbaud rate.

I filen cmdline.txt har Raspberry Pi’n tilldelats en statisk IP-adress. Raspberry Pi’n harsedan satts upp som en TCP-server med ett protokoll for att ta emot styrsignaler fran enTCP-klient enligt Avsnitt 5. Detta program startas i bakgrunden vid start av raspberry’ndefinierat i etc/rc.local.

Pa raspberry’n i “Home/truck manual steering” finns de filer och program som har byggtsfor kommunikation och utstallande av korrekt analog signal. Genom att sta i den mappenoch skriva “sudo python truck manual control.py” kommer den server starta som kors vidupstart.

12.2 Skickande av styrsignaler fran datorn

Pa rt-pc-03 i “C://local Homes/Racetrack Fast 2014/” finns mappen “truck manual con-troll” denna innehaller ett visual studio-projekt som kan kommunicera med raspberrynmed ratt protokoll.

Handkontrollen som styr lastbilen har ett spanningsomrade for styrsignaler mellan 0-3.2 V.Det ar inom detta intervall programmet pa rt-pc-03 staller ut signaler. Detta innebar olikavardes intervall for de olika digital till analog-korten beskrivet i Avsnitt 5.3. Sa som dettaprogram har skrivits finns en trad for styrning hoger/vanster och en trad for gaspadrag.Nar piltangenterna trycks ned sa raknas utsignalen upp eller ned inom sitt givna intervalloch nar piltangenten slapps skickas neutral lage vilket innebar styrning rakt fram ochinget gaspadrag.

13 Delsystem: Visualisering och GUI

Visualiseringssystemet har tva huvuduppgifter. Dels skoter systemet projektionen av in-formation genom projektorn, dels hanterar systemet anvandargransnittet (GUI:t) somsyns pa datorn. Exempel pa information som projektorn visualiserar ar varvtider och tra-jektoria for bilarna.

En oversikt av visualiseringssystemet ges av Figur 31. Det ar en schematisk bild overdelsystemets uppgifter och vad for information systemet kraver samt ger ifran sig.

13.1 Utseende och funktionalitet for GUI

I dagslaget sker all kommunikation mellan anvandare och hela systemet genom ett grafisktanvandargranssnitt pa datorn, ett GUI. Detta GUI bestar av tva olika fonster som synsFigur 32 och Figur 33. Huvudfonstret for GUI:t ses i Figur 32. Detta ar en kontrollpanelvarifran anvandaren kan styra systemet. Den nya funktionaliteten i visualiseringssystemetkommer huvudsakligen att synas i detta fonster med nya inmatningsparametrar och en


LiU Racetrack 47

Figur 31: Oversikt av delsystemet for visualisering och GUI. I bilden syns insignaler,utsignaler och funktionalitet i systemet.

helt ny del som kommer att tillata anvandaren att hantera hinder. Denna kontrollpaneldefinieras och skapas i filen ControlPanel.ccp. I den filen finns fardiga funktioner for attutoka kontrollpanelen med nya knappar, inmatningsfalt och text. Tabell 15 ar en samman-fattning over alla parametrar som ska kunna matas in genom kontrollpanelen (exklusivede befintliga PID-parametrarna).

Forutom kontrollpanelen bestar GUI:t aven av fonstret som syns i Figur 33. Dar ritas enkarta over bilbanan och bilarnas skattade positioner i realtid ut. Anvandaren kan ocksavalja att visa optimal trajektoria, konfidensintervall for bilarnas positioner och bilarnastrajektoria (bade tidigare och aktuellt varv). Detta fonster och dess funktionalitet skapasi MainDisplay.ccp och med sin klassdefinition i MainDisplay. Detta ar en nedarvd klassfran basklassen Display som i sin tur bygger pa det grafiska biblioteket OpenCV. Nyfunktionalitet som ska inforas i detta fonster ar att hinder, bade statiska och dynamiska,ska synas pa skarmen.


LiU Racetrack 48

Utover detta ska de virtuella sensorerna med skalenlig form och rackvidd ritas ut. Fordetta finns det funktioner i det befintliga biblioteket, circle och rectangle ar exempelpa sadana, vilket later oss rita ut geometriska figurer. For att rita ut en bild fran en fil (omvi exempelvis vill lata ett hinder representeras av en alg) erbjuds OpenCV imread ochimshow vilka laddar in en bildfil respektive visar den. Till sist ska aven GUI:t rita ut ny,beraknad trajektoria nar RRT:n forsoker fa bilen att undvika hinder. Da det redan finnsfunktionalitet for att rita ut trajektoria i form av funktionen Display::DrawLapOnline

ar detta inget nytt som behover programmeras fran grunden utan det enda som behovsar att Draw-traden far tillgang till RRT-trajektorian.

13.2 Projektion pa bilbanan

Forutom att rita upp ett GUI pa datorn skoter visualiseringssystemet ocksa projektornsom projicerar ut diverse efterfragad information pa den fysiska bilbanan. Den mate-matiska bakgrunden till hur projektionen fungerar finns beskriven i den tekniska doku-mentationen fran foregaende ar [3]. I enlighet med denna teori finns allt implemente-rat i ProjectorDisplay.ccp med sin klassdefinition ProjectorDisplay.h. Aven den-na klass ar nedarvd fran basklassen Display. Liksom for den tidigare GUI-delen i Fi-gur 33 vill vi aven har rita ut hinder, virtuella sensorer och RRT-trajektoria. EftersomProjectorDisplay delar basklass med MainDisplay implementeras dessa funktioner palikvardiga satt.

Ny inparameter Beskrivningsensor_range Rackvidd for virtuella sensorerna.sensor_type Grafisk form for de virtuella sensorerna

(cirkelskiva, kvadrat och sa vidare).trigger_overtaking Flagga for att trigga omkorning.race_mode Byter mellan race-mode och ”vanlig”

korning.truck_angles Installning for hur vinklarna till lastbi-

len ska skattas.

Tabell 15: Tabell over de nya inparametrarna som kommer att foras vidare fran kontroll-panelen till systemet. Dessutom en beskrivning vilken funktionalitet dessa parametrar styrover.


LiU Racetrack 49

Figur 32: Skarmdump av kontrollpanelen som den ser ut i dagslaget. Har kommer nyainmatningsmojligheter att inforas.

Figur 33: Skarmdump av kartan over bilbanan som ritas upp i realtid pa datorskarmen.Forutom ett mojligt ansiktslyft ska aven eventuella hinder och RRT-trajektoria synas har.


LiU Racetrack 50

14 Delsystem: Simulator

Simulatorns uppgift ar att simulera det fysiska systemet och darmed underlatta for test-ning av uppstallda krav och vidareutveckling av systemet. Till simulatorn hor en fordons-modell och en matuppdatering som ersatter det fysiska systemets malfoljning. Fordons-modellen ersatter den fysiska bilen och simuleringen ersatter malfoljningen i det fysiskasystemet. I 2014 ars projekt har koden som tidigare namnt delats upp i moduler, det-ta innefattar aven simulatorkoden. I ovrigt har simulatorn inte utvecklats vidare ochdarfor beskrivs bara det allra mest grundlaggande kring simulatorn i detta dokument.For utforligare information om simlatorn hanvisas lasaren till tidigare ars tekniska doku-mentationer.

14.1 Granssnitt

I Tabell 16 ges en oversikt over in- och utsignaler inom simuleringssystemet.

Insignaler Beskrivning9vx, 9vy Acceleration i x- och y-led.:θ GirvinkelaccelerationenXref , Yref , θref Referensposition i x- och y-led samt gir-

vinkelreferens.Utsignaler Beskrivningvx, vy Hastighet i x- och y-led.re, θe Avvikelse i avstand fran trajektorian

samt girvinkelavvikelse fran trajektori-an.

X, Y Position i x- och y-led.

θ, 9θ Girvinkel och girvinkelhastighet.

Tabell 16: Sammanfattning av in- och utsignaler i simulatorn.

14.2 Simuleringssystem

Simulatorn har i dagslaget en del brister; den klarar exempelvis inte av att simuleraett helt varv runt banan. Simulatorn har tva lagen, autonom eller manuell simulering ochdessa tva lagen fungerar pa samma satt som for det fysiska systemet, vilket finns beskrivettidigare i detta dokument. En systemoversikt av det nuvarande simuleringssystemet kanses i Figur 34. Ett mer detaljerat flodesschema kan ses i Figur 35.

14.2.1 Fordonsmodeller

I dagslaget finns tva olika fordonsmodeller (implementerade i tidigare ars projekt). Denena modellen ar fran 2011 [1] och den andra fran 2012 [2]. En skillnad mellan de tvamodellerna ar att den senare tar hansyn till fler fysikaliska egenskaper, som exempelvis slip.En annan stor skillnad ar att i modellen fran 2011 beraknas hastigheterna i longitudinell-och lateralled, vx och vy samt vinkelhastigheten 9θ direkt. I modellen fran 2012 beraknas

istallet accelerationerna 9vx, 9vy samt vinkelaccelerationen :θ och for att berakna vx,vy och9θ behover en integration utforas.


LiU Racetrack 51

Figur 34: Illustration av hur simuleringsfunktionen fungerar idag. Tillstanden uppdate-ras efter hur regulatorn avgor hur den simulerade bilen lampligast foljer den optimalatrajektorian.

14.2.2 Simulator

Simulatorn kan ses som en fiktiv matuppdatering som beraknar vx, vy, X, Y , θ och 9θ fran

en fordonsmodell. θ och 9θ beraknas genom integration och dubbelintegration av :θ och vx,vy, X och Y beraknas enligt (13) - (16). Utan denna sa kallade fiktiva matuppdateringskulle varken bilens position eller hastighet vara kand.

Xptq � Xpt� T q � Tvxpt� T q �T 2

29vxpt� T q (13)

Y ptq � Y pt� T q � Tvypt� T q �T 2

29vypt� T q (14)

vxptq � vxpt� T q � T 9vxpt� T q (15)

vyptq � vypt� T q � T 9vypt� T q (16)

Notera att da fordonsmodellen fran 2012 anvands behover en integration av 9vx och 9vygoras innan (13) - (16) kan anvandas.


LiU Racetrack 52

Figur 35: Flodesschema over simulatortraden fran start till avslut. Vart att notera ar attdet hela tiden kontrolleras att bilen haller sig pa banan. Vidare ar simulatorn uppdelad itva stora loopar, den ena kors da bilen ar i autonomt lage, den andra da bilen ar i manuelltlage.


LiU Racetrack 53

Referenser

[1] LiU Racetrack 2011. Teknisk dokumentation. 2011.



[4] R. Craig Coulter. Implementation of the pure pursuit path tracking algorithm. 1992.

[5] Sertac Karaman and Emilio Frazzoli. Incremental sampling-based algorithms foroptimal motion planning. 2010.

[6] Yoshiaki Kuwata, Sertac Karaman, Justin Teo, Emilio Frazzoli, Jonathan P. How,and Gaston Fiore. Real-time motion planning with applications to autonomous urbandriving. Control Systems Technology, IEEE Transactions on, pages 1105–1118, 2009.

[7] Kyosho. Radiostyrda bilar, kyosho dnano. http://www.kyosho.se/webshop/

products/product.aspx?ArtNr=01.DNC502 [Online; accessed 02-Oct-2014].

[8] Michael A. Osborne, Roman Garnett, and Stephen J. Roberts. Gaussian processesfor global optimization. In 3rd international conference on learning and intelligentoptimization (LION3), pages 1–15, 2009.

[9] Romain Pepy, Alain Lambert, and Hugues Mounier. Path Planning using a DynamicVehicle Model, volume 1. 2006.

[10] Carl Edward Rasmussen and Hannes Nickisch. Documentation for GPML MatlabCode version 3.4. 2014.

[11] Carl Edward Rasmussen and Christopher K. I. Williams. Gaussian Processes forMachine Learning. The MIT Press, 2006.


http://www.kyosho.se/webshop/products/product.aspx?ArtNr=01.DNC502

http://www.kyosho.se/webshop/products/product.aspx?ArtNr=01.DNC502

Teknisk dokumentation - isy.liu.se · Styrkort NI PCI-6024E Kopplingsplatta, BNC-2110, med tillh...

Documents

Transcript of Teknisk dokumentation - isy.liu.se · Styrkort NI PCI-6024E Kopplingsplatta, BNC-2110, med tillh...