Map Engine with Route and Slope Prediction for Autonomous Vehicles in Offroad Applications

(1)

UPTEC F 17047

Examensarbete 30 hp Augusti 2017

Map Engine with Route and Slope Prediction for Autonomous Vehicles in Offroad Applications

Erik Stigenius

(2)

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress:

Box 536 751 21 Uppsala

Telefon:

018 – 471 30 03

Telefax:

018 – 471 30 00

Hemsida:

http://www.teknat.uu.se/student

Abstract

Map Engine with Route and Slope Prediction for Autonomous Vehicles in Offroad Applications

Erik Stigenius

With an imminent future of fully autonomous heavy duty vehicles in offroad applications, the need for advanced control system will increase accordingly.

By implementing a raster map with tiles and pixels, to which a vehicle can record slope and position data while driving, it is possible to map earth's surface. By adding a heat parameter to every pixel, i.e. the number of passings through it historically, it is possible in future visits of the same are to generate a route prediction made up by the "hottest" pixels. By fetching the slope values in the hottest pixels, it is possible to generate a slope horizon that can be utilized by control systems, e.g. when planning gear shifts in hilly offroad terrain.

To mange the incrementally growing map, a memory management system was implemented. It buffers the relevant map data from the database, i.e. the vehicles closest surroundings, which is then used for route prediction and horizon generation. As the vehicle moves into other areas, new data is read from the database, and the recently passed area is written back to the database, however updated from the recent passing.

The system is implemented so that it runs through another application in the telematics electrical controller unit (ECU) in a Scania vehicle. The ECU contains a GNSS module from which the vehicle fetches satellite positioning data. Slope data is fetched from a slope sensor mounted on the truck.

Due to implications during testing and debugging of the resulting application developed and implemented during this thesis project, the application's performance couldn't be assessed properly. However, it is concluded that the background the application is built on is reliable, although tweaks to get the application fit for usage in offroad terrain had to be made. Mainly, the horizon length and map building techniques should not be the same as in similar applications for onroad driving.

ISSN: 1401-5757, UPTEC F 17047 Examinator: Tomas Nyberg Ämnesgranskare: Mikael Sternad Handledare: Jimmy Nichols

(3)

Ruttplanering för autonoma fordon baserat på lutningsdata från högupplösta digitala kartor.

I en tid som inom fordonsindustrin karakteriseras av en snabb utveckling av autonoma fordon samt den teknik de bygger på – är kraven på smarta styrsystem högre än någonsin. Möjligheten för fordonsägaren att minska kostander för bränsle, och så småningom även för förare, är en del av drivkraften bakom den snabba utveckligen.

Moderna lastbilar har en rad olika sensorer som i realtid samlar stora mängder data. Det kan vara allt från lastbilens gps-position till radar- eller lutningsdata. Oavsett varifrån datan kommer – kan den användas på olika sätt i alla de smarta styrsystemen som finns. Ett exempel på ett sådant smart styrsystem, som idag är en vanlig syn i fordon, är farthållare som aktivt med hjälp av algoritmer reglerar fordonets fart för att minska bränsleförbrukningen.

Gemensamt för en del av styrsystemen är att algoritmerna baserar sina beslut på data från någon typ av digital karta. En sådan digital karta kan byggas upp på flera olika sätt, men gemensamt för de olika teknikerna är att data från olika sensorer på ett fordon sparas i kartan. Beroende på vilken typ av data som sparas i kartan, kan den användas i olika styrsystem med olika uppgifter.

Genom att dela in jordens yta i ett rutnät, kan man skapa en så kallas raster- karta. En raster-karta innnebär att den data man vill spara i kartan sparas i ett rutnät. Varje ruta i kartan motsvarar en position i verkligheten, samt ett mätvärde från någon sensor. Genom att öka eller minska storleken på rutorna i rutnätet så kan man anpassa nogrannheten i kartan baserat på hur datan sedan ska användas. Detta går att jämföra med hur exempelvis ett foto med stora pixlar ser suddigt ut, medan ett foto med många pixlar är skarpt.

En "heat-map" är en form av raster-karta där antal genomfarter i en ruta sparas i kartan. Nästa gång fordonet kör i samma del av kartan finns det statistik på hur fordonet har kört där historiskt sett. Sparas även lutningsdata i varje ruta, kan fordonet få information om vilken rutt det är mest sannolikt att det kör även denna gången, samt hur det lutar på den rutten.

Ju fler gånger lastbilen åker i samma område, desto nogrannare återspeglar

(4)

den digitala raster-kartan verkligheten. Om man samtidigt låter flera spela in data till en gemensamkarta så kan man snabbt bygga upp tillförlitlig lutningsdata som kan användas i styrsystemen till olika uppgifter. Exem- pelvis för att underlätta timingen av växelbyte, något som är väldigt viktigt för tungt lastade lastbilar i backig terräng för att inte få motorstopp i en brant backe. Med hjälp av lutningsdatan i kartan kan man även reglera gaspådraget i en uppförsbacke om man vet att det kommer en utförbacke direkt efter. Genom att släppa på gasen en bit innan krönet på backen kan man spara värdefulla bränslekostnader.

(5)

(6)

Glossary

There are several technical terms, abbreviations and acronyms used in this report. This glossary is included for the reader to return to in case of con- fusion.

ECU Electrical Controller Unit - electrical unit in a vehicle with software for controlling the vehicle in several ways.

CAN Controller Area Network - the network over which the data is sent between ECUs in a vehicle.

ADAS Advanced Driver Assistance System - advanced vehicle control system

ADASIS Advanced Driver Assistance Systems Interface Specifications

ADAS Horizon A horizon of a specified length containing various data with the purpose to make a vehicle aware of its route ahead.

Route Prediction A prediction of which route a vehicle will drive on from its current position

Profile Spot A data point containing, among other things, a position (lat&lon) and an associated slope value

(7)

GNSS Global Navigation Satellite System

GPS Global Positioning System - a type of GNSS

WGS84 World Geodetic System 1984 - a system to model the surface of the earth as a ellipsoid with latitude and longitude coordinates.

NMEA National Marine Electronics Association - the association that has developed the standard protocol used for GNSS data.

NMEA Sentence A string of characters organized according to the NMEA standard.

Offroad/Onroad Applications An expression used to categorize a vehicle based on how it is being used, either in offroad or onroad terrain.

Application Computer program/system that performs a certain task.

(8)

Chapter 1 Introduction

With the increase in demand of semi autonomous vehicles during the last decades and the generally adopted target among vehicle manufacturers and their customers, as well as in society in general, of a future with fully auto- mated vehicles, the need for Advanced Driver Assistance Systems (ADAS) for vehicles is bigger than ever.

