Framework for Sensor Fusion

Transkript

1 Framework for Sensor Fusion Marcus Öman KTH, School of Computer Science and Communication (CSC) Abstract Using sensors in vehicles to be able to make the driving experience safer and automate the driving process is something that truck manufacturers has been interested in for years. In this thesis we explore the possibilities to make a framework for sensor fusion where developers develop plugins that gain access to data from multiple sensors. The result of this thesis is a suggestion for how to realize such a framework. We also discuss how to improve the quality of the framework and how to make it more stable.

2 Ramverk för sensorfusion MARCUS ÖMAN Examensarbete Stockholm, Sverige 2012

3 Ramverk för sensorfusion MARCUS ÖMAN 2D1021, Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik 270 högskolepoäng Kungliga Tekniska Högskolan år 2012 Handledare på CSC var Douglas Wikström Examinator var Johan Håstad TRITA-CSC-E 2012:056 ISRN-KTH/CSC/E--12/056--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

4 Framework for sensor fusion Abstract Using sensors in vehicles to be able to make the driving experience safer and automate the driving process is something that truck manufacturers has been interested in for years. In this thesis we explore the possibilities to make a framework for sensor fusion where developers develop plugins that gain access to data from multiple sensors. The result of this thesis is a suggestion for how to realize such a framework. We also discuss how to improve the quality of the framework and how to make it more stable. Sammanfattning Att använda sensorer i fordon för att göra körupplevelsen säkrare och automatisera körningsprocessen är något som lastbilstillverkare har varit intresserade av i flera år. I denna rapport utforskar vi möjligheterna att skapa ett ramverk för sensorfusion där utvecklarna skapar insticksmoduler som får tillgång till sensordata från flera sensorer. Resultatet av examensarbetet är ett förslag på hur man skulle kunna göra ett sådant ramverk. Vi föreslår också hur ramverket kan vidareutvecklas och göras mer stabilt.

5 Innehållsförteckning 1. Inledning Bakgrund Datafusion Användarfunktioner Dagens system Sensorer Problembeskrivning Målsättning Fokus och avgränsningar Teori RTMaps Boss Metod Sensorer Exempel på sensorer Pluginarkitektur Varför pluginarkitektur? Val av pluginarkitektur Implementering Dataformat Internt dataformat Implementering Användning Datalagring DCDB Andra lösningar Systemet i helhet Resultat och slutsatser Hur sköta kommunikation mellan sensor och kärna Skapa egen insticksmodul Tester på ramverket Tester med insättning i datalagringen Tester med uttagning från datalagringen Rekommendationer Referenser... 29

6 Förkortningar: API DCDB DLL DR LDW SO SQL TCP UDP Ordlista Aktuator Boost Condition Variable Data Container Data Restriction Serialisera (eng. Serialize) Application Programming Interface Data Container Data Base Dynamic Linked Library Data Restriction Lane Departure Warning Shared Object Structured Query Language Transmission Control Protocol User Datagram Protocol En mekanisk del som används för att förflytta eller kontrollera en mekanism eller ett system. Boost är ett C++-bibliotek med funktioner som implementerats för att fungera väl med den existerande C++-standarden. Mer information tillgänglig från En metod i boost som tillåter en att låta trådar vänta tills ett visst villkor uppfylls. En klass implementerad i C++ för att representera ett meddelande från en sensor. En variabel som används i ramverket för att variera hur mycket data som lagras för en viss sensor. En process att omvandla en datastruktur eller objekt till ett format som kan lagras för att senare kunna återanvändas för att återskapa datastrukturen eller objektet.

7

8 1. Inledning I detta avsnitt går vi igenom bakgrunden till denna rapport och informerar om vilka problem vi fokuserar på och vad vi inte kommer att fokusera på Bakgrund För att implementera morgondagens avancerade aktiva säkerhetssystem i fordon krävs det sensorer som läser av den aktuella trafiksituationen. Sensorerna kan vara av typen kamera, radar, lidar eller liknande. Vidare behövs det avancerad signalbehandling och datafusion för att förfina och kombinera informationen från de olika sensorerna. Slutligen ska mer eller mindre autonoma användarfunktioner implementeras i fordonet som fattar beslut baserade på den behandlade och fusionerade sensorinformationen. Eftersom detta är ett område som utvecklas snabbt är det svårt att säga vilka olika typer av sensorer och säkerhetsfunktioner som kommer i framtiden. Därför behövs ett flexibelt ramverk i botten för all funktionsutveckling som abstraherar sensortyperna och informationshantering samt ger möjlighet att på ett enkelt sätt utöka funktionaliteten hos de aktiva säkerhetsfunktionerna. De som föreslagit uppgiften är Scania och det är vid Scania Tekniskt Centrum i Södertälje arbetet utfördes. Scania tillverkar tunga lastbilar, bussar och industrioch marinmotorer [1] Datafusion De mest utvecklade säkerhetssystemen som används idag, och förmodligen i framtiden, använder sig av flera sensorer. Datafusion är en teknik som används för att kombinera data från flera sensorer för att kunna skapa feltoleranta system. Man kan tänka sig att de extra sensorerna är till för att dubbelkolla att informationen är korrekt eller att de har överrensstämmande data. Vad som egentligen händer är att man kombinerar data från ett antal sensorer på ett sådant sätt att man uppdaterar bilden på omgivningen som sensorerna samlar information om. Det är denna betydelse av termen datafusion som kommer användas i denna rapport, den är tagen från [2] Användarfunktioner De data som sensorerna samlar in och speciellt det data som är resultatet av datafusion kan användas som beslut för att utföra någonting, exempelvis köra om 1

