IN
DEGREE PROJECT
COMPUTER SCIENCE AND ENGINEERING,
SECOND CYCLE, 30 CREDITS
,
STOCKHOLM SWEDEN 2016
Enhancing Parking Behavior
Detection
TEODORA ANITOAEI
Enhancing Parking Behavior Detection
Master of Science - Major Thesis
Teodora Anitoaei
Supervisor: Gabriel Hjort Blindell
Examiner: Christian Schulte
Stockholm 31st October 2016
ICT Innovation - Embedded Systems
School of Information and Communication Technology
KTH Royal Institute of Technology
Abstract
A review of navigation systems nowadays shows that new features are required in the automotive field. One such feature is suggesting a parking space within a positioning system. In the new global context of navigation, finding a parking place has become a central issue for all drivers. The research question for this study is what happens when you get to the destination or when you don’t need to use a GPS to arrive to your destination? This thesis has two major purposes: (1) to investigate an efficient solution for detecting the parking behavior of a moving car; (2) to implement and integrate an environment-friendly solution for HERE in a way that would give the company a competitive edge.
By examining only the latitude and longitude from all the input GPS data received in a navigation system, the author defines the best configuration for a parking detection algorithm. Once the best configuration was found, an imple-mentation was proposed. An extensive series of tests has been carried out on the final implementation. Data for tests was obtained using internal tools from HERE for producing di↵erent testing routes as navigation files (.nmea files). Creating the input files manually o↵ers flexibility and gives the opportunity to touch all the unexpected behaviors, knowing the expected result in any case.
The results obtained from the analysis of the algorithm are encouraging. It has been shown that the configuration chosen for implementation is cheap and e↵ective in predicting parking behavior. In conclusion, the implementa-tion of the algorithm was successfully integrated with the existing HERE SDK. The new feature will be available for the following three automotive companies: Audi, BMW, and Daimler. The algorithm is designed such that it can be easily extended and improved. Future work might include adding parameters that should be adjustable by the user or client like speed of the car.
Sammanfattning
En genomg˚ang av nutida navigationssystem visar att nya funktioner kr¨avs f¨or fordonsomr˚adet. En s˚adan funktion ¨ar att f¨oresl˚a en parkeringsplats inom ett positioneringssystem. I det nya globala sammanhanget f¨or navigering har prob-lemet att hitta en pa parkeringsplats blivit en central fr˚aga f¨or alla f¨orare. Fr˚agest¨allningen f¨or denna studie ¨ar vad som h¨ander n¨ar du kommer till desti-nationen eller n¨ar du inte beh¨over anv¨anda en GPS f¨or att komma fram till din destination? Denna avhandling har tv˚a huvudsakliga syften: (1) att unders¨oka en e↵ektiv l¨osning f¨or detektering av parkeringsbeteende hos en bil som r¨or sig; (2) att genomf¨ora och integrera en milj¨ov¨anlig l¨osning f¨or HERE p˚a ett s¨att som skulle ge bolaget en konkurrensf¨ordel.
Genom att endast unders¨oka latitud och longitud fr˚an all GPS-indata som mottags i ett navigationssystem definierar f¨orfattaren den b¨asta konfiguratio-nen f¨or en parkeringdetekteringsalgoritm. N¨ar v¨al den b¨asta konfiguratiokonfiguratio-nen funnits f¨oreslots ett genomf¨orande. En omfattande serie tester har utf¨orts p˚a det slutliga genomf¨orandet. Data f¨or prov erh¨olls med hj¨alp av interna verktyg fr˚an HERE f¨or att producera olika provv¨agar som navigationsfiler (.nmea filer). Att skapa indatafiler manuellt erbjuder flexibilitet och ger m¨ojlighet att vidr¨ora alla ov¨antade beteenden, f¨or att veta det f¨orv¨antade resultatet i vilket fall som helst.
De resultat som erh˚allits fr˚an analysen av algoritmen ¨ar uppmuntrande. Det har visats att konfigurationen som valts f¨or genomf¨orandet ¨ar billig och e↵ektiv i att f¨oruts¨aga parkeringsbeteende. Sammanfattningsvis har genomf¨orandet av algoritmen framg˚angsrikt integrerats med den befintliga HERE SDK:n. Den nya funktionen kommer att finnas tillg¨anglig f¨or f¨oljande tre bilf¨oretag: Audi, BMW och Daimler. Algoritmen ¨ar utformad s˚a att den l¨att kan utvidgas och f¨orb¨attras. Framtida arbete kan omfatta att l¨agga till parametrar som b¨or vara inst¨allningsbara av anv¨andaren eller kunden som till exmpel hastigheten p˚a bilen.
Acknowledgments
I would like to express my gratitude to my examiner Christian Schulte and to my supervisor Gabriel Hjort Blindell for all the useful comments, remarks and engagement through the learning process of this master thesis. Furthermore I would like to thank the software company HERE for introducing me to the topic as well for the support on the way. I would like to thank my loved ones, who have supported me throughout entire process, both by keeping me harmonious and helping me putting pieces together.
List of Acronyms and
Abbreviations
This document requires readers to be familiar with terms and concepts. For clarity we summarize some of these terms and give a short description of them before presenting them in next sections.
GPS Global Positioning System SDK Software Development Kit
NMEA National Marine Electronics Association GPX Global Positioning System Exchange Format JSON JavaScript Object Notation
PDA Parking Detector Algorithm GNSS Global Navigation Satellite System DT Driven Track OT Optimal Track R Ratio C Cost T Threshold TT Target Tracking
GPSD Global Positioning System Daemon API Application Program Interface APP Application Layer
TDD Test Driven Development
HCVD Hybrid Components and Vehicle Data ETA Estimated Time of Arrival
Contents
1 Introduction 1 1.1 Problem . . . 1 1.2 Problem Statement . . . 2 1.3 Goals . . . 2 1.4 Purpose . . . 21.5 Ethics and Sustainability . . . 2
1.6 Research Methodology . . . 3
1.7 Delimitations . . . 3
1.8 Motivation . . . 3
1.9 Structure of the thesis . . . 3
1.10 About HERE . . . 3 2 Background 5 2.1 Navigation Systems . . . 5 2.1.1 NMEA files . . . 6 2.1.2 GPX files . . . 7 2.1.3 JSON files . . . 9 2.1.4 GPSD . . . 9 2.2 Navigation Formulas . . . 10 2.2.1 Haversine Formula . . . 10
2.2.2 Law of Cosines Formula . . . 11
2.2.3 Equirectangular Approximation Formula . . . 12
2.3 Related Work . . . 13
3 Method 15 3.1 Parking Detection Algorithm (PDA) . . . 15
3.2 Design . . . 19
3.3 Implementation . . . 21
3.4 Testing . . . 23
4 Results and Analysis 29 4.1 Notations and Values . . . 29
4.2 Results . . . 33
4.3 Reliability and Validity . . . 34
4.4 Discussion of classification results and error cases . . . 34
4.4.1 False positives . . . 34
5 Conclusions 39 5.1 Results . . . 39 5.2 Implementation . . . 39 5.3 Recommendations . . . 40 A Final Results for Haversine Haversine configurations 41 B Configurations Graphs Comparisons 49
C PDA Code 53
D PDA Integration Test 67
List of Figures
2.1 Waypoints, Routes, and Tracks recorded by GPS receivers . . . . 8
2.2 GPSD - Dataflow View . . . 9
2.3 Spherical triangle . . . 10
2.4 Comparison between Law of Cosines and Haversine Formulas . . 13
2.5 Ratios of Law of Cosines and Haversine Formula . . . 13
3.1 Parking Detection Algorithm Flow . . . 16
3.2 CarloControlPanel User Interface . . . 17
3.3 Example of input file - Visualization . . . 18
3.4 Driven track vs. Optimal track . . . 19
3.5 Carlo Package Overview . . . 20
3.6 CarloControlPanel Tool Package . . . 21
3.7 Navcore Components . . . 22
3.8 PDA Components . . . 23
3.9 UML Diagram for Parking Detector Algorithm . . . 25
3.10 Sequence Diagram for Parking Detector Algorithm . . . 26
3.11 PDA Flow . . . 27
4.1 Algorithm Configurations . . . 30
4.2 Algorithm Test Files . . . 31
4.3 Red Segment - Track Start Problems . . . 35
4.4 Red Segment - Map Matching Problems . . . 35
4.5 Red Segment - Wrong Annotation . . . 36
4.6 Red Segment - Unknown . . . 36
B.1 Haversine vs HereAPI - 400m . . . 49
B.2 Haversine vs HereAPI - 500m . . . 50
B.3 Haversine vs HereAPI - 600m . . . 50
B.4 Haversine vs HereAPI - 700m . . . 51
List of Tables
4.1 Configuration 1 for test file 1 . . . 33 A.1 Final Results for algorithm configuration ”Haversine Haversine 400 800 1200”
and di↵erent parameters . . . 41
A.2 Final Results for algorithm configuration ”Haversine Haversine 500 1000 1500” and di↵erent parameters . . . 42
A.3 Final Results for algorithm configuration ”Haversine Haversine 600 1200 1800” and di↵erent parameters . . . 44
A.4 Final Results for algorithm configuration ”Haversine Haversine 700 1400 2100” and di↵erent parameters . . . 45
A.5 Final Results for algorithm configuration ”Haversine Haversine 800 1600 2400” and di↵erent parameters . . . 46
List of Code
2.1 $GPGGA sentence decoding . . . 6
2.2 GPX File Example . . . 7
2.3 Haversine Formula implemented in C++ . . . 10
2.4 Equirectangular Formula implemented in Python . . . 12
3.1 SimpleClassifier implemented in Python . . . 16
C.1 PDA API header implemented in C++ . . . 53
C.2 PDA API source code implemented in C++ . . . 55
C.3 PDA Implementation Header in C++ . . . 57
C.4 PDA Implementation Source Code in C++ . . . 59
Chapter 1
Introduction
This chapter first gives a short introduction into the general problem and the problem statement, followed by an overview of the goals, purpose, methodology, delimitations and motivation of this study. The last part is concerned with the outline for the thesis.
1.1
Problem
Parking management is a common condition which has considerable impact on people driving every day. Parking management is frequently described as: search time and cost for parking spaces, parking revenue, and traffic congestion. Evidence suggests that distance wasted on detecting the available parking spaces is more than 4 kilometers per parking attempt, so an average of 10 minutes [24]. Drivers will keep on circling the parking area until they found an empty parking spot. This problem usually occurs in urban areas, where the number of vehicles is higher as compared to the availability of parking spaces. These ine↵ective conditions happened because of the lack of technology, available on the market today, for detecting parking behavior.
In recent years, there has been an increasing amount of problems on finding a parking space, especially in the big cities. Recent research explains that over 30% of the traffic in the city centers of medium and larger cities is due to people looking for a parking space [2]. Creating parking places makes it more attractive to drive, so streets are at their capacity, worsening traffic and delaying transit service. Lack of parking spaces not only generates traffic, but also degrades the quality of neighborhoods. On one hand, there are so many cars that is nearly impossible to build great urban places. On the other hand, it has conclusively been shown that parking makes housing less a↵ordable, because a parking space adds a significant amount of money to the cost of an apartment or a house [2]. According to studies done by Siemens [23], it can be said that every car driver wastes on average 100 hours a year looking for a parking space and causes one third of traffic, especially in city centers and around 30 percent of drivers are searching for a parking space in overcrowded city centers. Every year, the distance covered in each district of a big city is equivalent to 14 trips around the world [24].
1.2
Problem Statement
Thanks to technologies like smart-phones, GPS systems, or in-car navigation systems, finding the way has never been easier with access to traffic conditions, travel time, and directions. The research question for this study is about what happens when you get to the destination or when you don’t need to use a GPS to arrive to your destination? In the new global context, finding a parking place has become a central issue for all drivers. Despite this, directions skip over this last, very important step: suggesting a parking space.
Parking is an important aspect of navigation. Several attempts on navigation tools nowadays are adding the necessary condition of knowing the destination. Extensive research has been carried out on car navigation systems that o↵ers assistance in parking when the driver approaches the predicted destination. However, the fact is that most of the drivers don’t need directions to go home or to work, but no study exists which detects parking search behavior if the destination is unknown.
1.3
Goals
The primary goals of this thesis project are:
1. Present a cheap and efficient algorithm for predicting parking space search behavior;
2. Evaluate all the possible configurations of the algorithm in order to choose the best one for the final application;
3. Design and implement the best configuration to be integrated in the HERE SDK.
1.4
Purpose
The results from this thesis and the actual implementation will be available in the new features of 2017 for the following three automotive companies: Audi, BMW, and Daimler. The proposed solution is integrated in the HERE SDK and should be delivered as an integrated component from the software company. The findings are already patented by HERE and the research should make an important contribution to the field of automotive navigation.
1.5
Ethics and Sustainability
The proposed solution shall protect the user’s privacy by: not requiring a final destination point; not storing more than two kilometers of the traveled route during software runtime and discarding them at shutdown; not collecting or disclosing user’s personal information to any external entities.
The chosen implementation shall lead the way to a sustainable future by: reducing the number of kilometers traveled while searching for a parking place; reducing the traffic in crowded cities; keeping the car’s used resources to a minimum;
1.6
Research Methodology
This thesis has adopted the quantitative research method, as the focus is on the evaluation of all possible configurations for the algorithm proposed as a solution for predicting space search behavior.
1.7
Delimitations
A primary concern of this project is detecting parking search behavior without knowing the destination. Traditionally, this kind of behavior might still be inferred from driving patterns. A full discussion of which criteria might be available and how well they may predict parking search behavior lies beyond the scope of this study. The reader should bear in mind that the study is based on examining one research question: how to detect parking search behavior only knowing the traveled GPS trace, more specific only pairs of latitude and longitude, logged in the system.
1.8
Motivation
This project was conceived during my time working for HERE - a software com-pany owned by leading automotive companies: Audi, BMW, and Daimler (and was formerly owned by Nokia, until December 2015) [22] that brings together mapping and location businesses under one brand. HERE captures location content such as road networks, buildings, parks and traffic patterns [15].
My main reason for choosing this topic is based on the work developed in the same area with three di↵erent roles that I played in the company: working student, intern student, and master thesis student, in a time frame of one year.
1.9
Structure of the thesis
The thesis will be organized as a one-person project. The present research explores the current findings from HERE about parking search behavior and investigates only one of the features, creating an algorithm and discovering the best parameters to run the final application.
Thesis Outline: Chapter 1 introduces the problem and gives an overview of the context of this thesis. Chapter 2 further describes the idea of this thesis and provides the information needed to understand the problem and solution. Related work and competing solutions are also discussed. The goals and the methods of this study are discussed in chapter 3. Chapter 4 provides the results obtained with the methods presented in chapter 3 and an analysis of the work, explaining how it can be used and extended. Finally, chapter 5 evaluates the goals of this study and gives final remarks.
1.10
About HERE
HERE is a web mapping service developed originally in Navteq, an American company founded in 1985. The company was acquired by Nokia (a Finnish
telecommunication firm). It o↵ers street maps, satellite imagery, real-time traffic conditions, route planning for traveling by foot, bicycle, car and pub-lic transportation. It then sells or pub-licenses that mapping content, along with navigation services and location solutions to other businesses such as Alpine, Garmin, BMW, Oracle and Amazon.com. In addition, HERE provides platform services to many mobile devices operating systems, online or o✏ine. It delivers location services through HERE applications, provides solutions for GIS and government clients and powers major mapping providers, such as Bing, Face-book and (formerly) Yahoo! Maps [7]. HERE has maps in nearly 200 countries, o↵ers voice guided navigation in 94 languages, provides live traffic information in 33 countries and has indoor maps available for about 49,000 unique buildings in 45 countries [16]. As of December 2015 the company has more than 6500 employees.
Chapter 2
Background
This chapter provides information about the navigation systems key-terms that the reader should have to fully comprehend the rest of this thesis. It will first give a high-level overview of navigation systems and explain what it is meant when positioning is mentioned. After defining these terms, a high-level overview of navigation tools and applications is given.
2.1
Navigation Systems
Navigation is the science that focuses on the process of determining position, location, distance traveled, and course to a known destination. In other words, monitoring and controlling the movement of a craft or vehicle from one place to another. This dissertation aims to unravel one of the mysteries surrounding automotive navigation systems: detecting parking search behavior of a moving car.
In general, discussing about an automotive navigation system means a sys-tem based on the Global Positioning Syssys-tem (GPS), including a GPS receiver and audio/video (AV) components designed for a specific purpose such as a car-based/hand-held device or a smart-phone/tablet application. GPS is a satellite-based system used for locating any positions on the globe. The system is operated by the U.S. Department of Defense (DoD), NAVSTAR (NAViga-tion Satellite Timing and Ranging). GPS provides in real-time and continuous (24 hours/day) a 3-dimensional positioning, navigation and timing worldwide. Any person with a GPS receiver can access the system, and it can be used for any application that requires location coordinates (coordinating information from three or four satellite signals). That location includes the position of the satellite and the precise time of transmission. Having three signals, any 2D position can be found on earth; additional satellite signals make it possible to find altitude. GPS technology works in almost any condition and is accurate to within 3-15 meters, depending on the number of signals received, the spread of satellites in the sky and the technologies used in the receiver [13].
2.1.1
NMEA files
One of the input formats used in this study is NMEA data. NMEA is an acronym for the National Marine Electronics Association. An interesting fact is that NMEA existed well before GPS was invented. According to the NMEA official website, the association was formed in late ’50s by a group of electronic dealers. The purpose was to create better communications between the nav-igation hardware and software. Nowadays in the world of GPS, NMEA is a standard data format supported by all GPS manufacturers, like ASCII is the standard for digital computer characters in the computer world.
NMEA can play an important role because it has the power to give equip-ment users the ability to mix and match hardware and software. Each GPS receiver is di↵erent, and with NMEA-formatted GPS data is easier for soft-ware developers to write softsoft-ware for a wide variety of GPS receivers instead of having to write a custom interface for each. A good example is VisualGPS (free software), which accepts NMEA-formatted data from any GPS receiver and graphically displays it. Not having a standard such as NMEA, it would be time consuming and expensive to write and maintain such a tool [5].
NMEA 0183 replaces the earlier NMEA 0180 and NMEA 0182 standards and is a combined electrical and data specification for communication between electronics (echo sounder, sonars, anemometer, gyrocompass, autopilot, GPS receivers). In marine applications, it is slowly being phased out in favor of the newer NMEA 2000 standard. The NMEA 0183 standard is a serial communi-cations protocol, that uses a simple ASCII, defining how data are transmitted in a ”sentence” from one ”talker” to multiple ”listeners”. A talker can have an unidirectional conversation with an unlimited number of listeners, and with multiplexers, multiple sensors can talk to a single computer port. At the ap-plication layer, the standard also defines the contents of each sentence type, so that all listeners can parse messages accurately [21].
All messages are transmitted in the form of sentences. In these sentences are allowed only printable ASCII characters, plus CR (carriage return) and LF (line feed). Each sentence starts with a ”$” sign and ends with < CR >< LF >. However, there are a few NMEA messages/sentences and that makes NMEA a bit confusing. Just like there are all kinds of GPS receivers with di↵erent capabilities, there are many di↵erent types of NMEA messages with di↵erent capabilities. In addition, NMEA data can be transmitted via di↵erent types of communications interfaces such as RS-232, USB, Bluetooth, Wi-Fi, UHF, etc. [9]. For this study, only ”GPGGA” sentences are used and a decoding example is presented in 2.1 [8]. The GGA is a basic GPS NMEA message with essential fixed data which provide 3D location and accuracy information, including latitude and longitude. There are alternative and companion NMEA messages that provide similar or additional information.
1 $GPGGA, 1 2 3 5 1 9 , 4 8 0 7 . 0 3 8 ,N, 0 1 1 3 1 . 0 0 0 , E , 1 , 0 8 , 0 . 9 , 5 4 5 . 4 ,M, 4 6 . 9 ,M, ,⇤ 4 7 2
3 Where : 4
5 GGA G l o b a l P o s i t i o n i n g System Fix Data 6 123519 Fix t a k e n a t 1 2 : 3 5 : 1 9 UTC
7 4 8 0 7 . 0 3 8 ,N L a t i t u d e 48 deg 0 7 . 0 3 8 ’ N 8 0 1 1 3 1 . 0 0 0 ,E L o n g i t u d e 11 deg 3 1 . 0 0 0 ’ E 9 1 Fix q u a l i t y :
11 1 = GPS f i x ( SPS ) 12 2 = DGPS f i x 13 3 = PPS f i x
14 4 = Real Time Kinematic 15 5 = F l o a t RTK 16 6 = e s t i m a t e d ( dead r e c k o n i n g ) ( 2 . 3 f e a t u r e ) 17 7 = Manual i n p u t mode 18 8 = S i m u l a t i o n mode 19 08 Number o f s a t e l l i t e s b e i n g t r a c k e d 20 0 . 9 H o r i z o n t a l d i l u t i o n o f p o s i t i o n
21 5 4 5 . 4 ,M A l t i t u d e , Meters , above mean s e a l e v e l 22 4 6 . 9 ,M H e i g h t o f g e o i d ( mean s e a l e v e l ) 23 above WGS84 e l l i p s o i d
24 ( empty f i e l d ) time i n s e c o n d s s i n c e l a s t DGPS update 25 ( empty f i e l d ) DGPS s t a t i o n ID number
26 ⇤47 t h e checksum data , a l w a y s b e g i n s with ⇤
Listing 2.1: $GPGGA sentence decoding
2.1.2
GPX files
GPX or GPS Exchange Format is a light-weight XML document designed as a common GPS data format for the interchange data (way-points, routes, and tracks) between softwares and Web services on the Internet. Location data (and optionally elevation, time, and other information) is stored in tags and can be exchanged between GPS devices and applications. Common software appli-cations for the data include viewing tracks projected on various map sources, annotating maps, and geo-tagging photographs based on the location they were taken. Latitude and longitude are expressed in decimal degrees using the World Geodetic System 1984 (WGS 84) datum [20]. Elevation is recorded in meters. Dates and times respect Coordinated Universal Time (UTC) using ISO 8601 format [17].
The advantages of using GPX file: allows to exchange data with a growing list of programs for Windows, MacOS, Linux; can be transformed into other file formats using a simple converter software or website; it is based on the XML standard, thus there are numerous tools able to read this format; makes it easy for anyone on the web to develop new features for di↵erent applications.
From figure 2.1 [4] one can easily understand the di↵erences between way-points, routes and tracks. Waypoints are a pair of coordinates that identify a point in physical space, tracks are a record of where a device/person has been, and routes are suggestions and estimations about where they might go. For ex-ample, each point in a track has a time stamp (because is recording where and when it was there), but the points in a route are unlikely to have timestamps other than estimated trip duration, because a route is a suggestion which is possible that nobody ever have traveled [4]. Listing 2.2 [4] represents a simple example of GPX file produced by a Garmin Oregon 400t hand-held GPS unit.
1 <?xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF 8” s t a n d a l o n e=” no ” ?> 2
3 <GPX xmlns=” h t t p : //www. t o p o g r a f i x . com/GPX/1/1 ” xmlns:GPXx=” h t t p : //
www. garmin . com/ xmlschemas / GPXExtensions / v3 ” xmlns:GPXtpx=” h t t p : //www. garmin . com/ xmlschemas / T r a c k P o i n t E x t e n s i o n / v1 ” c r e a t o r=” Oregon 400 t ” v e r s i o n=” 1 . 1 ” x m l n s : x s i=” h t t p : //www. w3 . o r g /2001/ XMLSchema i n s t a n c e ” x s i : s c h e m a L o c a t i o n=” h t t p : //www. t o p o g r a f i x . com/GPX/1/1 h t t p : //www. t o p o g r a f i x . com/GPX/1/1/GPX. xsd h t t p : //
Figure 2.1: Waypoints, Routes, and Tracks recorded by GPS receivers
www. garmin . com/ xmlschemas / GPXExtensions / v3 h t t p : //www. garmin . com/ xmlschemas / GPXExtensionsv3 . xsd h t t p : //www. garmin . com/ xmlschemas / T r a c k P o i n t E x t e n s i o n / v1 h t t p : //www. garmin . com/ xmlschemas / T r a c k P o i n t E x t e n s i o n v 1 . xsd ”> 4 <metadata> 5 <l i n k h r e f=” h t t p : //www. garmin . com”> 6 <t e x t>Garmin I n t e r n a t i o n a l 7 </ t e x t> 8 </ l i n k> 9 <time>2009 10 17 T 2 2 : 5 8 : 4 3 Z 10 </ time> 11 </ metadata> 12 <t r k> 13 <name>Example GPX Document 14 </name> 15 <t r k s e g> 16 <t r k p t l a t=” 4 7 . 6 4 4 5 4 8 ” l o n=” 122.326897 ”> 17 < e l e>4 . 4 6</ e l e> 18 <time>2009 10 17 T 1 8 : 3 7 : 2 6 Z</ time> 19 </ t r k p t> 20 <t r k p t l a t=” 4 7 . 6 4 4 5 4 8 ” l o n=” 122.326897 ”> 21 < e l e>4 . 9 4</ e l e> 22 <time>2009 10 17 T 1 8 : 3 7 : 3 1 Z</ time> 23 </ t r k p t> 24 <t r k p t l a t=” 4 7 . 6 4 4 5 4 8 ” l o n=” 122.326897 ”> 25 < e l e>6 . 8 7</ e l e> 26 <time>2009 10 17 T 1 8 : 3 7 : 3 4 Z</ time> 27 </ t r k p t> 28 </ t r k s e g> 29 </ t r k> 30 </GPX>
2.1.3
JSON files
JavaScript Object Notation [25] or JSON, is a minimal, open-standard format that uses human-readable text to transmit data objects consisting of attribute value pairs. It is used primarily to transmit data between a server and a web application, largely replacing XML which is used by AJAX. JSON is a language-independent data format. It derives from JavaScript, but nowadays, code to generate and parse JSON-formatted data is available in almost all programming languages. The JSON filename extension is usually JSON.
2.1.4
GPSD
Global Positioning System Daemon or GPSD [11], is a free software, daemon (computer program that runs as a background process) that receives data from a GPS receiver, and provides the data back to multiple applications such GPS navigation software. The literature has emphasized the importance of GPSD in recent generations of manned aircraft, marine navigation systems, and military vehicles. GPSD is everywhere in mobile embedded systems. It underlies the map service on Android phones. So it provides a unified interface to receivers of di↵erent types, allowing concurrent access by multiple tools. GPSD manages a collection of sensors and makes logs from all of them available as a JSON file on a TCP/IP port.
Figure 2.2: GPSD - Dataflow View
Figure 2.2 [10] shows the GPSD’s architecture from a data-flow point of view. GPSD launches in a loop waiting for input. The source can be 1. clients making requests over a TCP/IP port; 2. navigation sensors connected via serial devices; 3. control socket used by hot-plug scripts and some configuration tools; or 4. servers issuing periodic di↵erential-GPS correction updates (handled as navigation sensors) [10]. If data comes in from a navigation sensor, it is given to the packet sni↵er. Packet sni↵er is a finite-state machine that works like the lexical analyzer in a compiler. The packet sni↵er’s job is to accumulate data from each port, deciding when it has accumulated a packet of a known type. A packet may contain di↵erent data, but the packet sni↵er does not know and does not care about the content of the packet. It only tells the core library when it has one and passes back the payload and the packet type. The core library has the responsibility to hand the packet to the driver associated with its type. The driver’s will mine data out of the packet payload into a session structure and decide for the multiplexer layer what kind of data it is. Part of this decision is an indication that the daemon has accumulated enough data to ship a report to its clients. After a data read from a sensor device, it means we’ve seen the end of a packet, the end of a packet group (which may be one or more packets), and the data in the device’s session structure should be passed to one of the exporters [10].
2.2
Navigation Formulas
2.2.1
Haversine Formula
Haversine Formula is a key equation in navigation. It is computing the shortest distance between two points on the surface of a sphere, also known as great-circle distance or orthodromic distance, from their longitudes and latitudes. The equation is a particular case of a more general formula in spherical trigonom-etry called ”The Law of Haversines”, relating the sides and angles of spherical triangles [6]. The name for the formula is following from Haversine function, given by: haversin(✓) = sin2(✓
2).
Figure 2.3: Spherical triangle
Consider the unit sphere from the figure 2.3, with the defined triangle by the orthodromic distances connecting points u, v, and w on the surface of the sphere. Given that the lengths of these three sides are: a - from u to v, b - from u to w, c - from v to w, and the angle of the corner opposite c is C, then the law of haversines is:
hav(c) = hav(a b) + sin(a)⇤ sin(b) ⇤ hav(C)
The sphere is a unit one, that means the lengths a, b, and c are equal to the angles, in radians, subtended by those sides from the center of the sphere. So if one simply considers the special case where u is the north pole, while v and w are the two points whose separation d is to be determined, the Haversine formula is obtained.
Listing 2.3 proves exactly how this thesis is using the Haversine Formula and the Earth radius chosen for all the projects inside HERE AUTO SDK.
1 c o n s t d o u b l e RADIANS PER DEGREE = 0 . 0 1 7 4 5 3 2 9 2 5 1 9 9 4 3 2 9 5 7 6 9 2 ; 2 c o n s t d o u b l e EARTH RADIUS METERS = 6 3 7 1 0 0 0 . 0 ;
3 /⇤
4 ⇤ Computes the d i s t a n c e between two g e o p o i n t s on the e a r t h ’ s 5 ⇤ s u r f a c e u s i n g the H a v e r si n e formula . The c u r v a t u r e o f the e a r t h 6 ⇤ i s taken i n t o account . The a l t i t u d e o f the p o i n t s i s i g n o r e d . 7 ⇤
8 ⇤ @param p1 F i r s t c o o r d i n a t e . 9 ⇤ @param p2 Second c o o r d i n a t e .
10 ⇤ @return The d i s t a n c e i n meters between p1 and p2 , 11 ⇤ or 0 i f e i t h e r p o i n t i s i n v a l i d .
12 ⇤/ 13 d o u b l e 14 d i s t m e t e r s (c o n s t G e o C o o r d i n a t e s& p1 ,c o n s t G e o C o o r d i n a t e s& p2 ) 15 { 16 i f( ! p1 . i s v a l i d ( ) | | ! p2 . i s v a l i d ( ) ) 17 { 18 r e t u r n 0 ; 19 } 20
21 c o n s t d o u b l e p 1 l a t r a d i a n s = p1 . l a t i t u d e⇤RADIANS PER DEGREE; 22 c o n s t d o u b l e p 2 l a t r a d i a n s = p2 . l a t i t u d e⇤RADIANS PER DEGREE; 23 c o n s t d o u b l e p 1 l n g r a d i a n s = p1 . l o n g i t u d e⇤RADIANS PER DEGREE; 24 c o n s t d o u b l e p 2 l n g r a d i a n s = p2 . l o n g i t u d e⇤RADIANS PER DEGREE; 25 26 c o n s t d o u b l e s i n h a l f d l a t = 27 s i n ( ( p 1 l a t r a d i a n s p 2 l a t r a d i a n s ) / 2 ) ; 28 c o n s t d o u b l e s i n h a l f d l n g = 29 s i n ( ( p 1 l n g r a d i a n s p 2 l n g r a d i a n s ) / 2 ) ; 30 c o n s t d o u b l e a = s i n h a l f d l a t⇤ s i n h a l f d l a t + 31 c o s ( p 1 l a t r a d i a n s )⇤ c o s ( p 2 l a t r a d i a n s ) ⇤ 32 s i n h a l f d l n g⇤ s i n h a l f d l n g ; 33 c o n s t d o u b l e c = 2⇤ a s i n ( s t d : : min ( 1 . 0 , s q r t ( a ) ) ) ; 34
35 r e t u r n EARTH RADIUS METERS ⇤ c ; 36 }
Listing 2.3: Haversine Formula implemented in C++
However, the formula is limited when applied to the Earth, because the Earth is not a perfect sphere, having a radius R which varies from 6356.78 km at the Poles to 6378.14 km at the Equator. The formula gives only an approximate result and there are small corrections, typically on the order of 0.1%, because of this slight ellipticity of the planet.
Haversine formula:
a = sin2( '/2) + cos '1⇤ cos '2⇤ sin2( /2)
c = 2⇤ arctan 2(p2
(a),p2
(1a)) d = R⇤ c
, where ' is latitude, is longitude, ' is di↵erence in latitude, is di↵erence in longitude , R is earths radius (mean radius = 6371 km); the angles need to be in radians to pass to trigonometric functions.
2.2.2
Law of Cosines Formula
According to this source [19], it is discussed that the Haversine Formula is con-ditioned for numerical computation, even for small distances. A better solution are calculations based on the spherical law of cosines. In fact, when Sinnott published the Haversine formula, computational precision was limited. Nowa-days, most modern computers and languages use IEEE 754 64-bit floating-point numbers, which provide 15 significant figures of precision. With this preci-sion, by the source’s estimations, the simple spherical law of cosines formula (cos c = cos a⇤cos b+sin a⇤sin b⇤cos C) gives results down to distances as small as a few meters on the Earths surface.
Law of Cosines:
2.2.3
Equirectangular Approximation Formula
The arguments presented above makes the simpler law of cosines a reasonable 1-line alternative to the Haversine formula. On the other hand, the choice may be driven by programming language, processor, coding context, available trigonometric functions in di↵erent languages, thus for very small distances an Equirectangular Approximation Formula might be more suitable, only if the performance is an issue and accuracy is not important. It is interesting to note that for small distances Pythagoras theorem can be used on an equirectangular projection: x = ⇤ ⇤ cos 'm y = ⇤ ' d = Rp2 (x2+ y2) 1 d e f e q u i r e c t a n g u l a r d i s t a n c e ( s t a r t p o i n t , e n d p o i n t ) : 2 # two p a i r s o f l a t i t u d e and l o n g i t u d e 3 l a t 1 , l o n 1 = s t a r t p o i n t 4 l a t 2 , l o n 2 = e n d p o i n t 5
6 x = math . r a d i a n s ( l o n 2 l o n 1 ) ⇤ math . c o s ( 0 . 5 ⇤ math . r a d i a n s ( l a t 2 + l a t 1 ) )
7 y = math . r a d i a n s ( l a t 2 l a t 1 ) 8
9 # a s p h e r i c a l d i s t a n c e between t h e two p o i n t s 10 r e t u r n R ⇤ math . s q r t ( x⇤x + y⇤y )
Listing 2.4: Equirectangular Formula implemented in Python
The problem with all these three formulas is related with computer arith-metic, not mathematics. At HERE it was decided that only Haversine formula is used, because the precision is less important. The basic factors to consider when discussing about these three are: a) a radian on the earth spans almost 107 meters; b) the cosine function for arguments x close to 0 is approximately
equal to 1 x2/2; c) double-precision floating point has 15 decimal digits of
precision.
Considering b) and c), it is implied that when x is near 1 meter, or 10 7
radians, almost all precision is lost: 1 (10 7)2= 1 10 14 is a computation
in which the first 14 of the 15 significant digits are all canceled, with just one digit to represent the result. Flipping this around, using inverse cosine (arc-cos) means that computing arccos for angles that correspond to meter-length distances cannot be done with any meaningful accuracy. Similar considerations suggest one shall avoid using the inverse cosine if distances less than a few hun-dred meters are involved, depending on how much precision one’s willing to lose. In Law-of-cosines, arccos is used to convert an angle to a distance. That role is played by arctan2 in the Haversine formula. The tangent of a small an-gle x is approximately equal to x itself. Consequently the inverse tangent of a number, being approximately that number, is computed essentially with no loss in precision. Finally, this is the reason why the Haversine formula, although mathematically equivalent to the law of cosines formula, is superior for small distances (1 meter or less).
According to [14], in the figure 2.4 is a comparison of the two formulas using 100 random point-pairs on the globe (using double-precision calculations). For distances less than about 0.5 meters, the two formulas diverge and for distances
above 0.5 meters they tend to agree. To show how closely they agree, the figure 2.5 represents a plot with the ratios of the Law of Cosines : Haversine Formula results for another 100 random point pairs, with their latitudes and longitudes randomly di↵ering by up to 5 meters. This shows that the Law of cosines formula is good to 3-4 decimal places once the distance exceeds 5-10 meters. The number of decimal places of accuracy increases quadratically; thus at 50-100 meters (one order of magnitude) you get 5-6 decimal places accuracy (two orders of magnitude); at 500-1000 meters you get 7-8 decimal places, and so on.
Figure 2.4: Comparison between Law of Cosines and Haversine Formulas
Figure 2.5: Ratios of Law of Cosines and Haversine Formula
2.3
Related Work
Very little was found in the literature on the question of determining the behav-ior of a moving car. An important competitor on the software side is Siemens. Even if is not a direct competition with this study, the Siemens Innovation has numerous projects related with parking management using smart sensors, smart software and smart data interpretation. The goals are clear: smart infrastruc-tures for saving time, protecting the environment and ultimately improving the
quality of life for city dwellers. One of the projects starts in Berlin to test radar-based parking space detection with the desired result to end to superfluous and hazardous traffic searching for a parking space, and optimum use of parking spaces within the city [24]. Siemens has launched the world’s first pilot project in a public area (Berlin) aimed at simplifying the process for searching for a parking space. They have installed for test and demonstration radar sensors on street lamps that provide information on parking space occupancy. The network of sensors scans from above an area of up to 30 meters, the equivalent of five to eight parking spaces. The results will be available in 2016 and should prove that by reducing parking search traffic the system is suitable for cutting CO2 emissions.
Chapter 3
Method
Chapter Three begins by laying out the solution to the problem presented in the Introduction chapter, and looks at how the algorithm is working. It will then go on in detail about the architecture. It presents the design and implementa-tion for algorithm, describing both its static and dynamic view.The static view includes elements such as: classes with inheritance and composition, structured classes, interfaces, components, subsystems, and deployment.The dynamic view includes the sequence or communication diagram.
3.1
Parking Detection Algorithm (PDA)
In collaboration with HERE, in Hybrid Components and Vehicle Data (HCVD) team, by analyzing the behaviors of a driver, the program detects whether they are driving towards a destination or if they are currently in search of a parking spot. Several metrics are used for detecting this, including distance to final destination (if set), distance to potential destination (if learned) and the current driving behavior (speed, forking rate, gained distance). HERE formulated this as a classical machine learning classification problem. It is the author’s purpose to choose one of the simplest and most efficient features from machine learning and improve it. The main aim of this study is to investigate the approach chosen, proposing a design and implementation for a solution to be integrated with the current HERE Auto SDK. Once it is known that a driver is actively looking for a parking place, it can be used as information to suggest a parking garage or a parking area in the vicinity of the driver. For this, HERE will use the o✏ine data in their map or online services that add live data. The concept is to develop an application that is able to check the driving status and to make suggestions to the user when a parking behavior occurs.
The feature chosen by the author is called ”Track Cost”. Additionally, a simple classifier was added, that implemented a very simple heuristic technique on the track cost feature and did not require to be trained by any data. The code implementation for the simple classifier is illustrated in listing 3.1. Under the assumption that drivers typically take optimal routes to reach a destination (the shortest or the fastest route) parking search behavior can easily be detected. Once the driver reaches his destination and starts looking for a parking space, the route is no longer optimal. Typically the driver first tries to find a parking
Figure 3.1: Parking Detection Algorithm Flow
spot right at the destination and then explores the street network around this spot with increasing distance. The difficulties appear when the driver is looking for something else (e.g. an ATM, a shop, a gas station, a parking place further from destination). These are non-optimal routes and can happen also in traffic (like an accident on the road can be the cause of a detour).
1 c l a s s S i m p l e C l a s s i f i e r : 2 ””” 3 C l a s s i f i e s j s o n / gpx /nmea t r a c k f i l e s with a c l a s s i f i e r . 4 The c l a s s i f i e r i s c h e c k i n g t h r e e r a t i o s ( c o s t 0 / c o s t 1 / c o s t 2 ) 5 d e p e n d i n g on c h o s e n t h r e s h o l d s and i s r e t u r n i n g a b o o l 6 r e p r e s e n t i n g t h e s t a t u s o f t h e c a r ( d r i v i n g / p a r k i n g ) 7 ””” 8 d e f i n i t ( s e l f ) : 9 #t h r e s h o l d s 10 s e l f . t h r e s h o l d 0 = 1 . 1 5 11 s e l f . t h r e s h o l d 1 = 1 . 2 5 12 s e l f . t h r e s h o l d 2 = 1 . 4
13 14 d e f s t a t u s ( s e l f , c o s t 0 , c o s t 1 , c o s t 2 ) : 15 i s p a r k i n g = 0 16 i f c o s t 0 > s e l f . t h r e s h o l d 0 o r c o s t 1 > s e l f . t h r e s h o l d 1 o r c o s t 2 > s e l f . t h r e s h o l d 2 : 17 i s p a r k i n g = 1 18 r e t u r n i s p a r k i n g
Listing 3.1: SimpleClassifier implemented in Python
In figure 3.1 a work-flow of the algorithm is represented. This algorithm begins with the GPS input, which can be given in three formats: NMEA, JSON or GPX files. A short introduction about these formats was provided in the Background chapter. Another way to get the input is in the car, through real-time driving coordinates. For the purpose of testing the functionality of the algorithm, random input files were not conclusive, so the input data needed to be customized depending on the wanted status of the car. In order to create special tracks, an inside GNSS tool from HERE SDK was used: CarloControlPanel. The idea of the application is very simple: drawing a trace on a map gives a NMEA or GPX file.
Figure 3.2: CarloControlPanel User Interface
CarloControlPanel is a tool that, among other things, can create, visualize and send out NMEA position data via a socket. In figure 3.2 the user interface of the application is presented. Tracks can be interactively created by clicking and dragging points on the map. NMEA data (only GPRMC and GPGGA sentences) is then generated by interpolating between created positions. If the ”Routed” feature is enabled position data is interpolated between calculated route geometry positions. Speed, interval and start time of generated positions can be configured. Tracks can be saved as GPX files or exported as NMEA files. GPX tracks can be loaded and modified. NMEA tracks can be loaded, visualized and replayed.
To understand better how were these files created, a visual example is shown in figure 3.3. There are three colors on the trace: blue - for ”unknown” status,
when there is not enough data collected to decide the status of the car, green -for ”driving” behavior, when nothing unusual occurs in the driving track, and red - for ”parking”, when the driven track is longer than the optimal one. All these files contain more information than is necessary for the algorithm. So the next step is converting the input in pairs of latitude and longitude. In order to convert NMEA sentences a lot of packages are available online, and for GPX or JSON files a simple parser is enough.
Figure 3.3: Example of input file - Visualization
On the basis of figure 3.3, another explanation of the map can be seen in figure 3.4. The idea is the driver is leaving from Isafjordsgatan 39 to Kistagangen 20. The blue path represents the driven track, and the green one shows what would have been the optimal track. One can easily see the di↵erence. With this in mind, is interesting to mention that the track cost is using the route optimality. Given a point B on the track, a previous point A on the track is selected (e.g. 1000 meters before) and a route calculation is done to point B. The track cost is computed as the ratio of the track length to the route length. The higher the track cost is at a point B, the more likely it is that the driver is searching for parking. These costs are calculated for the following distances: 400 m, 800 m, and 1200 m at each track point. Track costs could also be based on the ratio of track duration and route duration. Nevertheless, this is very sensitive to any sort of traffic incident. The length of a track or route can be determined with high accuracy, whereas durations are only estimates with a very high degree of variance and as such give worse classification scores. However, to get the tracks cost required, the next steps in the algorithm are evaluating the driven tracks and the optimal ones. With the costs computed, three thresholds are mandatory. More details about the numbers chosen for driven tracks and
thresholds can be checked in chapter 4. Finally, it is therefore possible to express a status of the car: 0 - driving mode or 1 - parking mode.
Figure 3.4: Driven track vs. Optimal track
3.2
Design
An initial objective of the project was to identify the best configuration for the algorithm. The author chose Python for this task. Python is an open source programming language, easy to learn and use, providing a flexible environment, and not the least, very robust. The code written in Python for this applica-tion has fewer lines of code than the same algorithm implemented in any other programming language, which makes Python less prone to issues, easier to de-bug, and more maintainable. All of these advantages and the fact that is not necessary to look up references frequently, nor are there formalities of the lan-guage, like it would in Java or C++, convinced the author that this is the faster solution for finding out the best parameters to run the algorithm.
This section is set out with the aim of assessing the importance of reusing the existing components from HERE SDK and introducing a new feature. One of these preexisting components, car location (carlo) SDK package is shown in figure 3.5 to help understand how the HERE AUTO SDK is structured. The name ”Carlo” has been chosen having the motivation to create a location SDK for cars. Hence CAR LOcation SDK is CARLO SDK. The SDK consists of several modules: common (shared components that are required by all other components), SDL (smart data loader), navcore (Core Location SDK compo-nents: contains functionality to render a map, calculate routes, search locations
etc.), MobilityGraph (captures user’s mobility graph and transition patterns, provides destination and route predictions), BSP (the board-support-package library: providing platform specific implementations, e.g. system state infor-mation or platform configurations, an interface to the (geo location) sensors, logging, persistence storage, network access, etc.) and ngeo ( MOS compo-nents).
Figure 3.5: Carlo Package Overview
Given the architecture for the SDK, an explanation for the GPS simulation tool can also be represented: figure 3.6. CarloControlPanel tool is implemented in Carlo Package. Carlo allows it to communicate with GPSD or GeoLocation-Sensor. GPSD is a service daemon that monitors one or more GPS-es attached to a host computer through serial or USB ports, making all data on the loca-tion of the sensors available to be queried on TCP port of the host computer. With GPSD, multiple location-aware client applications can share access to supported sensors without contention or loss of data. Also, GPSD responds to queries with a format that is substantially easier to parse than the NMEA 0183. The GPSD distribution includes a linkable C service library, a C++ wrapper class, and a Python module that developers of GPSD-aware applications can use to encapsulate all communication with GPSD [11]. GPSD can also connect to CarloControlPanel so basically all applications that use the library ”libgps” can receive simulated position data - e.g. Here Auto. However, GeoLocationSensor is feeding to the navigation tool a new position that can come from GPSD, NMEA file or directly from Carlo.
It was decided that the best fit for PDA was in navcore module, where are all the features related with maps, routes and search. In order to integrate the new algorithm in the project, a series of analyses on the components were necessary. One of the advantages in doing this is the reuse of existing products
Figure 3.6: CarloControlPanel Tool Package
and components. In figure 3.7 is an overview of the architecture for navcore. Each component can not be detailed in this study due to confidentially reasons. However, analyzing diagram in figure 3.8 on one hand can be seen the new components for navcore module, similar with the classes from prototype phase: algorithm component (PSD), composed from the four main interfaces Driven-Track (DT), OptimalDriven-Track (OT), SimpleClassifier (SC) and RatioCalculator (RC). On the other hand, four components are reused from navcore structure: utilities - where all the helpers methods are, including the mathematical formu-las for Haversine distance, routing - where all the logic for computing the fastest route between two points is, positioning - where all the GPS points are treated and forward, and guidance - necessary for routing and positioning modules.
3.3
Implementation
In figure 3.9 is shown the complete UML diagram for the code used for testing di↵erent configurations for the algorithm. Even if in the diagram are shown only the default values, the UML diagram is valid for all configurations. The dia-gram describes the structure of the PDA by showing the system’s classes, mod-ules, their attributes, methods, and the relationships among them. The class ParkingSearchDetectionAlgorithm owns four classes: DrivenTrackCost, Opti-malTrackCost, SimpleClassifier, and RatioCalculator. These four main classes are in a inheritance relation.
DrivenTrackCostByHaversineDistance and DrivenTrackCostByEquirectan-gularDistance are inherited from DrivenTrackCost. The names may help to understand the di↵erences between them. One class is using Haversine Formula for computing the distance between two GPS coordinates, and the other one is using a simplified version of this formula called Equirectangular Distance For-mula. As mentioned in the Background chapter, the di↵erence between these two is the accuracy provided.
Figure 3.7: Navcore Components
The same division is valid for OptimalTrackCost: OptimalTrackCostBy-HaversineDistance and OptimalTrackCostByEquirectangularDistance. In addi-tion, OptimalTrackCostByRouteLength class is represented. This class is using the HERE routing API, connecting this prototyping phase to the final project code source and creating valuable results. Another important class is RatioCal-culatorByDistance inherited from RatioCalculator. As described in the previous section, a possible RatioCalculatorByDuration class would have been an option, but was dropped out because of its high sensitivity. Finally, all these classes are using the module Helpers which contains methods for reading and converting three kinds of GPS input files: NMEA, GPX and JSON, and also the mathemat-ical formulas methods used by DrivenTrackCost and OptimalTrackCost classes. Figure 3.10 presents the sequence diagram, showing how objects operate with one another and in what order. This allows the specification of simple runtime scenarios in a graphical manner. In general, the PDA should be requested, so the diagram starts with an interaction from exterior calling get driving mode method. This message launches a sequence that runs one time for each of the three required costs. This sequence launches by get cost method with trace and driven distance as parameters, activating in DrivenTrackCost the calculations to get driven track. In order to continue and be able to compute also the optimal track, the GPS point where the driven distance stopped is needed. That’s why is important that all of these messages happen synchronously. Finally, after contribution from RatioCalculator class, the cost can be returned. Only after computing all 3 costs, a final status of the car is given as a boolean result.
The flow chart 3.11 below illustrates at a deeper level the implementation and functionality of the algorithm.
Figure 3.8: PDA Components
3.4
Testing
One of the most difficult parts of this thesis was the testing section. It is well known that there is always the necessity to prove that the code is functional and ready for production use. In order to integrate completely the algorithm in HERE SDK, unit testing and integration testing was mandatory.
The HCVD team advice was to use Test Driven Development (TDD) for the algorithm implementation, because HERE teams are used to agile programming approach [18]. TDD is a software development process that is based on the repetition of a very short development cycle [3]:
1. the developer writes a failing test case (this will define a desired improve-ment or new function);
2. produce code to pass the test;
3. re-factors the new code to acceptable standards.
For the unit testing, the author used the mocking technique. Mock objects are simulating behavior of complex, real (non-mock) objects and they are useful when an object is impractical or impossible to incorporate into a unit test. For example, the implemented code for PDA needed to use Routing API from HERE SDK in order to get the minimum distance for Optimal Track, but in the unit testing part the Routing API would have not influence the behavior of PDA functions. Routing API is suppling non-deterministic results. Also the states of this class are very difficult to reproduce because of its dependencies. The main advantage from avoiding Routing API in unit testing was that running the unit tests was fast, because it was no need to wait for Routing Calculations (which were very slow). To create a mocked class the author chose to use Google C++ Mocking Framework [1]. The framework has a pivotal role in testing because the evaluation of the results is done automatically by framework, when mocked object is destroyed.
For the integration testing, the author divided the all the possible cases in 6 tests, as shown in Appendix D:
status is UNKNOWN (not parking/driving status);
2. Start Detection test with valid trace: when the system starts correctly a PDA object, has a valid driven track file (input file: trace01.nmea) and is able to detect a DRIVING mode only;
3. Start Detection test with valid trace: when the system starts correctly a PDA object, has a valid driven track file (input file: trace02.nmea) and is able to detect a DRIVING mode and switch to a PARKING mode depending on the input;
4. Start Detection test with invalid trace: when the system start correctly a PDA object, but the trace is corrupted (or simply not long enough) in order for the algorithm to start computing car’s mode, so the parking status shall be UNKNOW;
5. Start Detection multiple times test: the system can start the PDA object only one time, any other time that the operation is repeated shall be signaled with an error;
6. Cancel Detection test: if the system starts a PDA object, the system can also cancel the same PDA object. All the values shall be reset to default and the parking status to be UNKNOWN.
Chapter 4
Results and Analysis
The fourth chapter presents and discuss the results regarding the best configu-ration for the algorithm presented as a solution in chapter three.
4.1
Notations and Values
As mentioned in Methods chapter, in order to decide the best configuration for the algorithm, a set of 40 configurations was analyzed. These configurations are mentioned in figure 4.1.
The name for one configuration has the following template (presented as a string concatenation): the method used for finding driven track + ” ” + the implementation used for computing optimal track + ” ” + the first chosen dis-tance + ” ” + the second chosen disdis-tance + ” ” + the third chosen disdis-tance (these three distances are the ones for looking behind from the last GPS posi-tion, all in meters) + ” ” + the first chosen threshold + ” ” + the second chosen threshold + ” ” + the third chosen threshold. For example, the name for the first configuration is ”Haversine Haversine 400 800 1200 105 115 13”. This can be translated as: the implementation used for finding the driven tracks is by Haversine formula, the method used for calculating the optimal tracks is by Haversine formula also, the chosen distances are: 400 m, 800 m, and 1200 m; and the chosen thresholds are: 1.05, 1.15 and 1.3. The comma could not be rep-resented in the name, so the respected rule is the comma should be immediately after the first digit, which will always be ”1”.
It is apparent from the structure of one configuration that 3 distances are needed and that the first configuration starts with first distance equal to 400 meters. This number is not chosen randomly. Legally, to make a U-turn safely, you must be able to see well in both directions. It is illegal to make a U-turn on a curve in the road, on or near a railway crossing or hilltop, or near a bridge or tunnel that blocks your view. You shall never make a U-turn unless you can see at least 150 meters in both directions, which means at least 300 meters. Besides the legally aspects, the GPS satellite can recognize that a U-turn happened in the driven trace of a car if a minimum distance of 400 meters was traveled. In response to this research the starting configuration distance was set to 400 meters. The same thinking was applied for the second and third distance, which are double and respective triple of the first one.
Figure 4.2: Algorithm Test Files
thresholds. The minimum threshold that makes sense and shows the slightest di↵erence in the ratio between the driven track and optimal track is 1.05. For thresholds less than 1.05, the di↵erence between optimal and driven track was too small to influence the algorithm (less than approximately 150 meters). At the initial threshold di↵erent numbers from the interval [0.05,0.20] were added to obtain the second minimum threshold. Being interested only in the first 3 digits of the fractional part, made the author decide that adding 0.10 for the second threshold, and 0.20 for the third threshold gives an observable di↵erence for the final costs needed in the algorithm.
Another important notation is the one for the input files. Fifty NMEA files were created and renamed with a intuitive description like in figure 4.2. All the test files were generated manually in GNSS tool presented in Chapter 3. The best way to create NMEA files for testing a navigation application would be with drive testing, but because of the resources allocated for this project, drive tests were not possible. The cheapest solution for HERE to replace drive tests was to introduce the GNSS tool. This tool is supporting only the map from Berlin, Germany, so as a result all the test files are created with Berlin GPS coordinates. Even if the input files were not a result of a real car driving around, the final files presented interesting and possible cases of di↵erent behaviors of a car. The first set of files aimed to represent the basic driven track of a car (e.g.: a straight line or a small loop in the end of the track), while the next set of files emphasized on the unexpected driven track of a car (e.g.: a double loop in the middle of the track, which can be the result of the driver looking for an ATM machine). Another way to distinguish between these files is the size, so the number of NMEA sentences. The correlation between the number of NMEA sentences and the number of GPS points is resulting in how long is the driven track created for the respective file. In the end, the files contained distances between 0 and 50 kilometers. What is interesting in creating data manually is that the author knew the correct result of the algorithm for a certain input file, which allows easily to compare an actual result with a final one.
For example, ”test01 loopend” means that is the first test file generated in GNSS tool (test01) and at the end of the GPS track has a loop (loopend). The algorithm should find parking mode in the last part of the trace where is the unexpected behavior (the loop). The table 4.1 illustrates ”Haversine Haversine 400 800 1200 105 115 13” configuration for ”test01 loopend” input file. What is important to understand from this table is related with the ”Distances” col-umn. As it can be seen, the first distance is 400, which represent the first distance from the configuration. After that this distance is increased with 500 meters. The idea behind this is that it does not make sense, in testing param-eters for final configuration, to check the status of the car from meter to meter (as it would happen in real cases and final implementation of the algorithm). In researching phase, in order for something to change and for the algorithm to recognize that something is di↵erent from a few seconds ago, we need at least 500 meters in between. In this case, the maximum is 5400 meters because the trace created is smaller than 5900 meters (5400 + 500). So for the first test file, 11 results are generated which can be observed in ”Result” column, with ”0” - meaning driving mode and 1 - parking mode. However, the input files were created manually, and the author decided the ”Actual Result” column at the time the files were generated. This was a time-consuming way of check-ing if the results were correct, but in end the only efficient solution. Knowcheck-ing
Algorithm Configuration: ”Haversine Haversine 400 800 1200 105 115 13” GPS trace file Distances Result
(R) Actual Result (A) R A R A Ratio test01 loopend 400 0 0 0 900 0 0 0 1400 0 0 0 1900 0 0 0 2900 0 0 0 3400 1 1 0 3900 1 1 0 4400 1 1 0 4900 1 1 0 5400 1 1 0 1
Table 4.1: Configuration 1 for test file 1
the generated and correct result leads to ”Result vs. Actual Result” or ”R A” column. Applying XOR operation between these two results is giving the wanted output. XOR is 1 only if the input values are di↵erent, and 0 if are equal. That means that wherever is a ”0” in this column, the generated results are the expected ones. In the ”Ratio” column a simple excel function is applied: COU N T IF (F 4 : F 12; ” = 0”) : COU N T (F 4 : F 12), which is giving a ratio between the correct results and the total results. In this case are 11 correct results divided by 11 results, giving the ratio ”1”. This is a great example, ratio ”1” showing that the algorithm is functional, for that particular test case. The complete table can be analyzed in the Appendix A.
4.2
Results
In the end, the tables were obtained with the final results for: 1. all configurations for Haversine Haversine 400 800 1200; 2. all configurations for Haversine Haversine 500 1000 1500; 3. all configurations for Haversine Haversine 600 1200 1800; 4. all configurations for Haversine Haversine 700 1400 2100; 5. all configurations for Haversine Haversine 800 1600 2400; 6. all configurations for Haversine HereAPI 400 800 1200; 7. all configurations for Haversine HereAPI 500 1000 1500; 8. all configurations for Haversine HereAPI 600 1200 1800; 9. all configurations for Haversine HereAPI 700 1400 2100; 10. all configurations for Haversine HereAPI 800 1600 2400;
In the appendix chapter are attached all the tables for Haversine Haversine configurations. What is interesting in all the tables above is the geometric mean, which is computed with the final results ”R A” from all the 50 input files. The geometric mean is better suited than arithmetic mean since it is much more robust and sensible [12]. The final result was unexpected: the best configuration was Haversine HereAPI implementation with 400 800 1200 distances and 115 125 14 thresholds because the geometric mean was equal to 0.83, being the best result from all 40 final tables.
4.3
Reliability and Validity
The reliability of the configurations is very good because the conditions can be controlled very precisely, as discussed in the beginning of this chapter. Creating the input files manually o↵ers flexibility and gives the opportunity to touch all the unexpected behaviors, knowing the expected result in any case. This can include also some impossible events.
Unfortunately, the validity su↵ers for the same reasons that the reliability is good. Since everything is created virtually, a real case taken from a drive test might be quite di↵erent from the case created manually by a human (being a driver in traffic is completely di↵erent than being one in front of a computer). However, the main purpose for the input files was to detect the best configura-tion for the algorithm regardless of the authenticity of the driven track. Ana-lyzing the validity from this point of view, the obtained results are considered important data to HERE because these are providing better information about how would an algorithm work with only raw data like altitude and longitude.
4.4
Discussion of classification results and error
cases
Given the recommended SimpleClassifier, it is worth looking at classification results in a bit more detail. Taking into account all computed results for all 40 configurations, there are 43,040 entries in the output table. From the total 10,712 are wrong and 32,328 are correct results. That means that almost 25% of the entries were computed bad. The numerous reasons could be classified in two categories: false positives and false negatives.
4.4.1
False positives
Analyzing 25% entries, can be said that some of them had been wrongly classi-fied as parking mode while being in fact driving mode. Manually inspection of these segments can roughly assign 4 categories to those False Positives:
1. Beginning of track problem 52%: A lot of wrong search segments appeared at the beginning of a track (within first 1000-1500 meters) as in figure 4.3. This is due to the fact that for short tracks a few meters of di↵erence between track length and route length might already be significant with respect to the cost ratio. These cases can be easily excluded since it is unlikely that a parking search starts right at the beginning of a journey.
Figure 4.3: Red Segment - Track Start Problems
2. Map matching problems 18%: Some wrong search segments are related to map matching problems as presented in figure 4.4. If the map matcher is putting a track point to the wrong road element, route calculations may be significantly longer or shorter. Additionally, some of the recorded tracks didnt seem to be properly map matched and showed large jitters, which also easily resulted in longer tracks.
Figure 4.4: Red Segment - Map Matching Problems
ex-plainable due to a detour as shown in figure 4.5. This typically indicates a wrong annotation, so human mistakes.
Figure 4.5: Red Segment - Wrong Annotation
4. Unknown reasons 19%: The remaining wrong search segments remain not easily explainable like in figure 4.6. Often, these segments had been rela-tively short. So a smoothing of the predicted mode might remove a lot of these cases. It looks like they often relate to map matching problems as well. Further investigation needed.