In present time there are several driver assistance systems available for heavy duty vehicles, e.g. adaptive cruise control and lane assistance. How- ever, with increasing demand on higher levels of autonomy as well as better fuel efficiency, the systems become more advanced in terms of how much and how accurate data that is needed.

Input data can be provided using different methods. Data about a vehicle’s closest surroundings can be gathered by sensors in real-time or with very high frequency. However, with more advanced autonomous driving functionality, information about the surroundings, roads etc. far ahead of the vehicle is also needed, a so called horizon of data. To generate a horizon with data, pre-recorded maps with information about the road network and its surroundings, can be used as a source.

With modern sensors of many kinds, e.g. cameras, accelerometers, radar, lidar etc., the possibilities of what data that can be gathered and either record and store in a map, or use in control systems, are many. And the factors limiting usage of data is often lack of computer power and creativity, rather than lack of good data.

1

(11)

2 Chapter 1. Introduction

1.1 Problem Definition

With the usage of digital maps containing various data about road networks and surroundings, the length of the horizon that a vehicle can be aware of can be greatly increased. The data can e.g. be road attributes such as slope, curvature or surface. By utilizing horizons of various data as input in control systems, it is possible optimize a vehicle’s performance during the whole range of the horizon. Currently, common optimizations that often depend on prediction horizons of the road ahead are e.g. gear shifts and throttle in order to improve fuel efficiency.

In present time at Scania, there are applications with digital maps containing data of road attributes with the possibility to generate prediction horizons for optimization of performance when driving onroad. However, there is not yet such an application for offroad driving optimization, e.g. when driving in quarry and forestry applications. Therefore, the task of this master thesis is to develop and implement a system that make use of a digital map containing data, with the ability to predict upcoming route as well as to generate a slope horizon for the upcoming route, by using the map data.

Such a system mainly consists of four parts:

1. A digital map containing certain road attributes, and with the functionality to incrementally update itself with new data for uncharted territory, as well as to keep already mapped parts up to date, in real- time as the vehicle moves.

2. Route prediction and slope horizon generation. The route prediction will be based on statistics of historical route choices and the slope horizon will be based on the slope data recorded in the map. With the purpose of this project being a system exclusively for offroad driving in relatively low speeds and limited areas, the optimal length of the horizon needs to be investigated. Furthermore, a confirmed end user for this project have come with requirements regarding horizon length in order for the system to fit their needs, something that will be taken into account.

3. A memory management solution. Since the digital map incrementally grows bigger and bigger, the memory needed for storage of it will become too much to store in the main memory of the embedded

(12)

1.2. Purpose and Objectives 3

controller unit on which the system will be implemented.

4. A interface to already existing software in the embedded controller unit in which the system will be implemented. By doing this, the system will become modular, a key concept in the development process at Scania.

Figure 1.1: Illustration of how the desired system could look like

1.2 Purpose and Objectives

With the increase of autonomous vehicles, reliable control systems will become even more important. To be able to develop such control system, data of good quality to base control strategies on, will become more important as well. This project aims to prove the usefulness of one such method - to provide control systems with a horizon of reliable data to base control strategies on. Therefore, the overall objective of this master thesis is to develop a system that can provide vehicles with accurate map data and predict a route based on historical movement and generate a horizon with road slope data, for usage offroad driving applications. Furthermore, the output of the system should make it possible for control systems to optimize a vehicle’s performance on the output route, mainly by allowing gear shifts to be made at the right timing in offroad terrain, something that vehicles currently are having trouble to do successfully and safely.

(13)

4 Chapter 1. Introduction

1.3 Delimitations

Due to the vast amount of data gathered by Scania’s vehicles, of which much is possible to store in a map and use to base path prediction and horizon on, a delimitation has to be made in order to keep the workload within reasonable limits. Therefore, to clarify the objective and narrow the scope of this master thesis, the system developed and implemented will only take road slope data into consideration. However, the design of the program will be made in a way that allows for future additions of road attributes that can be stored in the map as well as base path prediction and horizon on.

1.4 Methodology

Initially, research of already existing related work will be performed. There are many studies on different techniques to build digital maps.The master thesis Grid Based Predictive Road Map [4] by Pivén and Ekstrand from 2015 and Robust Route Prediction in Raster Maps [6] by S. Fabian from 2015 will also be studied with the purpose of finding inspiration and ideas. Furthermore, ADASIS v2 Protocol [1], which is the protocol for ADAS-messages that is to be sent between electrical controller units in a truck.

The goal of this thesis project is to develop an embedded system and implement it on the electrical controller unit (ECU) for telematics, which is mounted in all Scania trucks. Since the system needs to interface to the already existing software in the ECU in question, documentation on both the ECU and the already existing software will be necessary to study in order to understand how to make the developed system modular, as already mentioned - a key concept in all development processes at Scania.

Furthermore, the actual development and implementation will be divided into four parts: mapping and recording, route prediction and slope horizon generation, memory management and interface to existing software.

It will be done using Scania’s development environment - a virtual ma- chine running on Linux. The implementation will be done in C++. Code and algorithms will be developed and written with inspiration from previous work. Unit testing of each of the individual parts of the system will

(14)

1.4. Methodology 5

be performed throughout the process to make sure desired functionality is achieved. However, integration tests in a real truck will be performed at the end of the project, which also includes test driving on Scania’s test track, with logging equipment to monitor and record the system’s performance.

(15)

(16)

Chapter 2 Background

2.1 Theory

2.1.1 WGS84 and Distance Calculation

An international standard and commonly used coordinate reference system within cartography, developed by US Department of Defense in 1984 [10], is the World Geodetic System 1984 (WGS84). WGS84 is based on a standard ellipsoidal reference surface. WGS84 is also the standard reference coordinate system used by the global navigation satellite system GPS. A WGS84 coordinate consists of a pair of longitude and latitude values and references a point on earth’s ellipsoidal surface. The latitude value represents the angle from the equator towards either the north or south pole with respect to the system’s origin - earth’s center of mass, as seen in figure 2.1. It ranges according to eq. (2.1). The longitude value represents the angle from the prime meridian towards east or west, as also can be seen in figure 2.1. It ranges according to eq. (2.1).

−90^◦ <Latitude <90^◦

−₁₈₀^◦ <Longitude<₁₈₀^◦ ^(2.1) To calculate the distance between two WGS84 coordinates, i.e the arc length between two points, as seen in figure 2.2, the Haversine Formula,

7

(17)

8 Chapter 2. Background

Figure 2.1: Illustrates the concept of latitude and longitude in WGS84. Source: Wikimedia Commons

Figure 2.2: The arc distance between two points, P and Q, on a sphere - can be calculated using the Haversine Formula. Source: Wikimedia Commons