9 bilen framför. För att köra om bilen framför krävs det också vissa handlingar, exempelvis vridning av ratten och ökning av hastighet. Beslutet och bestämning av vad som ska åtgärdas för att utföra en handling är något som samlas under begreppet användarfunktion Dagens system Idag finns det inget kommersiellt system för datafusion av data från flera sensorer där resulterande data går att använda i användarfunktioner. Det man har gjort istället är att helt enkelt inte använda sig av datafusion. Det som skulle krävas om man skulle vilja använda sig av datafusion i dagens system är att skicka data från sensorerna till de fusionsfunktioner som använder den och sedan skicka vidare det data som är behandlad till användarfunktionerna som använder den. Det låter kanske inte så farligt men de negativa sidorna visar sig när man till exempel vill lägga till en fusionsfunktion, vilket visar sig kräva en del onödigt arbete. Funktionen behöver data från några sensorer, då måste man lägga till kod där man tar hand om sensordata för att ordna det. Fusionsfunktionen kräver alltså ändringar i andra delar av programmet. För varje ny fusionsfunktion behöver man göra samma sak igen. Samma sak gäller det när man inte längre vill använda en fusionsfunktion och då vill ta bort den. Då tar man bort kod som skickade data till fusionsfunktionen som troligtvis ligger där man tar hand om sensordata. Likadant för varje fusionsfunktion som man vill ta bort. Problemen med fordonsindustrins nuvarande system om man vill använda datafusion med flera sensorer är bland annat: Dålig skalbarhet. Kodduplicering. Skapare av fusionsfunktioner och användarfunktioner behöver förstå hela systemet Sensorer De sensorer som kan tänkas användas idag är bland annat: Avståndssensorer: Dopplerradar LDW-kamera, LDW står för Lane Departure Warning (sv. filbytesvarning). Laserscanner 2

10 Fordonsparametrar: Hastighet Acceleration Rattens vridningsvinkel Varvtal på motor Växel 1.2. Problembeskrivning Som det beskrivs i avsnitt visade det sig att dagens system gör det ganska svårt att lägga till nya fusionsfunktioner samt användarfunktioner. Skulle en pluginarkitektur kunna förenkla arbetet och skulle den kunna bevara de funktioner som redan finns och behövs? Hur skulle en sådan pluginarkitektur se ut? Kan det bli snabbt nog för att uppfylla kraven som finns på avancerade hjälpmedel för föraren? Vilka data behöver utbytas mellan de olika komponenterna? Hur ska man behandla data från sensorer? 1.3. Målsättning Målet med denna rapport är att skapa ett ramverk med en pluginarkitektur som gör att fusionsmoduler och användarfunktionsmoduler får tillgång till data från en mängd olika sensorer. Detta illustreras i figur

11 Figur 1.1 En översikt över komponenterna i systemet En aktuator är en mekanisk del som används för att förflytta eller kontrollera en mekanism eller ett system. Data och Kärna i figuren ovan är något som ska utredas hur de ska fungera. Datautbytet mellan fusionsmodulerna och kärnan samt användarfunktionsmodulerna och kärnan är något som ska definieras. Allt detta ska implementeras som en prototyp och testas för att kunna utvärdera hur väl det fungerar. Det ska även dokumenteras så att andra programmerare ska kunna utveckla fusionsmoduler och användarfunktionsmoduler samt lägga till nya sensorer och aktuatorer. Hela systemet ska fungera i operativsystemen Windows XP och Ubuntu vilket innebär att kodbasen ska vara portabel Fokus och avgränsningar Fokuset i denna rapport ligger på att definiera hur dataflödet ser ut i systemet. Vilka data som utbyts, hur ofta och så vidare. Algoritmer och kodbibliotek som används för att implementera ramverket kommer att presenteras. Denna rapport fokuserar inte på hur fusionsmoduler och användarfunktionsmoduler utför sin funktion. Däremot är det viktigt att dessa kan utföra sin funktion så att ingen funktionalitet går förlorade som finns i dagens system. 4

12 Gränssnittet till sensor och gränssnittet till aktuator är något som har implementerats i RTMaps, vilket kan beskrivas som ett ramverk för sensordata, som beskrivs i korthet i avsnitt 2.1. Hela systemet är implementerat i C++ och Boost [3] har använts för att hjälpa till med plattformsberoende funktioner så att systemet har blivit så plattformsoberoende som möjligt utan allt för mycket extra arbete. Boost är ett C++-bibliotek med funktioner som implementerats för att fungera väl med den existerande C++-standarden. 5

13 2. Teori I detta avsnitt presenteras vad andra har gjort inom området RTMaps RTMaps är ett ramverk, utvecklat av Intempora [4], som hjälper till med behandling av sensordata i realtid. Sensordata kan sparas för att senare kunna återspela datasekvensen som sensorerna skickar för att hjälpa utvecklare att kunna testa sina system på samma indata. RTMaps hjälper även till med att skicka behandlad data till aktuatorer. Komponenter som behandlar sensordata utvecklas i C++ och dataflödet mellan komponenter görs med hjälp av ett grafiskt gränssnitt Boss Boss är Carnegie Mellons Tartan Racings bidrag till DARPA Urban Challenge, där elva förarlösa bilar tävlade i att klara en bestämd bana på snabbast tid. Tartan Racing har publicerat en artikel [5] om mjukvaruinfrastrukturen där de diskuterar deras lösning samt relaterat arbete. De tar upp en del ämnen som är intressanta för denna rapport som till exempel kommunikation mellan processer och hur de implementerat deras task framework, där en task i princip är en insticksmodul till systemet där arbete utförs. Deras system, Tartan Racing Urban Challenge System, är uppbyggt av ett dussin sådana insticksmoduler. 6

14 3. Metod I detta kapitel går vi igenom vad som gjorts i examensarbetet och tar upp för- och nackdelar med de metoder som har använts. Det tas även upp bakgrundsfakta som motiverar valen av metoder. För att kunna ta till sig informationen i detta avsnitt bör man ha förståelse för programmering med C++, datastrukturer, databaskoncept (inget SQL) och tidskomplexiteten för de vanliga datastrukturerna och tillhörande metoder. Se [6], [7] och [8] Sensorer För att förenkla för läsaren att förstå alla detaljer i problemet som detta examensarbete har tänkt lösa behöver man en del grundläggande information om de delar som vi tänker använda oss av. Vi går därför igenom vad en sensor är för något och tar upp några exempel. En sensor är en enhet som mäter något i omgivningen och skickar en signal som beskriver mätningen. För de sensorer som används idag är signalen noga definierad och det data man får är vanligtvis behandlad så att användaren av sensorn inte behöver behandla rådata. Vi går igenom några sensorer i de kommande avsnitten för att få en förståelse för vad sensorer ger för information Exempel på sensorer I det här avsnittet går vi igenom tre olika sensorer som utför liknande funktioner. Vi kommer se att de data de skickar innehåller lite olika information. Vi kommer inte gå igenom dataformatet de olika sensorerna använder men noterar att det måste skilja sig mellan varandra eftersom de skickar olika mängder data och innehåller information om olika delar av den omgivning som de övervakar. Dopplerradar En dopplerradar som används i lastbilar detekterar och följer ett antal fordon i dess synfält. Dessa objekt får attribut som till exempel hastighet och acceleration relativt egen, det vill säga lastbilens, hastighet och acceleration. Detta illustreras i figur