d=2R arcsin s

sin²

∆latPQ

2

+cos(latP)cos(lat_Q)sin²

∆lonPQ

2

! (2.2) can be used. Where d is the arc length between P and Q and R is the radius of the sphere.

Equation 2.2 is derived from the Law of Haversines, which states the relation between the three sides of a triangle projected on the surface of a sphere, as illustrated in figure 2.3.

(18)

2.1. Theory 9

The WGS84 system is based on the fact that earth is an ellipsoid and not a sphere, which contradicts the possible use of the Haversine formula when calculating distances. However, when using the Haversine formula for short distances, the surface of the reference ellipsoid for the WGS84 system can be approximated as a spherical surface - and thus be used with satisfying accuracy.

Figure 2.3: Law of Haversine states the relation between the three sides of a triangle on the surface of a sphere. Source: Wikimedia Commons

2.1.2 GNSS Positioning and NMEA sentences

A Global Navigation Satellite System is a system that enables accurate real time positioning on earth’s surface. There are a number of GNSS:s in operation today, e.g. GLONASS, Galileo, Beidou and GPS - with GPS being the most widely used.

Positioning in a GNSS is based on several satellites that transmit their position relative to a receiver located on earth’s surface, including an associated time stamp. The receiver can, with the knowledge of several satellites’ positions and the propagation velocity of their radio waves sent through the atmosphere, calculate its distance to each of the satellites. By using trilateration it is then possible to determine the receiver’s position with an accuracy of up to a few meters, a concept illustrated in figure 2.4.

The resulting data from the trilateration can then be formatted according to the NMEA standard data format into NMEA sentences. The standard was first developed by the National Marine Electronics Association in 1983, but has been updated several times since then. There are different kinds of NMEA

(19)

Figure 2.4: Illustrates the concept of positioning with trilateration, with P₁, P2and P3being satellites in the atmosphere and B a receiver on earth’s surface. Source: Wikimedia Commons

sentences used for GNSS data, e.g. GSV, GSA, GGA and RMC. GSV contains detailed satellite data, GSA overall satellite data, GGA fix information and RMC recommended minimum data for GNSS/GPS. A RMC sentence can for example look like

$GPRMC, 140752, A, 5205.037, N, 01232.000, E, 027.1, 014.5, 190617, 002.2, W∗6A (2.3) where the meaning of each part of the sentence can be seen in table section 2.1.2.

RMC Recommended Minimum sentence C 140752 Fix taken at 14:07:52 UTC

5205.037,N Latitude 52 deg 05.037’ N 01232.000,E Longitude 12 deg 32.000’ E

027.1 Speed over the ground in knots 014.5 Track angle in degrees True 190617 Date - 19th of June 2017 002.2,W Magnetic Variation

*6A The checksum data, always begins with *

Table 2.1: Showing the meaning of the different parts of the NMEA RMC sentence in eq. (2.3)

(20)

2.1. Theory 11

2.1.3 Bresenham’s Line Algorithm

Given two points in a grid, by using Bresenham’s Line Algorithm it is possible to determine the pixels in the grid forming a straight line between the two given points, as seen in figure 2.5.

Figure 2.5:Illustration of the concept behind Bresenham’s line algorithm. Source: Wikimedia Commons

Depending on the slope of the line, the direction in which the line stretches the most is the major axis. The pixels representing the line are found by choosing the pixel with its center closest to the true line, for every step taken along the major axis. The algorithm can be implemented using integer calculations only, which makes it fast and effective with respect to processing power [7].

2.1.4 Weighted Arithmetic Mean

When taking the mean of several values, where the values have different weights in the resulting mean, it is called a weighted arithmetic mean, and it can be calculated according to eq. (2.4). If the interval from which the values are sampled from moves according to certain requirements, e.g. with respect to time, the mean becomes a moving weighted arithmetic mean [2].

The moving weighted arithmetic mean is suitable to use when the mean value needs to be based on a certain set of data a limited interval. The newest samples can be given the biggest weight and older are given a smaller weight, or vice versa, depending on requirements. The length of the interval can also be adapted to fit the requirements [2].

(21)

¯x = ^∑

ni=1w_ix_i

∑ⁿi=1wi

=

= ^w¹^x¹+w₂x₂+_...+wnxn

w1+w2+...+wn

(2.4)

With normalized weights, i.e. when∑ⁿi=1w_i =1, eq. (2.4) can be simplified to

¯x =

∑

n i=1

wixi. (2.5)

2.2 Telematics ECU

The target ECU for the system is a telematic unit that is available in all Scania vehicles. Its main purpose is to handle all communication to and from the vehicle, and do so with telecommunication. It is also the ECU that receives GNSS signals, which includes information about positioning, velocity, heading, altitude etc. The GNSS signals then propagates to different applications in the ECU.

2.2.1 Software

The ECU have many different applications and tasks. One important part of it is the application for "lookahead"/prediction-functionality. It is responsi- ble for the providing of ADAS horizons, which is to be sent on CAN to other ECUs, among other things. It contains several different sub-applications, each with their own task.

One of the sub-applications is a map engine developed by third-part used for onroad driving applications. It provides a default map containing data of the road network that is used for route prediction and horizon generation. The map receives updates with new data when necessary. However, to take advantage of the data gathered by Scania’s vehicles, Scania has developed their own application that runs in parallel and records road data from sensors on the vehicle, e.g. slope and position. This data is stored

(22)

2.3. Mapping 13

separately from the provided default map, but is also used in the route prediction and horizon generation.

The applications in the telematics ECU are interfacing with each other with standardized interfaces, which makes all the software modular. To keep the integration of the system developed in this master thesis project as simple and effective as possible, it is supposed to use the same interface as already existing applications.

Figure 2.6:Overview of the relevant parts of the target ECU’s software

2.3 Mapping

Two common techniques used for representation of data when building digital maps are raster and vector representation. In both cases, naturally, the accuracy of the input data is important to get an accurate map. Error offsets in input data, e.g. erroneous positioning and slope data, will in the end decrease the effectiveness of the various systems dependent on the map data. In the case where the map data is used in vehicle control systems to increase fuel efficiency, it is shown by Holma in [8] that small error offset in positioning and slope data causes throttle, braking and gear shifts with bad timing, which decrease the effectiveness of the system.

(23)

If a map is to be incrementally updated in real time, the increasing memory usage will become a problem regardless of how the map is built. There are studies on this matter that are accounted for in this section.

2.3.1 Raster Representation

Raster representation divides the mapped area into a grid, and store information in each cell of the grid, as seen in the top part of figure 2.7.