15 Figur 3.1 Visualisering av sensordata från en dopplerradar Annan information som ges är klassificeringar av objekten. En sådan klassificering skulle kunna vara personbil eller lastbil. LDW-kamera LDW står för Lane Departure Warning och betyder ungefär filbytesvarning. Den informationen som är ny med LDW-kameran är att den håller reda på filbredden, vägens riktning, tid till filbyte och annan information som har med vägens egenskaper att göra i och med att den kan urskilja de vita strecken från vägen. Detta illustreras i figur 3.2. Vidare håller en LDW-kamera reda på samma information som en dopplerradar men med annan precision. Den är till exempel bättre på att klassificera objekten men sämre på att få rätt relativ hastighet och acceleration. 8

16 Figur 3.2 Visualisering av sensordata från en LDW-kamera Laserscanner En laserscanner håller reda på samma områden som sensorerna innan, förutom det håller den reda på tomrum. Den gör det genom att se om något objekt reflekterar ljus som laserscannern skickar ut. Om det inte reflekteras något ljus det är det ett tomrum, annars finns det ett objekt i den riktningen. Detta illustreras i figur 3.3. Eftersom användningsområdet är att hålla reda på tomrum kallas laserscannern ofta för Free Space Scanner. 9

17 Figur 3.3 Visualisering av sensordata från en laserscanner 3.2. Pluginarkitektur I detta avsnitt förklaras varför man skulle vilja använda sig av en pluginarkitektur, olika sätt att konstruera en pluginarkitektur samt den metod som användes i examensarbetet och motivering till varför den metoden valdes Varför pluginarkitektur? Att ha en pluginarkitektur innebär att man ska kunna utöka programmets funktionalitet med hjälp av insticksmoduler som kan skapas och läggas till i efterhand utan att behöva kompilera om huvudprogrammet. I detta fall är det tänkt att fusionsmodulerna och användarfunktionsmodulerna skulle vara insticksmoduler. En av fördelarna med en pluginarkitektur är att projektet delas upp i naturliga delar som olika programmerare kan arbeta med, vilket innebär att man kan arbeta parallellt utan problem. En annan är att man har väldefinierade gränssnitt när man utvecklar insticksmoduler, eftersom dessa måste vara bestämda och bör vara så pass dokumenterade att en utomstående kan utveckla insticksmoduler till systemet. Nackdelar med att använda sig av en pluginarkitektur finns naturligtvis också. Ett exempel på sådant är till exempel när man ändrar i gränssnittet för att kunna 10

18 uppfylla nya krav som ställs på pluginarkitekturen. Det som händer då är att gamla insticksmoduler antagligen inte fungerar med det nya gränssnittet och man måste lägga ner arbete på bakåtkompatibilitet eller be skaparna av insticksmodulerna att kompilera om Val av pluginarkitektur När man bestämmer sig för en pluginarkitektur är det bra att tänka på hur värdprogrammet och insticksmodulerna ska kommunicera med varandra. Man måste också skilja på hur värdprogrammet kommunicerar med insticksmodulerna och hur insticksmodulerna kommunicerar med värdprogrammet. I ett examensarbete av Magnus Johansson [9] nämns ett antal olika metoder för kommunikation mellan värdprogram och insticksmodul. I detta examensarbete används den enklare metoden, enligt examensarbetet, vilket innebär att man har ett bestämt antal metoder som är kända av den motstående parten för att sköta kommunikationen. Det betyder att värdprogrammet har ett visst antal funktioner som insticksmodulerna känner till och insticksmodulerna har ett visst antal funktioner, där antalet kan variera beroende på insticksmodulens roll, som värdprogrammet känner till. Fokuset i examensarbetet har legat på att göra det så enkelt som möjligt att skapa insticksmoduler som ska användas av värdprogrammet. Detta har inneburit att metoder som skulle innebära att skaparen av insticksmoduler behöver göra trådsäkra metoder, lagra sensordata och så vidare har undvikits. Mer konkret har det inneburit att en insticksmodul efterfrågar data från sensorer som värdprogrammet har kunskap om. Värdprogrammet tillhandahåller denna information och insticksmodulen fortsätter i sitt arbete. Om insticksmodulen skulle behöva spara egen data, så att andra insticksmoduler kommer åt den, eller skicka data till aktuatorerna så tillhandahåller värdprogrammet även dessa funktioner. Insticksmodulerna som är laddade körs i var sin tråd som värdprogrammet tar hand om och alla funktioner som insticksmodulerna kommer åt i värdprogrammet är trådsäkra. Värdprogrammets kända funktioner När det kommer till funktioner som värdprogrammet erbjuder handlar det till större del om tillgång till datalagringen för sensordata och sensorfusionsdata. Det är viktigt med hur man kommer åt data, vilken information är viktig när man efterfrågar data. Efter en intervju med Pär Degerman, min handledare på Scania, framkom det att det i huvudsak finns tre olika sätt att fråga efter sensordata. 11