The resolution of raster map is determined by the size of the individuals cells. Therefore, with large cells the resolution becomes low, resulting in low accuracy of the data representation. Similarly, small cells results in high resolution and high accuracy of data representation. However, the cell size also affects the data processing. With large cells data processing, in general, becomes faster. And with smaller cells - vice versa. The possibility to adjust the cell size depending on the requirements of the application, also means that it is possible to affect the memory usage and processing power of the application, although raster maps in general need less memory and processing power than other map types, e.g. vector maps.

There are studies on the use of raster maps in applications with incrementally updated road maps. One that investigates the problem that the memory usage of incrementally updating maps become big very fast, is Kon- rad et al. in [3]. In the study, a system that incrementally builds a raster based road map in real time with arbitrary sensor data, is developed. To make sure the map’s increasing memory usage doesn’t become a problem in terms of processing power and memory usage, the area kept in main memory is limited to a so called grid patch, which is loaded from a hard disk temporarily into main memory. This map does not reference any global reference system, but positioning is performed through estimation based on comparisons with GPS maps.

However, the use of grid maps combined with a global reference system has been investigated by Rovira-Más in [11], a study that investigates the possibility to use grid maps for controlling of autonomous offroad vehicles in the agriculture industry. The system utilizes a 2D grid with data from stereo vision sensors. It also take into account the vehicle’s position and heading. Furthermore the system transform the internal grid map into a globally referenced 2D grid map based on GPS coordinates. A mapping process much alike the one used by Pivén et al. in [4], which is accounted

(24)

2.3. Mapping 15

for in more detail in section 2.3.3.

Figure 2.7:Illustration of the difference between raster and vector data representation in a map. Source: Wikimedia Commons

2.3.2 Vector Representation

A vector map is based on individual points that form lines, polygons and other shapes to represent information of a mapped area, as seen in the bot- tom part of figure 2.7. With the representation being dynamic, it is possible to accurately represent data. However, for this technique to be accurate, location of each point of a shape needs to be stored and be accurate. With large data sets, the representation becomes more accurate, but it also result in the need of more memory and processing power at creation. Therefore, this technique is not optimal for usage in an embedded device with incremental updates, which is showed by Biagioni et al. in [5]. However, there are algorithms specifically used for automatic generation of maps with vector representation, although without incremental updates. These are Trace Merging, Kernel Density Estimation and K-Means.

When using trace merging, traces similar enough to each other are simply merged into one single trace. By using additional weights on each trace, which is increased for every merge, it is possible to distinguish erroneous traces from real ones.

(25)

K-Means divides location data points into clusters. The data point is added to a cluster based on the proximity to the cluster’ center. The cluster center is an average of all points, and it is recalculated every time a point is added.

To generate roads from the data points, they are linked to form roads based on its position and direction. This method is not suitable for an incremental road map since the clusters needs to be recalculated every time a new data points is added, something that requires a lot of processing.

Kernel density estimation puts a grid on recorded traces. Every cell in the grid has a weight that represents either the the number of traces or number of visits in that cell. The more traces or visits in a cell, the higher weight.

From the resulting map, it is possible to extract a road network. However, this algorithm shouldn’t be used for incrementally updating maps since it need to rerun every time new data is available.

2.3.3 Coordinate Mapping

To relate WGS84 coordinates to a position in a digital map, an internal cartesian coordinate system can be used. This technique is used by both Pivén et al. in [4] and by S. Fabian in [6], and shows good results. By first dividing the surface of the earth into a grid of tiles, as seen in figure 2.9, where tile has a cartesian x and y coordinate as identifier. And secondly, divide each tile into a grid as well, containing pixels, also with a cartesian coordinate for positioning within a tile. The main purpose of the tiles is to facilitate the implementation of the memory management technique accounted for in section 2.5. The pixels are used to store the actual data in the map. The resulting grid allows for easy positioning by transforming WGS84 coordinates to cartesian coordinates.

The size of the pixels determines the resolution of the map and affects both horizon accuracy as well as needed computer power, consequently, it has to be determined to fit the application requirements. However, S. Fabian shows in [6] that a pixel size of 20x20m is optimal with respect to horizon accuracy for both onroad and offroad applications. A smaller sized pixel will increase the total number of pixels, which will result in heavier computing and decreased positioning accuracy, while a larger pixel size will decrease resolution and therefore map and horizon accuracy as well as decrease the total number of pixels and the computer power needed for calculations.

The size of a tile, i.e. the number of pixels in a tile, can be chosen to fit the

(26)

2.3. Mapping 17

requirements of the memory management system.

Since the earth is modeled as an ellipsoid in the WGS84 system, the cells of the resulting grid will not be perfectly rectangular, which can be seen clearly in figure 2.8. The east-west change of the cell’s size will increase with distance (north/south direction) from the equator.

Figure 2.8:Illustrates the East-West change of cell size in a grid projected on an ellipsoid

The main benefit of an internal cartesian coordinate system is its simplic- ity, resulting in more efficient computing, low memory usage and ease of implementation, which is also showed by Pivén et al. in [4] and S. Fabian in [6].

Figure 2.9: Illustrates the concept of dividing earth’s surface into a grid of tiles and a sub-grid of pixels, where each pixel contain various data

(27)

2.4 Route and Slope Prediction

A major part of the implementation of the system described in chapter 1 is the route and slope prediction based on data recorded in the digital map.

There are several techniques of doing this, which some are accounted for in this section.

2.4.1 Directional Based Route Prediction

In [4] Pivén et al. presents a route prediction algorithm based on the probability of which direction that is driven through a pixel depending on which side the pixel is entered from. The algorithm starts with the latest known position and bearing. When the vehicle enters a new pixel, it is determined, by using position and bearing, from which side pixel is entered. Historical data about the most usual bearing when entering from that side of the pixel is extracted and assumed being the new bearing, then the algorithm starts over. This creates a predicted route, and together with slope data it builds a horizon of slope data.

2.4.2 Heat Map Based Route Prediction

In [6] S. Fabian presents a technique for route prediction based on a heat map. The term heat map, originally described by C. Kinney in a patent[9]

from 1993, illustrates with "heat", the frequency of each element in a matrix, where the elements being data of some kind. The frequency, or heat, can represent anything and in this case it’s the number of visits in a pixel. Each time a pixel is visited the heat is increased by one. Therefore, the "heat" represents the probability of a vehicle passing through each pixel. By looking at the most likely pixel to come, in every step of the a vehicle’s movement, it is possible to predict the most probable route, given the pixels are previously visited and have a heat value. To further increase the accuracy of this algorithm, S. Fabian adds the aspect of travel direction, in the same way as the directional based route prediction. This results in a three layered heat map with one travel-through direction in every layer, including a corresponding heat and slope value for each direction. The directions are divided into three sectors ranging [0^◦−120^◦], [121^◦ −240^◦] and [241^◦−360^◦] with re-