19 Man vill ha de x senaste meddelandena från sensor s. Man vill ha alla meddelanden från sensor s i ett tidsintervall [a,b]. Man vill ha de x senaste meddelandena efter tidpunkt a från sensor s och är villig att vänta y tidsenheter. Utöver detta har värdprogrammet funktioner för skickning av instruktioner till aktuatorer i lastbilen, utskrift av text och aktuell tid. Insticksmodulens kända funktioner Insticksmodulens funktioner som är kända av värdprogrammet handlar om hantering av den specifika insticksmodulen. De funktionerna är: Initiering av insticksmodul Start av insticksmodul Avstängning av insticksmodul Dessa funktioner implementeras alltså av insticksmodulen och är unika för den specifika insticksmodulen. De har förutbestämda namn så att de känns igen av värdprogrammet men utöver dessa funktioner finns det inga krav på insticksmodulen Implementering Likt allt annat i detta projekt implementerades både värdprogrammet och insticksmoduler i C++. Men vi börjar med att gå igenom översiktligt hur insticksmodulen fungerar och sedan lite mer detaljerat om hur vissa problem som löstes under arbetet. Sedan beskrivs värdprogrammet på samma sätt. Ett exempel som har inspirerat, men inte följts helt och hållet eftersom det är för omständigt för detta projekt, är [10]. Insticksmodulen Tidigt i projektet bestämdes det att insticksmodulerna skulle vara implementerade som delade kodbibliotek. Det vill säga att i Windows förväntas de vara C++ i.dllfiler och i Ubuntu förväntas de vara C++ i.so-filer. Detta val gjordes för att det verkade vara den enklaste vägen att gå samt att kunskapen för C++ redan finns på Scania. Det innebär att det inte blir något nytt att lära sig för att kunna implementera egna insticksmoduler, vilket borde ses som något positivt i sammanhanget eftersom fokuset ligger på att det ska vara enkelt att skapa eget innehåll i ramverket. 12

20 Insticksmodulens livscykel går som följer: Insticksmodulen upptäcks av värdprogrammet. Insticksmodulen initieras av värdprogrammet och får då reda på värdprogrammets funktioner. Insticksmodulens run-metod anropas och insticksmodulen förväntas köra hela tiden tills den blir tillsagd att sluta genom att dess stop-metod anropas vilket görs när värdprogrammet vill sluta köra. Insticksmodulens destroy-funktion anropas och där förväntas den släppa alla resurser insticksmodulen har allokerat under dess körning. För att realisera detta har initieringsfunktionen och destroy-funktionen implementerats som externa funktioner så att de är anropbara om man har tillgång till.dll- eller.so-filen. Initieringsfunktionen tar ett funktionsobjekt som följer ett visst gränssnitt som argument och returnerar en pekare till en instans av insticksmodulen. Funktionsobjektet är ett sätt att föra vidare funktionsanrop till där de behandlas vidare. Exempelvis beskriver funktionsobjektet vilka tillgångssätt insticksmodulen har till datalagringen. Insticksmodulen känner till gränssnittet för funktionsobjektet men inte implementeringen vilket innebär att insticksmodulen inte bryr sig om hur värdprogrammet är implementerat så länge som värdprogrammet uppfyller kraven på funktionsobjektet. Detta funktionsobjekt kommer i efterföljande stycken att kallas för SystemFunctions. Destroy-funktionen anropas med en pekare till instansen av insticksmodulen som argument. Värdprogrammet Värdprogrammets uppgift är att hitta nya insticksmoduler samt erbjuda de kända funktionerna som nämndes innan i avsnitt 3.2.2, det vill säga tillgång till någon slags datalagring samt möjlighet att skicka instruktioner till aktuatorer i lastbilen. För att hitta nya insticksmoduler används FileSystem i boost. Vad den används till är att få reda på vilka filer som finns i en katalog för insticksmoduler. Vid varje kontroll undersöks vilka insticksmoduler som har tillkommit som måste startas upp av värdprogrammet. Vid laddningen av insticksmodulerna presenteras de kända funktionerna. Vad som skulle kunna varit en bättre lösning är att låta varje insticksmodul vara en egen process som kommunicerar med värdprogrammet via TCP eller liknande. Protokollet mellan dessa skulle då kunna vara något liknande funktionsobjektet, men man får i meddelandet specifikt ange vilken funktion man vill använda och sedan skicka med parametrarna. Det positiva med denna lösning är att om en av insticksmodulerna kraschar innebär det inte att körningen av andra insticksmoduler och värdprogrammet stoppas vilket är fallet när insticksmoduler körs i trådar. Med denna lösning skulle man även kunna starta om insticksmoduler som har kraschat genom att starta om processen som 13

21 insticksmodulen körs i. Det negativa med denna lösning dock är att kommunikationen via TCP ökar vilket möjligtvis gör att det inte är lämpligt att använda denna metod. Denna lösning har inte testats på grund av tidsbrist. Hur datalagringen fungerar och är implementerad beskrivs i detalj i avsnitt Som det nämndes i avsnittet om insticksmodulens implementation förväntade den sig ett funktionsobjekt som vi kallar SystemFunctions. Vad SystemFunctions gör är helt enkelt att skicka vidare anrop om datalagringen till datalagringen och instruktioner till lastbilens aktuatorer till RTMaps via TCP. Där sker en konvertering från det interna dataformatet, som beskrivs i detalj i avsnitt 3.3.1, till RTMaps dataformat Dataformat När man jobbar med sensorer kan det vara svårt att arbeta direkt med det format som sensorerna använder. Formatet är ofta hårt specificerat och information skiljs endast med position. Det kan vara enklare att förstå vad som menas om vi tittar närmare på ett fiktivt exempelmeddelande från en laserscanner. Exempelmeddelande: 2 0, , Figur 3.4 Visualiserar ett fiktivt sensormeddelande från en sensor som ser två objekt. Vad detta meddelande säger är att det finns två objekt som den har upptäckt i den senaste överblicken av området laserscannern övervakar. Sedan går det vidare med att beskriva positionerna av objekten och en uppskattning om vad det kan 14