(28)

2.5. Memory Management 19

spect to the pixel horizontal. The concept is illustrated in figure 2.9. To stop the heat value from overflowing its data type, an aging method is used.

When one of the three heat values in a pixel reach its upper limit, instead of adding 1 to that specific value, 1 is subtracted from the other two values.

By doing this, the ratio between the heat values remains.

2.5 Memory Management

An incrementally growing map’s memory usage grows in the same pace as the map itself. In an application running on an embedded device with limited memory, the increasing memory usage will become a problem. There- fore, a suitable memory management technique is needed with the purpose of limiting the amount of data in the system’s main memory. By doing this, calculations will become less heavy to perform and more effective. A technique developed by Hazel et al. in [12] and tested in applications with grid maps with good results, is to keep only the closest surrounding in the main memory, and update in real time. By using this technique, the majority of the map can be stored in a secondary memory, and only a suitable portion of the map can be loaded into main memory, allowing for effective processing. This technique, which is illustrated in figure 2.10 is also used with good results by Pivén et al. in [4].

Figure 2.10: Illustration of the concept of keeping only a limited area in main memory at a time. Source: [4]

(29)

2.6 Horizon Generation and Transmission

2.6.1 ADASISv2 Protocol

The ADASISv2 Protocol[1] is a protocol jointly developed by companies in the automotive industry and the content of this section, including figures, is sourced from the official and public documentation of the protocol.

The main purpose of ADASIS is to standardize the structure of messages with data sent over a CAN bus in vehicles and used by advanced driver assistance systems. The messages contains e.g. information such as latest known position in map, age and accuracy of latest known position, heading, speed, speed limits, number of lanes and much more. It also contains information about road geometry and attributes, e.g. curvature and slope, of the route ahead of the vehicle. By breaking down a horizon in several messages, it is possible to send it over CAN for other ECUs to utilize.

The protocol includes five different message types that can be used depending on what is to be sent. The messages are Position, Segment, Stub, Profile Short and Profile Long, and can be sent with different frequencies depending on the priority of the information. E.g. position data, which is of great importance in many applications, can be chosen be sent more frequently.

Figure 2.11:ADAS horizon based on stepwise interpolation

An ADAS horizon consists of several profile spots. Each profile spot contains a data value of some property, e.g. a slope value or a curvature value.

To build an actual horizon, a number of profile spots can be put after each

(30)

2.6. Horizon Generation and Transmission 21

other. To make the horizon continuous, either stepwise (seen in figure 2.11) or linear interpolation (seen in figure 2.12) are applied to the profile spots.

Figure 2.12: ADAS horizon based on linear interpolation

Figure 2.13: ADAS horizon optimized for bandwidth

When an ADAS horizon is to be sent over CAN, the profile spots are sent in profile short or profile long messages, depending on desired resolution.

The profile short message allows up to 10 bit data values whereas the profile long message allows for 32 bit data values. Other than the actual profile values, the messages also contain e.g. info such as id of the current horizon and accuracy of the profile values.

Depending on the requirements of the horizon, which can be either optimization with regard to bandwidth usage or with regard to robustness, the

(31)

messages are sent with different frequencies. Figure 2.13 shows how profile messages of a horizon should be divided if the horizon is to be optimized for bandwidth usage. In this case, messages are only sent if the profile is changing, compared to a horizon optimized for robustness (as in figure 2.14), where messages are sent for every point in the horizon, even those with unchanged profile. This results in a lower total amount of messages being sent when optimizing with regard to bandwidth and more messages when robustness is required.

Figure 2.14:ADAS horizon optimized for robustness

2.6.2 Horizon Length

Varying horizon length is something that affects both the accuracy of the horizon as well as the performance of the systems relying on accurate horizon data. It is shown by Hellström in [13] that for a truck of 40 tonnes in hilly conditions, a horizon length of roughly 2,5km is needed for optimal fuel savings. It also shows that for a truck of 20 tonnes in flatter conditions, a horizon length of 500m is sufficient for optimal fuel savings.

Furthermore, a simulation[6] based on data from a digital map with the number of route possibilities increasing with horizon length by S. Fabian, it is shown that both error as well as number of possible horizons increase with the length of the horizon, which can be seen in figure 2.15. This is due to distance estimation getting less accurate with distance from the truck, and that possible routes for a vehicle to drive increases with horizon length.

(32)

2.6. Horizon Generation and Transmission 23

Figure 2.15:Error as a function of horizon length. Source: [6]

2.6.3 Road Slope Estimation

For control systems to be able to optimize vehicle performance based on slope data, accurate slope data is required. Naturally - the more accurate data - the better performance. However, this is also affected by the robustness of the control systems, i.e. how well control systems handle erroneous data.

The slope value, ΘScania, estimated by the slope sensor on a Scania truck range −40.0% ≤ _Θ_Scania ≤ 40.3% and have a resolution of 0.02 percentage points. However, a slope value according to ADASIS[1], ΘADASIS, range

−_51.1% ≤ _Θ_ADASIS ≤ 51.2% with a resolution of 0.1 percentage points.

Depending on which type that is needed, the slope values can be converted with

ΘScania =111+ (_0.2Θ_ADASIS). (2.6)

The slope sensor of the truck samples slope values at 10Hz. To keep the slope data as accurate as possible, there are several criteria for which sample to use. E.g. during heavy accelerations and decelerations, when shifting gear and such, the slope sensor gives very erroneous values. Therefore, before the data is sent out to other parts of the vehicle, the erroneous samples

(33)

are all discarded, as well as samples that might violate some other criteria.

According to the ASASISv2, the slope value should be converted from a floating number to a 10bit unsigned int when sent over CAN.

(34)

Chapter 3 Implementation

The complete system was divided into four sub-parts in order to facilitate the implementation. This chapter aims to describe the implementation of each part.

3.1 System Overview

The implementation was based on the following two figures. The details of the implementation are accorded for in this chapter.

Figure 3.1: Illustration of how the desired system could look like

25

(35)

26 Chapter 3. Implementation

Figure 3.2:Illustration of the intended resulting software layout in the telematics ECU

3.2 Map

The map that were chosen to be implemented in this project is based on the map used in [6] by S. Fabian, which is a raster based heat map (as described in section 2.3.3) with the associated heat map based route prediction/horizon generation (as described in section 2.4.2).