22 vara för objekt. Positionerna beskrivs med en vinkel och avstånd från sensorn. Detta dataformat kan vara jobbigt att arbeta med om man snabbt vill göra någonting med informationen för att testa om det fungerar Internt dataformat Som det nämndes i avsnittet innan finns det problem med att jobba med sensorernas egna format. Det skulle därför vara bra om det fanns något system som beskriver sensordata på ett enklare sätt så att utvecklarna av insticksmoduler inte behöver utföra extra arbete. Det skulle även vara bra om det gick att skriva om meddelanden från två olika sensorer som beskriver i princip samma data till det enklare dataformatet. Detta skulle innebära att man inte behöver ändra på kod som använder sig av sensordata om man byter sensor eller liknande eftersom man använder sig av det nya enklare och interna dataformat som beskriver exakt samma data och har samma struktur oavsett sensor. Här efter följer ett övergripande exempel för att förklara formatet: Sensor Tidsstämpel Attributnamn Värde... Attributnamn Värde Detta beskriver ett sensormeddelande. Man börjar med sensorns namn, sedan kommer en tidsstämpel som beskriver när mätningen var gjord. Sedan radar man upp alla attributnamn med tillhörande värde. Ett sådant meddelande är enklare att hantera som programmerare eftersom man kan använda sig av attributnamnet istället för position i meddelandet för att ta reda på det värde man är intresserad av. Detta innebär också att attributnamnen bör vara unika för meddelandet. Två olika meddelanden från samma sensor behöver inte innehålla samma attributnamn. Om man byter mellan två sensorer som beskriver samma data men använder olika enheter kan det uppstå problem. Med olika enheter menas exempelvis att beskriva en vinkel med radianer eller grader. För att förstå problemet som uppstår med detta så kan man tänka sig att någon försöker läsa av ett värde med attributnamn Vinkel och förväntar sig en vinkel i grader men får istället en vinkel i radianer. Man fortsätter då och använder detta värde felaktigt och kommer därmed antagligen sluta med att något oväntat händer. Detta är inget som det interna dataformatet tar hand om utan det kommer kräva lite arbete från den som använder formatet. Det man skulle kunna göra är att beskriva enheten i namnet och sedan när det används fråga efter de olika sorterna och göra egen konvertering. 15

23 Implementering För att realisera en enkel användning av det interna dataformatet har en C++klass, som vi kallar DataContainer, implementerats. Attributnamn och värdeparen har implementerats med hjälp av boost::unordered_map där attributnamnen har typen std::string och värdet har typen boost::variant. Valet av typen på värdena har i princip stått mellan boost::any och boost::variant. boost::variant valdes över boost::any på grund av att boost::variant har mer support vad gäller automatiserad användning av värdet eller typen av värdet. För sensorns namn användes std::string och för tidsstämpel boost::int64_t. När man lägger till ett attributnamn och värdepar håller DataContainer reda på ordningen som dessa lades in i. Detta gör den för att fortfarande tillåta den äldre metoden att använda sensordata som utnyttjade just position i meddelandet för att skilja på värdena. Detta innebär att vi har två metoder när vi efterfrågar ett specifikt värde, man måste antingen ange position eller attributnamnet. Ett implementationsval krävdes vilket påverkar position i meddelandet om man lägger in två olika värden med samma attributnamn. Det finns åtminstone två olika vägar att gå. Antingen tillåter man dubbletter och då bör man inte använda boost::unordered_map i implementationen, eller så uppdaterar man det äldre värdet med det nya värdet. Eftersom boost::unordered_map används framgår det att DataContainer följer det andra sättet vilket innebar att den uppdaterar de äldre värdena med de nya Användning Som tidigare nämnts är det interna dataformatet implementerat som en C++-klass som vi kallar DataContainer. När man instansierar en DataContainer bör man skicka med sensornamn och tidsstämpel. Om det inte görs kommer dessa initieras till "Not specified" och -1 respektive. Dessa går dock att ändra med metoderna med namnen setsensor och settimestamp. Sedan vill man troligtvis fylla denna DataContainer med data. Detta gör man med metoden setdata<datatyp>(namn,data), där datatyp, namn och data måste specificeras. Datatyp bör vara namnet på datatypen som data har. Namn är en sträng som kommer motsvara attributnamnet på det data som det associeras med. Om man lägger in mer än ett data-värdepar måste man se till att namnen som används är unika. Om man lägger in något med samma namn kommer det att skriva över det man tidigare hade lagt in och data går därmed förlorat. Om man tar emot en DataContainer och vill använda innehållet borde man veta vad den innehåller. Att veta vad den innehåller innebär antingen att man vet attributnamnen man vill använda samt deras datatyper eller ordningen på data 16

24 och tillhörande datatyp. Det man gör då är att man använder metoden getdata<datatyp>(namn) eller getdata<datatyp>(index) där datatyp, namn och index måste specificeras. Datatyp är den datatyp man förväntar sig med givet namn eller index. Index motsvarar den position som data i fråga har i ordningen. Skulle det hända att man vill göra en generell mottagning av en DataContainer går det att göra. Detta är ett av skälen att vi använder boost::variant över boost::any. Med boost::variant går det att använda sig av vad som kallas en visitor. Med en visitor kan man enkelt låta koden utföra olika kodinstruktioner beroende på datatypen vilket är det som behövs för att kunna använda data i en DataContainer på ett generellt sätt Datalagring Vi har gått igenom sensorer och sensordata samt pluginarkitekturen där insticksmoduler vill komma åt sensordata. För att uppfylla kraven som metoderna i värdprogrammet ställer kräver det att vi har någon sorts datalagring där vi lagrar information som sensorerna har skickat. Vi börjar med att gå igenom det val som gjorts och sedan diskutera för- och nackdelar med detta samt jämföra denna lösning med andra alternativa lösningar DCDB Som det nämndes i avsnitt identifierades endast ett fåtal funktioner som behövdes för att kunna erbjuda fullgott stöd för åtkomst av sensordata. Eftersom det inte var något egentligt hinder att implementera en egen databas för detta ändamål så valde vi att gå den vägen istället för att använda något färdigt. För att uppnå maximal hastighet valdes det att datalagringen skulle ske helt i minnet. Om man analyserar hur frågorna är uppbyggda märker man direkt att det är fördelaktigt att skilja data från olika sensorer på något sätt. Här valdes det att skilja lagringen av dessa med en unordered_map från Boost, vilket fungerar som en hashtabell. För att lagra meddelanden från en specifik sensor används en länkad lista. De punkterna som datastrukturen som tar hand om meddelandena ska klara av är följande: Ett sensormeddelande har ingen bestämd storlek. Databasen ligger i minnet, det är viktigt att kunna ta bort oviktiga (äldre) meddelanden snabbt. Att lägga till nya meddelanden ska gå snabbt. Att komma åt de senaste sensordata ska gå snabbt. Att komma åt det sensordata som kom mellan två olika tidpunkter ska gå snabbt. 17