The heat map implemented in this system is based on raster data representation, as described in section 2.3.1, and is divided into a grid of tiles and pixels. With the background of [6], the pixel size was set to 20x20m to yield optimal route prediction and to facilitate robust positioning. With the same background, the pixels were implemented in three layers with each layer representing a travel direction through the pixel and the corresponding heat of that travel direction. The travel directions were set as sectors ranging [0^◦−120^◦], [121^◦−240^◦] and [241^◦−360^◦], with respect to the pixel horizontal (accounted for in section 2.3.3). To be able to easily position a vehicle within the map, latitude and longitude from the vehicle’s GNSS receiver have to be transformed to coordinates referencing pixel’s global position within the internal cartesian coordinate system. By using the operations in eq. (3.1) on the pixel’s global position, it is possible to determine the current tile as well as where in the tile the current pixel is located. Thus, the system completely neglects the position of the vehicle

(36)

3.2. Map 27

inside a pixel.

pixelsPerTile=100 pixel_globalPos = (312, 459)

tile_globalPos = ^pixel^globalPos

pixelsPerTile = (3.12; 4.59) ⇒ truncated : (3, 4) pixel_posInTile = pixel_globalPos% pixelsPerTile = (12, 59)

(3.1)

T i l e {

u i n t 3 2 _ t x P o s P i x e l; u i n t 3 2 _ t y P o s P i x e l;

std::vector<Pixel> p i x e l s I n T i l e; }

Figure 3.3:The data structure of a Tile object

The tiles were implemented with the main purpose to facilitate the memory management system, which it does by allowing the change of the number of pixels, within a tile, to fit the requirements on horizon length (described in section 2.5). The number of pixels per tile were set to 100. With the knowledge that a sufficient horizon length in offroad applications are shorter than 2km, 100 pixels per tile will satisfy that requirement. The attributes of a tile during runtime can be seen in section 3.2.

P i x e l {

u i n t 3 2 _ t x P o s P i x e l; u i n t 3 2 _ t y P o s P i x e l; u i n t 3 2 _ t s l o p e s; u i n t 1 6 _ t h e a t s; }

Figure 3.4:The data structure of a Pixel object

The actual data in the map is stored in the pixels. To determine the data structures (seen in section 3.2) of a pixel, assessments were made. Firstly, the structure of the internal cartesian coordinate system. Equation (3.2) shows the number of pixels needed to cover all land area of the earth.

(37)

earthlandArea =149x10⁶km²

pixelarea =20x20m=4x10⁻⁴km² pixels/earth_landArea = ^earth^landArea

pixelarea

=3.72x10¹¹

(3.2)

With a 16bit x and y cartesian coordinate in the internal coordinate system, the maximum number of pixels possible to track in the system can be calculated as follows:

2¹⁶ =65, 536 ⇒ pixels/dimension

⇒

65, 536² =4.3x10⁹number o f pixels.

(3.3)

Since the number of pixels to cover all of earth land area > total number of possible pixels with a 16bit x and y coordinate, the coordinates were set to 32bit unsigned integers.

Furthermore, a pixel’s slope value. During runtime, there are three 10bit slope values available in the map, each for one of the three travel directions.

The values are stored temporarily in an array to to facilitate operations.

However, when a pixel is written to the database for long term storage, the three slope values can be serialized to a single 30bit unsigned integer by using bit operations. By adding 2 extra bits in front of the 30bit integer, as seen in eq. (3.4), it is possible to serialize and store the three slope values as 32bits or 4bytes.

extraBits =00

slope0=1111100000 slope1=0000000001 slope1=1010101010

⇒

combinedSlope=00|1111100000|0000000001|1010101010

(3.4)

The same method was used for the heat values of each pixel, as seen in eq. (3.5). As shown in [6], best results with respect to horizon accuracy were

(38)

3.2. Map 29

obtained when the heat of a pixel is bound by 5bits, i.e. 32. By serializing three 5bit heat values into 15bits, and adding 1 bit in front, the heat can be serialized as 16bits.

extraBit=0 heat0=00001 heat1=01100 heat1=10101

⇒

combinedHeat=0|00001|01100|10101

(3.5)

With a relatively low heat maximum limit of 32, the concept of "aging", as described in section 2.4.2, was implemented. When one of the heat values in a pixel reaches its upper limit, next time that pixel is traveled through in that direction, a subtraction of the other two heat values is made. This will result in a remained ratio between the heat values of each of the three travel directions.

As mentioned, the pixel size is set to 20x20m. However, dividing earth’s surface into a grid will result in squares only at the equator. With increased latitudinal distance from the equator, the squares’ longitudinal size will decreasing pixel, as illustrated in figure 2.8. To solve this problem, a correc- tion factor ρ_C_f to decrease the number of pixels in longitudinal direction, as distance from the equator is increased in north-south direction, was implemented. By decreasing the number of pixels in longitudinal direction by factor ρ_C_f, the earth is sufficiently covered with pixels of the same size regardless latitude. The fact that all pixels are the same size made the implementation less complex, and also level out performance of some calculations. The correction factor is derived below.

nrO f Pixelslongitudinal =max ρC_f

equatorial_{circum f .} size_pixel , 1

!

(3.6) where

ρC_f =y =^p1−x² (3.7)

as a result of earth being approximated as a sphere with cross sectional circle

x²+y² =r², r =1 (3.8)

(39)

and with

x= |latitude|

90 (3.9)

where

−₉₀^◦ <latitude <90^◦. (3.10)

3.2.1 Recording and Incremental Update

The system was built so that it can record data and incrementally update itself. As a vehicle travels along its route, the vehicle samples its position at 1Hz and current slope value at a frequency of 10Hz. The two data samples are then paired by matching the timestamps of the samples, and stored in an array temporarily until later usage. This is all performed by the main application in the software of the telematics ECU. Through the interface described in section 2.2.1, the slope and position data pairs are fetched by the system. The slope data is then recorded to the pixel corresponding to the position of the slope sample, by comparing the positions. If the position of the slope sample doesn’t exist in any pixel, a new pixel is created and the data is stored. In some cases, depending on pixel size and the speed of the vehicle, more than one sample in the same pixel might be taken. This will lead to an erroneous increase of heat in that pixel, which ultimately leads to a decrease in prediction accuracy. This is solved by not allowing more than one record per pixel in a row.

By looking at what previous pixels the vehicle has driven through, it is possible to estimate the vehicle’s heading through the current pixel and thus which direction sector the corresponding slope value belongs in. This way, three slope values, each of them corresponding to one of three travel direction sectors through a pixel, is stored in each pixel. To keep the slope value up to date it is updated by taking a weighted arithmetic mean with the old mean and the new slope value, as seen in eq. (3.11),

Slopenew mean = (1−α)Slope_{new value}+αSlo pe_{old mean}, n∈ [0, N] (3.11) where n is the sample number, N is the length of the moving interval in which the samples are taken and α the weight.

(40)

3.3. Route Prediction/Horizon Generation 31

Equation (3.11) was chosen because it suites the requirements of keeping the slope values in the pixels up to date. In an offroad environment roads can change radically in a short period of time, therefore the mean is not only affected by the weight, but also through a moving window with a mean of only the N most up to date slopes. It is also effective in terms of processing power needed, since it only performs a multiplication and an addition.

In certain situations, when input data might not be available for longer than a pixel length, Bresenham’s line algorithm (accorded for in section 2.1.3) can be used to estimate what pixels have been traveled through. This oc- cur, among other reasons, because the slope sensor can’t give accurate slope values during harsh accelerations and decelerations and during gear shifts.

Simply by drawing a straight line from the last known position to the current position, it is possible to linearly estimate which pixels that have been traveled through, as well as in which direction, during the time with miss- ing data. The slope for the estimated pixels is set as an average of the slope of the previous known position and the current position. This was implemented as a way to increase robustness of the system. By modifying the algorithm so that it can handle diagonal movement as well, accuracy of the algorithm can be increased.

3.3 Route Prediction/Horizon Generation

The route prediction that was implemented in this thesis is based on and inspired by the heat map based route prediction in [6] by S. Fabian.

As mentioned in section 2.4.2, the prediction is based on the heat of the pixels in a heat map, i.e. the number of travels through a pixel, for each of the three travel directions. By fetching the vehicle’s current position (at 5Hz), i.e. a latitude and longitude pair from the interface, and transform them into cartesian coordinates valid within the internal coordinate system, it is possible to locate the vehicle in the map. Then, heading is calculated by looking at the previous pixel. When the heading is known, the algorithm finds the hottest neighboring pixel, i.e. the hottest pixel with respect to all three heat map layers. In this step, the current heading is considered as well. It is assumed that the travel direction is more likely to remain approximately the same as in the previous pixel, rather than the vehicle making a sharp turn. By iterating this step, desired horizon length

(41)

is reached. Furthermore, the slope values corresponding to the hottest heat layer for the selected pixels are fetched. The position of the pixel and the fetched slope value constitute a profile spot, as defined in section 2.6.1. In the last step of the horizon generation, the travel distances between all the profile spots in the horizon is estimated by using the Haversine formula.

The resulting horizon contains several profile spots, which in its turn contain a latitude/longitude pair, a slope value and the travel distance from the previous profile spot in the horizon.

Figure 3.5: A flowchart of the implemented heat map based route prediction algorithm.

Source: [6]

In a offroad applications, e.g. in a quarry, it is common for trucks to drive on a repetitive path. Therefore, the route prediction must take this into consideration. To handle this, a limit of how many times a vehicle can drive the same path during a drive, was implemented. The limit affects the prediction algorithm when it iterates to find the next pixel to add to the horizon. If the number of visits to a pixel in the same drive exceeds the limit, it will be discarded in the horizon generation. At this point, the next horizon being generated wont contain that pixel, resulting in a different horizon.

3.3.1 Transmission of Horizon

With the horizon generation running at 1Hz, the number of available horizons quickly become large. And given the fact that a vehicle driving in

≈ 30km/h travels a distance of about eight meters during one second, a distance on which the route prediction in many cases wont change consid- erably, it would only be a waste of bandwidth to send every single horizon on CAN. Therefore, an algorithm to decide what horizons to send was implemented.

(42)

3.3. Route Prediction/Horizon Generation 33

Figure 3.6:Illustration of two subsequent horizons with matching and overlapping sections as well as the extension. H1 and H2 are separated height-wise for explanation purposes only.

At startup of the system, when there is no previous horizon available, the first available horizon is always sent over CAN. As soon as there are more than one generated horizon, the algorithm starts comparing the newest horizon to the current horizon. To be able to compare the two horizons, the matching and overlapping sections of both horizons need to be found.

This is done by finding the profile spot on the the current horizon closest to the first profile spot on the new horizon, as seen in figure 3.6, where H1 de- notes the current horizon and H2 the new horizon. Note that figure 3.6 has no y-scale and that H1 and H2 are separated height-wise for explanation purposes only. Once the profile spot on the current horizon closest to the beginning of the new horizon is found, the difference in slope value for all profile spots in the overlapping and matching sections are compared. If the value differs in more than one point, the current horizon is discarded and the new horizon is sent over CAN. However, if the slope values of the overlapping section of the horizons match, only the extension, i.e. the profile spots that extend the current horizon, are sent over CAN (see figure 3.6) The horizon that is decided to be sent over CAN is assigned a horizon id and is then put into several Profile Short messages. Each of the messages contain, among other things, two profile spots with the slope value of the spot and the distance to the previous spot. The profile short message can be sent in any frequency up to 25Hz. In the case when slope values differ on the overlapping section of the two compared horizons, the new horizon sent will be assigned a new horizon id. In the case when the overlap matches and only the extension is sent, the horizon id will remain the same. This

(43)

way, the receiving ECU will know that the profile short messages with the extension is part of the current horizon, and not a new horizon. The Position message however has higher priority, according to ADASIS, and has to be sent once every second. It contains, among other things, the position of the vehicle on the current horizon, i.e. the distance from the horizon start to the current position on the horizon.

3.4 Memory Management System

To make the system suitable for embedded use in the telematics ECU, which has limited memory capacity, the memory usage had to be optimized and controlled in some way. Several steps were taken to accomplish this and have been accorded for in previous sections. The most obvious and direct source to increased memory usage is the recording and incremental update of the map, which will increase over time. In order to be able to control the memory usage and to stop the growing map from becoming a problem, a memory management system was implemented.

The system implemented is based on the concept developed by Hazel et al. in [12] and described in section 2.5. Clearly, the requirements on such a management system depend on the hardware of the ECU in which the system will be integrated - in this case the main (RAM) memory and the secondary (flash storage) memory. As the map grows bigger, the whole map can not be fully loaded into RAM, where the system is running, at all times. By enabling for certain parts of the map to be loaded from the flash storage into RAM, only when needed, the amount of maim memory used by the map can be controlled and limited. As the vehicle moves, the part of the map loaded into RAM can be updated to cover the relevant areas needed at the moment.

At first, a database interface was implemented and a data base was created in the secondary flash storage in the ECU, where the map can be stored.

The database interface used is Sqlite because of its flexibility and speed, which makes it suitable for embedded usage. It is also the interface used by many applications in the ECU. At system startup, the vehicle’s position is fetched from the interface. By converting the latitude/longitude pair to coordinates referencing the internal cartesian coordinate system, the system can send a query to the database with the cartesian coordinates combined

(44)

3.4. Memory Management System 35

Figure 3.7:Illustration of the resulting memory management concept

into a key. This is done by the following operation:

(xTile <<16) | (0xFFFF & yTile), (3.12) which results in a 32bit unique key.