25 Den länkade listan är inte optimal när det kommer till alla punkter men den klarar de flesta utan problem. Den tredje punkten kan den länkade listan ha problem med om, av någon anledning, ett nytt ankommet meddelande har en äldre tidsstämpel än andra meddelanden som redan kommit in i datalagringen. Detta bör dock inte höra till vanligheterna. Den länkade listan har dock större problem med den femte punkten, där man ska komma åt sensordata mellan två olika tidpunkter. Om tidpunkterna är för långt bak i tiden är det troligt att datalagringen har uppdaterats med ny sensordata vilket gör att den länkade listan behöver leta en längre tid för att hitta den sensordata som efterfrågades. Det är möjligt att man skulle kunna förbättra datastrukturen genom att ersätta den länkade listan med en skipplista istället. Figur 3.5 visualiserar datastrukturen som precis beskrivits. Sensor 1 Sensor 2... Sensor N Meddelande 1 Meddelande 1 Meddelande 1 Meddelande 2 Meddelande 2 Meddelande Meddelande M Meddelande O Meddelande P Figur 3.5 Visar hur DCDB, DataContainer Data Base, är konstruerad med fokus på minnet. Sensorlistan är en unordered_map och meddelandelistorna är dubbellänkade listor. Varje meddelande är på det interna dataformatet som nämnts i avsnitt De funktioner som DCDB erbjuder är motsvarande de funktioner som identifierades i Vad man måste tänka på är att det är det är flera olika insticksmoduler som kommer anropa dessa funktioner samtidigt, i någon mening, via flera olika trådar. Detta innebär att man måste se till att trådsäkra funktionerna som är anropbara från insticksmodulerna. Detta löstes med hjälp av Boosts synkroniseringssystem (Synchronization). Det som gjordes var att endast låta en tråd åt gången komma åt en specifik länkad lista. Två trådar kan komma åt två olika sensorers data utan problem men vill de använda samma sensors data får 18

26 den andra tråden vänta tills den första är klar. När funktionerna returnerar instanser av meddelanden från sensorerna så returneras en kopia istället för pekare eller referens eftersom det annars kunde uppstå problem med delade resurser. Optimalt skulle flera trådar kunna läsa, dvs. inte ändra något, från en lista samtidigt utan att något blir fel. Denna implementation tar dock inte hänsyn till detta, vilket innebär att endast en tråd åt gången har tillgång till den länkade listan oavsett om de läser eller skriver till listan. Det skulle kunna förbättras i en framtida version. För att lösa problemet med att tillåta trådar att vänta på inkommande data användes Condition Variables från Boost. Dessa möjliggör att låta en tråd vänta och göra så lite arbete som möjligt tills den blir tillsagd att sluta vänta. Condition variables används om det visar sig att det inte finns tillräckligt med data som det frågas efter. Varje sensor i DCDB har sin egen condition variable som meddelar trådar att sluta vänta för varje nytt meddelande från sensorn Andra lösningar Man skulle kunna använda färdigimplementerade databaser så som MySQL, MSSQL eller PostgreSQL. Det var något som var planerat i början av arbetet men ändrades när vi fann att man undvek serialisering av sensormeddelandena om man valde sättet som beskrevs i avsnitt Spår som finns kvar av denna ändring är främst valet att använda boost::variant över boost::any i implementeringen av DataContainer. Prestandamässigt finner vi att det är olämpligt att serialisera meddelandena med boost::serialization. Mer om detta i avsnitt 4.1. Så för att serialisera bör man söka sig någon annanstans för att kunna uppnå prestandan som krävs i detta ändamål, kanske Protocol Buffers [11] skulle kunna klara av prestandakraven Systemet i helhet Nu när vi har gått igenom alla delar i systemet går vi igenom hur det hela hänger ihop. Till att börja med har vi sensorerna. Dessa övervakar ett visst område och meddelar vad de ser via CAN, vilket är en nätverksstandard utvecklad för fordonsindustrin. En dator läser av dessa meddelanden och RTMaps översätter meddelandena till sitt eget format så att de går att använda. Dessa meddelanden skickas vidare till värdprogrammet i detta projekt via TCP. Värdprogrammet tar emot dessa meddelanden och översätter till det interna dataformatet och lagrar i DCDB. Sensormeddelandena finns nu tillgängliga för de insticksmoduler som har laddats in och startats av värdprogrammet. Insticksmodulerna har även möjlighet att lagra egenproducerad information i DCDB, precis som om det vore ett sensormeddelande. Vissa insticksmoduler är tänkta att agera utifrån vad 19

27 sensormeddelandena säger och skickar instruktioner till aktuatorer i lastbilen vilket innebär att lastbilen styrs utifrån instruktionerna. Även dessa instruktioner kan man skapa på det interna dataformatet. Värdprogrammet översätter till RTMaps-formatet och skickar vidare till RTMaps via TCP. RTMaps skickar sedan vidare instruktionerna till aktuatorn via CAN. Nedan i figur 3.6 visas en översiktlig bild på systemet i sin helhet. Figur 3.6 En översikt på hur systemet ser ut i helhet. Här ingår Sensor, RTMaps, Datalagring, Värdprogram, Insticksmoduler (Plugin) och Aktuatorer. Sensorer och Aktuatorer är inget som projektet har fokuserat på. RTMaps har, som nämnts, hand om data till och från Sensorer och Aktuatorer. Datalagring, Värdprogram och Insticksmoduler är de som konstruerats i projektet samt kommunikation med RTMaps. 20

28 4. Resultat och slutsatser Under projektets gång har en del test utförts för att leda vägen för det fortsatta arbetet med ramverket. När ramverket hade fått en slutlig form skapades en insticksmodul för att se hur det fungerade Hur sköta kommunikation mellan sensor och kärna Tidigt i projektet gjordes ett test för att se vilken väg som skulle tas för att sköta kommunikationen mellan de olika delarna som skulle skapas. Testet gick ut på att ta reda på om vi kunde använda TCP effektivt för att föra över data mellan RTMaps och ramverket. Ytterligare test gjordes för att ta reda om en konvertering av data gick att göra innan man skickade över informationen för att i ramverket undvika att behöva känna till RTMaps specifika dataformat. Testets utförande gick till så att vi hade en inspelad sekvens som kunde spelas upp i RTMaps. Detta innebar att vi kunde få exakt samma sensordata från RTMaps upprepade gånger vilket är ett perfekt verktyg för att kunna utföra tester där våra sensordata inte spelar någon roll så länge som man använder samma testdata. Sekvensen var inspelad från Scanias testbanor med ett antal sensorer över en tid på 4 minuter och 34 sekunder. Från våra testdata användes endast data från en specifik sensor, nämligen laserscannern. Vi gjorde detta val eftersom laserscannern är den sensor som skickar mest data av de sensorer som används av Scania i dagsläget. Den skickar ungefär tio gånger så mycket data som de andra sensorerna tillsammans [12]. Metoden som var bestämd från början gick till så att vi omvandlade en sensorrapport till en DataContainer som beskriver exakt samma meddelande. Det vi sedan gjorde var att automatisera serialiseringen med hjälp av boost::serialization. Det serialiserade meddelandet skickades med TCP till kärnan där det deserialiserades till en DataContainer igen och lagrades sedan i DCDB, det vill säga datalagringen. Vad som stod klart efter testerna var att den metod som hade valts från början med boost::serialization inte riktigt fungerade för att översätta sensorrapporterna till strängar färdiga att skickas med TCP. Den kunde inte gå igenom alla sensormeddelanden i tid och det bildades en lång kö med sensorrapporter som behövdes gå igenom och skickas vidare. Detta innebar att de data som insticksmodulerna fick tag på var inte den senaste. Efter detta upptäcktes det att RTMaps hade färdiga metoder för att skicka runt sitt interna dataformat med hjälp av TCP. Det enda som saknades för vårt projekt var att hålla reda på vilken sensor meddelandet kom från för att kunna lagra det under rätt sensornamn i datalagringen. 21

29 I projektet används alltså TCP för kommunikation mellan RTMaps och ramverket. Detta beslut gjordes på grund av bekvämligheten att veta att sensormeddelandena kommer fram och i ordning. Det bör gå att byta till UDP utan problem. RTMaps och ramverket var tänkt att vara på samma dator vilket innebär att felsökningen som TCP tar hand om inte är lika viktig och ramverket tar hand om ordningen med hjälp av tidsstämplarna. Om man ser på andra metoder som skulle kunna användas till exempel delat arbetsminne är det möjligt att de har fördelar gentemot TCP och/eller UDP men de kommer även med nackdelar. Fördelarna som möjligtvis finns är att det använder mindre resurser på systemet samtidigt som meddelandena når ramverket snabbare. Att sensormeddelandena når ramverket så snabbt som möjligt är något som är ytterst viktigt. Nackdelarna med dessa metoder är extra arbete och förlorade möjligheter. Om man tar delat minne som exempel försvinner möjligheten att RTMaps och ramverket är på olika datorer. På grund av avsaknad erfarenhet av delat minne gjorde att TCP och UDP lockade mer i valet av kommunikationen mellan processerna Skapa egen insticksmodul För att testa hur det är att utveckla insticksmoduler till ramverket skulle man kunna låta utvecklare, som inte varit med när ramverket skapades, försöka utveckla insticksmoduler med antingen ett givet mål eller en helt egen insticksmodul med egen funktionalitet. Sedan skulle de kunna ge feedback om vad som var svårt, vad som skulle kunna förbättras, vad som var bra och så vidare. Detta test är något som projektet saknar. Däremot har vi utvecklat en insticksmodul. Insticksmodulen som skapades var tänkt att skapa en egen intern bild över hur man kört med hjälp av en hastighetssensor och vinkeln på hjulen. Utöver detta användes en klocka för att hålla reda på hur lång tid det tagit mellan de olika mätningarna. Algoritmen gick ungefär som följer: position = (0,0) lasttime = currenttime() while true v = getdata( ABS, frontaxlespeed ) u = getdata( ABS, yawrate ) tmptime = currenttime() position = updateposition(position, v, u, timediff(lasttime,tmptime)) wait(100-timediff(lasttime,tmptime)) // gör varje loop 100ms lasttime = tmptime 22

30 För att skapa denna insticksmodul krävdes det inte mer än så, varje rad kunde översättas var för sig. Det blir dock en naiv implementering. Det som försvårar är till exempel om data inte finns tillgängligt när det efterfrågas eller om data som efterfrågas inte uppdateras så ofta som man hade önskat. Sådant är sensorspecifikt och svårt att abstrahera utan att låta insticksmodulskaparen få extra information om det data som efterfrågas, till exempel åldern på sensordata eller om det data som efterfrågas inte finns tillgänglig. För att visa hur det fungerade till slut har vi tagit data från GPS och använt Google Maps för att visa hur rutten såg ut enligt den GPS vi använde. En bild på detta visas nedan. Figur 4.1 En karta över Scanias testbana i Södertälje med en svart linje som motsvarar den rutt som kördes enligt GPS. Vidare gjordes ännu en bild med Google Maps för att visualisera data från insticksmodulen. Data från insticksmodulen var dock inte passad mot en karta, så 23

31 ett visst arbete har gjorts i efterhand för att passa data efter karta. Det som visas är ungefär det som skulle ha representerats av insticksmodulen om den hade haft kännedom om startposition och kartan i övrigt. Bilden som illustrerar detta visas nedan. Figur 4.2 En karta över Scanias testbana i Södertälje med en svart linje som motsvarar den rutt som kördes enligt insticksmodulen. Som synes är varken data från GPS eller insticksmodul helt att lita på eftersom de visar en rutt som går en bit från vägen enligt kartan. Kombinerar man resultatet från insticksmodulen med en karta skulle man möjligtvis kunna ordna till resultatet och räkna ut vilka vägar som följdes och därmed få en mer korrekt bild av hur rutten såg ut än den som visas ovan. Metoden som användes påminner mycket om vad som kallas död räkning, vilket användes inom sjöfart och luftfart innan GPS-systemet fanns. Anledningen till varför man skulle vilja använda denna metod är om GPS-systemet inte fungerar där man befinner sig eller om man vill ha en reservplan om det plötsligt slutar fungera. Faktorer som gör att resultatet 24