The tile in which the vehicle is located in as well as the eight surrounding tiles are then buffered into RAM, as illustrated in figure 2.10, through SQL query language. As the vehicle moves and records/updates the map, the system also checks if new map data needs to be buffered to RAM, i.e. if the vehicle are close to its current tile’s border or already has entered a new tile. If that is the case, the tiles in RAM that are no longer in use for route prediction, i.e. the tiles from which the vehicle came from, are written to the database and deleted from RAM, and new tiles in front of the vehicle are buffered into RAM. At run down of the system, all map data in RAM is written to the database so that no map data is lost. The database required for this solution was manually deployed in the flash storage of the ECU.

All the data written to the database is serialized to be able to store in an efficient way. Likewise, all the data read from the database is deserialized before it can be utilized in the system.

(45)

3.5 Main Application Interface

To end up with a system that would be possible to easily integrate in the existing main application of the telematics ECU, and which according to the initial requirements should be run through the interface of the main application, it had to be designed accordingly.

In practice, the system is run through function calls from the main application to the interface. Furthermore, the interface contains functions calls to the actual system’s different parts - recording, horizon generation, memory management etc.

The system starts up when the vehicle exits onroad terrain and enters offroad terrain. This event is flagged by the main application and triggers a function call from the main application to the interface to start up the offroad engine. The function then instantiates the main classes of the system – MapMatcher, Map, HorizonManager and MemoryManager, which are needed for the system to be able to run.

The interface was implemented in a way so that it receives navigation satellite data at a frequency of up to 5Hz, which is available from system start up. The data is fetched as strings that are called NMEA sentences, accorded for in section 2.1.2. First, the sentences are validity checked by confirming that the checksum of each of the sentences are correct. If the checksum is correct, the content of the sentence, i.e. the actual data, is checked for errors by a plausibility assessment. The plausibility assessment compare the data values, which can be e.g. latitude and longitude, to see if the values lie within in range of what is possible. The data retrieved is position (latitude and longitude), speed (knots) and heading, however a lot more data than this is available if needed.

Furthermore, to start the different parts of the system, such as the map recording/updating, route prediction, the relevant map data needs to be buffered from secondary memory to main memory, which is done by send- ing the position data, i.e. latitude and longitude, to the memory management system.

With map data of the vehicle’s surroundings in RAM, the map recording/updating and route prediction can start.

During runtime, the main application regularly fetches the truck’s current

(46)

3.5. Main Application Interface 37

Figure 3.8:A more detailed flow chart of the interface

position in the map to match it with that position’s corresponding slope value. As mentioned in section 2.6.3, the slope value is sampled at 10Hz and the position at 1Hz. This means that the actual recording of the data into the map, which is performed once the positioning within the map has been matched with slope data, takes place with some delay rather than in real time. And in the case with few slope samples accurate enough, the distance between the matched pairs of slope and position can become long. When this happens, the Bresenham line algorithm, described in the background, estimates what parts of the map that has been driven through between the samples.

The current position is also used as parameter when calling the function that generates horizons, which is done at 1Hz. As described in section 3.3, all the resulting horizons are compared to determine what to send and not to send over CAN. The profile spots of the chosen horizon are then sent to the message handler in the main application (seen in figure 3.2), which in its turn send the profile spots over CAN. However, before the messages are sent over CAN, they are placed in a message queue, with messages not only from the offroad engine, which prioritizes what messages to send over CAN, and when to send them.

(47)

(48)

Chapter 4 Result

4.1 Resulting System

The four main parts of the project, map recording/updating, horizon generation, memory management and interface to the main application, whose implementation is described in detail the previous chapter, result in the system illustrated in figure 4.1 and figure 4.2.

Figure 4.1:Overview flow chart of the resulting system

The implementation has been made as an application coded in C++. The resulting code of the application of this master thesis is classified on Scania’s terms, and will not be appended in this report. However, figure 4.3 gives

39

(49)

40 Chapter 4. Result

Figure 4.2: Overview of the main application in the telematics ECU

an overview of the program design in terms of the implementation, with the names of the different classes and how they relate.

The names of a classes have been chosen to give a clear indication of its purpose, however a brief statement follows. The logic and algorithms for the digital map is implemented in the three classes Map, Tile and Pixel. The recording of data to pixels is performed in Map and Pixel, after the actual data samples are fetched from the interface. Map also contains the algorithms for horizon generation/route prediction, which it does by finding the appropriate pixels to add to the horizon.

In Shared, the conversion of coordinates, from cartesian to wgs84 and vice versa, is performed. It also contains other common and constant variables that are used throughout the whole application.

The class Calc performs fundamental tasks, e.g. converting degrees to ra- dians and calculating distances between pixels in the cartesian coordinate system etc. Distance estimator is the class that estimates distance between wgs84 points in the map, and it does so by using the Haversine formula, as described in the background. Compared to the distance estimation in Calc, the Haversine formula takes earth curvature into consideration. DistanceEs- timator is the class used for calculating distances between profile spots in the horizon.

Map Engine with Route and Slope Prediction for Autonomous Vehicles in Offroad Applications

Examensarbete 30 hp Augusti 2017

Map Engine with Route and Slope Prediction for Autonomous Vehicles in Offroad Applications

Erik Stigenius

Abstract

Map Engine with Route and Slope Prediction for Autonomous Vehicles in Offroad Applications

Ruttplanering för autonoma fordon baserat på lutningsdata från högupplösta digitala kartor.

Glossary

Contents

Chapter 1 Introduction

1.1 Problem Definition

1.2 Purpose and Objectives

1.3 Delimitations

1.4 Methodology

Chapter 2 Background

2.1 Theory

2.1.1 WGS84 and Distance Calculation

2.1.2 GNSS Positioning and NMEA sentences

2.1.3 Bresenham’s Line Algorithm

2.1.4 Weighted Arithmetic Mean

∑

2.2 Telematics ECU

2.2.1 Software

2.3 Mapping

2.3.1 Raster Representation

2.3.2 Vector Representation

2.3.3 Coordinate Mapping

2.4 Route and Slope Prediction

2.4.1 Directional Based Route Prediction

2.4.2 Heat Map Based Route Prediction

2.5 Memory Management

2.6 Horizon Generation and Transmission

2.6.1 ADASISv2 Protocol

2.6.2 Horizon Length

2.6.3 Road Slope Estimation

Chapter 3

Implementation

3.1 System Overview

3.2 Map

3.2.1 Recording and Incremental Update

3.3 Route Prediction/Horizon Generation

3.3.1 Transmission of Horizon

3.4 Memory Management System

3.5 Main Application Interface

Chapter 4 Result

4.1 Resulting System