32 inte speglar verkligheten är felaktigheter i sensordata, uppdateringsfrekvensen och att resultatet egentligen inte är passad mot en karta Tester på ramverket För att undersöka om ramverket fungerar som det borde i teorin utfördes ett antal tester. Dessa tester var gjorda som insticksmoduler till ramverket och var designade för att testa specifika egenskaper hos ramverket för att se att det stämde överens med teorin. Kommunikation mellan sensor och ramverket tas inte med då den enda skillnaden mellan dessa och tester på insticksmodulerna är kommunikationshastigheten. Sedan är tester på insticksmoduler enklare då dessa får konfirmering på när insättning i datalagringen är klar, medan det inte är någon kommunikation tillbaka från ramverket till sensorerna. Testsystemet som användes var en FSC Amilo Li2727 med operativsystemet Ubuntu och kompilatorn gcc Alla tester upprepades tio gånger för att säkerställa ett korrekt resultat. I diagrammen som visar resultaten för testerna representerar varje punkt ett medelvärde för de tio testerna som gjordes Tester med insättning i datalagringen En insättning i databasen motsvarar till exempel en sensor som rapporterar med ny data eller en insticksmodul har kommit fram till någonting med hjälp av andra sensorers och insticksmodulers data och vill lagra det den kommit fram till i datalagringen. Två tester utfördes som handlade om insättning i datalagringen. Det ena handlade om insättningshastigheten om fler sensorer eller insticksmoduler lagrar data under samma sensornamn, det andra handlade om insättningshastigheten om fler sensorer eller insticksmoduler lagrar data med olika sensornamn. Varför dessa test gjordes var för att se hur mycket mer krävande det är när fler sensorer eller insticksmoduler försöker komma åt samma del av datalagring. Anledningen till att det tar längre tid är att vi låser en resurs för att förhindra problem som uppstår om något ändras samtidigt som någon annan läser från samma resurs. Låsningarna gör att det bildas en sorts kö som låter en insticksmodul eller sensor åt gången lagra eller läsa data i datalagringen för respektive sensor. Resultatet syns i diagram 4.1 nedan. 25

33 Hastighet för insättning med fler insticksmoduler Olika sensorer Samma sensor Sekunder Antal insticksmoduler Diagram 4.1 Visar hur insättningshastigheten av en miljon datapunkter varierar för en till sex insticksmoduler om de sätter in data till samma sensor eller olika sensorer. Som testresultaten visar ser det ut att öka linjärt i båda fallen. Om insticksmodulerna lagrar till samma sensor ser vi en brantare lutning jämfört med lagring till olika sensorer Tester med uttagning från datalagringen En uttagning från datalagringen motsvarar att en insticksmodul efterfrågar något specifikt data och får reda på om den finns och i sådana fall får den efterfrågade data. En uttagning från datalagringen kan likställas med att läsa ett eller flera datavärden från datalagringen. Två tester utfördes som handlade om uttagning ur datalagringen. Det ena handlade om uttagningshastigheter om fler sensorer eller insticksmoduler läser data från samma sensor, det andra handlade om uttagningshastigheten om fler sensorer eller insticksmoduler läser data från olika sensorer. Som tidigare med testerna om insättningen är det låsningen av resurser som är intressant. Resultatet syns i diagram 4.2 nedan. 26

34 Hastighet för uttagning med fler insticksmoduler Olika sensorer Samma sensor Sekunder Antal insticksmoduler Diagram 4.2 Visar hur uttagningshastigheten av en miljon datapunkter varierar för en till sex insticksmoduler om de läser data från samma sensor eller olika sensorer. Som testresultaten visar ser det ut att öka linjärt i båda fallen. Lutningen på graferna är lika i de båda fallen, dock tar det längre tid för insticksmoduler att läsa från samma sensor jämfört med att läsa från olika sensorer. 27

35 5. Rekommendationer Externa funktioner är inte lämpliga när det kommer till stabilitet i C++. Vi skulle råda till att låta insticksmoduler att kommunicera via något mer allmänt format, exempelvis textsträngar över TCP. Fördelarna med detta är att insticksmodulerna inte behöver vara skrivna i C++ med samma kompilator utan de kan till och med vara skrivna i Java eller något annat språk som har tillgång till TCP. En stor nackdel med detta är att kommunikationen skulle öka tiden det tar att kommunicera mellan de olika insticksmodulerna och kärnan. Datalagringen bör nog implementeras som en insticksmodul så att man kan ge en möjlighet att skräddarsy datalagringen beroende på vad man lagrar. Den implementeringen som kommer med detta projekt använder sig av arbetsminnet. Men det passar inte om man vill lagra större mängder data, eller data som man vill lagra även efter programmet avslutats. Även datamottagningen och datasändningen mellan kärnan och RTMaps skulle med fördel kunna implementeras som insticksmoduler. Helst på ett sådant sätt att RTMaps abstraheras och kan bytas ut om/när andra programvaror erbjuder ett bättre utbud av funktioner och sensorkopplingar. Det är ju viktigt att tänka på att ett program ska kunna överleva förändringar i omvärlden. Angående sättet insticksmoduler får tillgång till data fungerar inte riktigt med alla olika sorters insticksmoduler man skulle vilja göra. En insticksmodul som vill använda all data från en sensor kan inte göra detta utan en hel del extra onödigt arbete. Det skulle vara bra om kärnan tillät en insticksmodul att prenumerera på en sensors eller insticksmoduls data så att den prenumererande insticksmodulen får tillgång till data allt eftersom den blir tillgänglig. Detta skulle leda till att insticksmodulerna måste skrivas trådsäkra, eftersom de kommer få data från en utomstående tråd, vilket är något vi har undvikit igenom hela projektet. Fokuset har hela tiden legat på att göra insticksmoduler enkla att utveckla. 28