Positioning by Road Feature Correspondence

This research analyzes a new method to localize a moving vehicle within a known road network using di↵erential odometry and a digital road map. The technique proposes geometrically hashing road features whose curvature is great enough to represent a distinct, measurable, real-world phenomenon. Several other strategies using road map data to constrain a localization search are discussed. In the recognition phase, this research proposes using a modified particle filter provides a way to maintain, test, and resample multiple hypotheses of the vehicle’s dead-reckoned location.

With dead-reckoning a navigator determines his or her position by accumulating movements, i.e. displacements in position, and adding them to the last known position. An everyday instance of dead-reckoning is the use of step-by-step directions to a lost motorist. 1 Here is a colloquial example: "Go to the stop sign and take a right. Drive three blocks and the post o ce is on your left." The starting position is where the conversation took place, and the change in position is given. A distance measure, which in this example is the number of blocks, creates a spatial reference frame in which odometry plays a necessary role. To use the directions the navigator must count blocks. Additionally, because the navigator in the example is on a surface and not a merely a line, the navigator must also keep track of heading.
The second type of navigation is position fixing. Position fixing determines one's absolute location by using environmental or infrastructural indicators. This navigation technique does not start with a known position but aims to resolve it from surrounding fixtures. In the above example, the lost motorist might be aware of the relative position of a shopping center and stop to find its absolute position on a map. The shopping center is the landmark and the navigator's recognition of it instigates a qualitative event [3]. Additionally, humans associate these kinds of landmarks with their adjacency to other landmarks in a topological way. In the above example, it is unlikely that the direction-giver links each landmark in those directions by some geometric algorithm, but rather through a topological connectedness, the memory of which is enhanced with numbers for precision. The A more sophisticated and popular example of position fixing is Global Navigation Satellite Systems (GNSS), such as GPS, in which satellites transmit details about their own position and time signals to navigators on the ground. In GNSS the ground receiver uses the distance from each GNSS satellite to trilaterate its own position. GNSS is an example of infrastructure-based positioning, which requires a pre-existing man-made system in place.

Distinctive Places and Features
Kuipers and Byun in [4] define a "distinctive place" as "the local maximum found by a hill climbing control strategy, given an appropriate distinctiveness measure." However, we will relax this definition to be "the location of an appropriately high distinctiveness measure." We do this for two reasons. First because the research here describes a passive system, where no control inputs influence the system and position is estimated only after odometric measurements are made, we do not have the ability to "hill climb" to maxima. Second, as will be described in the Methodology Section, because we quantify the curvature of radius of the road to which a vehicle is bound, we cannot maximize this quality even by driving it in a slightly di↵erent way. 2 To convey the importance of using landmarks and "distinctive places" in any global localization strategy, it is instructive to examine techniques that do not use features with obvious distinctiveness, but through automation recognize distinctive features even still. Such an example is Terrain Reference Navigation (TRN), in which environmental features sampled (typically by radar) belong to set of elevations that exist on a continuous domain, i.e. the set real numbers between the lowest and highest terrain [1]. The navigator using TRN continues to accumulate elevation measurements and their relative positions until a su cient terrain signature is generated and matched with a previously acquired database of terrain elevations. The words "su cient terrain signature" should evoke the same idea of landmarks. The time series elevation data, despite being on a continuous domain and uninteresting to humans, becomes enough to distinguish itself from other possibilities in a known dataset.

Topometric Positioning
The positioning solution proposed in this research derives from a human's ability to navigate with turn-by-turn directions and simultaneously to locate oneself by recognizing landmarks along the way. This instinctual approach to human positioning forms a subtle nexus between geometric navigation environments where spatial relations determine one's position in a reference frame, and qualitative or topological navigation environments which highlight discrete landmarks whose adjacencies form a navigable graph. The fusion of these environments has been called topometric localization [5]. 2 We remark here that although measuring the path of a vehicle during a lane change in the middle of a turn would indicate a di↵erent curvature than if the vehicle did not change lanes during the turn, we note that this does not maximize the distinctiveness of the road's curve, and instead e↵ectively adds noise to the measurement of it.

Significance of the Study
For most people satellite navigation is the sole solution to the global positioning problem. However, alternative positioning strategies can augment GNSS in several common situations, and provide a safeguard against GNSS outages. The following subsections describe situations where a solution to road-based GNSS-free localization might be useful.

Commercial Road Navigation
Global Positioning System authorities including The United States Air Force guarantee ongoing availability and maintenance of American GPS service [6]. Nevertheless, GNSS signals are easily jammed, interfered with, or blocked by weather because they are relatively weak [7]. Accounting only for free-space dissipation, the received signal's strength is approximately -120dBm at the earth's surface [7].
Additionally, a GPS receiver demands even greater signal strength than that required for tracking, and a GPS receiver may demand a even more time to get an initial position in bad weather.
On the other hand, intrinsic sensors such as vehicle odometers can immediately begin providing data to use for estimating location, despite any natural or manmade radio frequency interference.

Defense Road Navigation
Although mention of military positioning systems conjures up the image of soldiers, naval vessels, and fighter jets, there are many use-cases of military positioning that are similar to their civilian counterparts. Road-based vehicle patrols or re-supply routes both require positioning that is constrained to a road network, and both might take place in a GNSS-denied environment [8]. Further, the threat of GNSS failure impinges most greatly those who are least trained to navigate without it. Whereas the loss of GNSS would a↵ect pilots, sailors, and expert soldiers to some degree, such a loss might cripple some other military units' ability to navigate foreign roads and arrive on time.

Extension to Indoor Localization
With modification this research can be applied to indoor positioning. Indoor positioning is an active area of study among the major technology companies, and a lot of resources are being spent to bring indoors the high level of positioning service that is o↵ered outside by GPS [9].

Game Non-Player Character Positioning AI
In many games a non-player character (NPC) is imbued with an automatic awareness of location. On the other hand, the player is often forced to find himself within the game world through trial and error. The technique researched here could be cheaply integrated into the artificial intelligence of NPCs and give them a more realistic ability to learn their locations. Here, the "mapping" part of Simultaneous Localization and Mapping (SLAM) might or might not belong well to the game story because the player or NPCs could already have a complete map at their disposal [10,11].

Related Work
Most of the current techniques in the field of map-based global localization can be categorized as either "map constrained tracking" or as "landmark recognition." Below is a brief overview of each, followed by a closer look another even more pertinent strategy.

Map Constrained Tracking
Most of these tracking techniques do not use roadmap data directly to address the "kidnapped robot" problem; rather, they rely on an outside source of global location information such as GPS or an otherwise previously known location. Only after which point does the vehicle use dead-reckoning to move geometrically about the state space and provide it with a continuous estimate of the position. When digital map data is consulted in combination with this technique, the drift from dead-reckoning is corrected to provide an even more accurate estimate. Usually some form of map-matching technique, wherein a position estimate is given to the algorithm as input, and a map edge or node is returned, is used. 3 In [12] a survey of techniques are discussed, but the two relevant ones here are detailed in the subsections "Dead reckoning: Map matching" and "Dead reckoning: Dynamic filtering." 4 With these methods, a position is known at initialization and is a) updated by the position on a map corresponding with a dead-reckoned change in position or b) updated to be consistent with a motion model which is itself corrected by additional measurements. In their research Karlsson and Gustafsson only use the Anti-lock Braking System (ABS) Wheel Speed Sensor data from the vehicle's Controller Area Network (CAN) bus to perform di↵erential odometry, although techniques using an IMU are discussed. As another important aside, the authors also use the term "virtual sensor" when referring to measurements provided by consulting the road map data, and we adopt that term in this research.
In [13] a similar technique using di↵erential odometry, roadmap data, and a particle filter is discussed. The experiment is divided in the tracking task, i.e. initial position is known, and the global localization task. For tracking it is unclear from the extended abstract how the road map data is traversed by hypothesis particles, but it is likely the same map matching style used in [12] because of Merriaux's reference to similar work by Gustafsson. For localization, a much greater number of particles are spread uniformly across the search space, in this case a road network of approximately 100km. With 3600 particles spread across this map, the authors claim that global location is determined within 90 updates, each of which taking 0.51s on a single core. Additionally, the authors identify a linear relationship between runtime required to update all particles and the number of particles.
In [14] Li and Leung propose a Constrained Unscented Kalman Filter (CUKF) to fuse Global Positioning System (GPS), Inertial Navigation System (INS), and digital map data. While GPS data provides the drift-free global localization capability of their system, the INS provides dead-reckoned position estimates with higher resolution. In particular they use a measure of agreement of the vehicle's heading with the direction of roads in a neighborhood in order to further constrain position estimates. They show that the CUKF significantly improves the position estimates over a standard unconstrained Unscented Kalman Filter (UKF).
In [15], Najjar and Bonnifait directly address the issue of how best to select a road to solve the road matching problem. 5 Their approach consists of a Multisensor Fusion Extended Kalman Filter (EKF) with Di↵erential Global Positioning System (DGPS) and ABS wheel speed odometry as inputs. This position model then feeds a set of road selection process whose criteria are based on 1) proximity to the estimated position and 2) consistency with travel direction (as in [14] with speed as an additional consideration for this consistency. In particular, the possibility of a vehicle traveling at 40kph being on a road perpendicular to its trajectory is highly unlikely and Najjar and Bonnifait's model takes these sorts of constraints into account. 5 The road matching arises when global positioning data such as that from Global Navigation Satellite System (GNSS) is too noisy to stay on a road and must be corrected to represent a position on digital map data, especially GPS turn-by-turn navigation devices.

Summary
Landmarks distinguish roads so that each road is measured as in a way that separates it spatially from other roads. Because of the limited degree of landmark characterization in the above techniques, we classify these only as "map constraining," and not as "feature detection" or "landmarking." In the next subsection we discuss several techniques that make more overt use of landmarking in order to determine global location.

Landmark Recognition
The most e cient techniques for global localization apply Kuipers's idea of a "distinctive place" [16] by fixing landmarks to an either learned or already known map. If a known location is recognized to be close, the degree of confidence in a navigator's position can be restored to the degree of confidence held in the position of the landmark. In some applications such as [11] the landmarks form a graph whose measure of connectedness is the ability of a game character to navigate from one landmark to another. In [11] Schra↵enberger and Hervé call this topology a "Perceptual Navigability Graph." The approaches discussed below apply the use of landmarks to spatially distinguish roads (or in some cases spaces) with varying measurable features.
In [17], Jensfelt and Kristensen present a technique that consider multiple hypotheses by generating a set of possible poses when a known visual feature is recognized. For example when their robot recognizes a door, a set of hypotheses consistent with seeing the door under the circumstances, e.g. location of doors previously known to be on the wall, is generated. Each hypothesis, similar to particles in the particle filter, is updated with its own Kalman Filter estimates and covariance matrices. Emphasis is placed on topology and map discovery.
Notably in this research odometric dead-reckoning and feature recognition are reconciled by a process the authors term "data association," wherein the authors threshold a similarity measure given by squared Mahalanobis distance between the pose hypothesis and the pose "candidates." We assume the convention of naming feature-generated locations as "candidates" in this research, as well as assuming the terms coined by the authors in [17] to describe "supportive" estimates as generated by dead-reckoning and "creative" estimates to be those generated by feature recognition. 6 In [5], Badino et al. also use images as recognition features along a navigable path. In this case the research is performed outside with images similar to those in Google Streetview, and range measurements are taken to accompany the images, all taken periodically along a fixed 8km route. This route comprises a discrete state space and topology of landmarks. In the query phase the authors use their novel U-SURF and WI-SURF features to update a Bayesian filter. This technique was 100% e↵ective in its ability converging to the correct global location. Another notable detail is that the researchers in [5] created their image training set over all four seasons in order to make querying resilient against changes in vegetation, lighting, etc.
In [18] Floros et al. estimate the shape of a road by visual odometry and match it with OpenStreetMap data. In their project they call "OpenStreetSlam" the authors use Harris corners and RANSAC to update a Kalman Filter which updates a camera's pose estimate and, ultimately, the shape of a driven path.
The researchers make use of Monte Carlo Localization (MCL), or particle filter, in order to maintain a distribution of possible locations. They update their hypotheses using measurements of their query shape against the road data with Fast Directional Chamfer Matching across the entire set of possible roads. This is done online while the vehicle is traveling a required initial distance and takes approximately 11.5s over the Karlsruhe Institute of Technology and Toyota Technological Institute (KITTI) vision dataset consisting of a total driving distance of 39.2km within a 1km radius [19]. The basic components of this approach, i.e. shape of a traveled road as determined by odometry, OpenStreetMap data, particle filter with updates based on shape correspondence, amount to a vast similarity in the research that will be described here. We remark here that the work in [18] di↵ers substantially from ours in that Floros et al. use visual odometry to detect roadmap features and use line segments to represent them.

Geometric Hashing and Navigation
In their paper "Image-Based Navigation on a Chip," Lifshits et al. propose a navigation technique to locate the end e↵ector of robotic systems used for electronic chip manufacturing functions such as "lithography, cutting and inspection" [20].
Given a known wafer map, the authors propose geometrically hashing all of the features of the wafer map in a preprocessing stage, and subsequently locating the robotic eye-point by geometrically hashing a subset of the features in a lookup phase 7 . Although "navigation" here does not refer to that of a surface-bound vehicle, the essential components of locating oneself with a limited perspective of a known overall environment, a theoretical approach discussed in detail by Kuipers in [21], still apply. Further, the research in [20] is the only previously existing work to use geometric hashing to solve the "kidnapped robot" problem. As a di↵erence to Lifshits et al.'s work and the work here, we want to emphasize that our approach considers graph-like data, and not a point cloud. This distinction significantly changes the nature of what comprises a feature and how those features are discovered. 7 Section 1.3.4 provides an overview of the classical geometric hashing technique used in [20].

Geometric Hashing Overview
The technique of geometric hashing has been used in many fields of research to align a segment of graph data with its original set. Applications can be seen in protein structure alignment [22] digital photograph registration [23], and astrometry [24].
The technique of geometric hashing can be broken down into two phases: building a hash table (the Training Phase) and indexing test points within the hash table to determine to which basis the points belong (the Recognition Phase) [25].
When building the geometric hash table, the goal is to create key-value pairs whose keys represent test points in the coordinate system produced by the corresponding value, the coordinates in whose basis the keys exist. For example, "1.05,-0.35": (35143,85243: 35100,84987) represents a point whose coordinates are 1.05, -0.35 after it has undergone the change-of-basis transformation defined by the two points 35143, 85243 and 35100, 84987. These two points are recorded in the original coordinate system so that when the lookup phase takes place, the result will be in a coordinate system useful to the user.
These key-value pairs are constructed by examining combinations of two points on the model, creating a change-of-basis function using the two points as a new basis, and then recording the coordinates of the remaining points in the new coordinate system into the hash table. Below is a more thorough description.
An important caveat to note is that a query pattern may be matched to more than one location in a set. Take for instance the short path consisting of a straight drive forward for a trivial distance. This could be matched to any small straight road portion of the map, whose matching paths will be many. Rather, the technique of matching the geometry of a path to a map requires that the path contain enough information, here unique points, to separate it from similar possible paths.
The rest of the first phase is straightforward: a transformation C is con- represented on the list determines the winner from the list. In application, these two steps require significant attention to peculiarities among the data and computing limitations. In the next section we will discuss in details specific to Path Registration how our implementation deviated from the overall geometric hashing strategy. [26]

Thesis Statement
This research analyzes a new method to localize a moving vehicle within a known road network using di↵erential odometry and a digital road map. The technique proposes geometrically hashing road features whose curvature is great enough to represent a distinct measurable real-world phenomenon. In order to withstand uncertainty and absence of measurement events, a modified particle filter provides a way to maintain, test, and resample multiple hypotheses of the vehicle's dead-reckoned location.

List of References
[1] P. D. Groves, Principles of GNSS, Inertial, and Multi-Sensor Integrated Navigation Systems Second Edition. Boston: Artech House, 2013.

Methodology
Although only one of the modules (RoadMapHash, which preprocesses the OpenStreetMaps data into a key-value database of recognizable curvature features) has been fully implemented, we propose a control system architecture that enables a vehicle to determine its location both on-line for use in consumer facing applications, and o↵-line, in applications where the vehicle data is merely recorded for later analysis by a management authority.  This database may be used on-line as a file store or transfered over a network connection. Ultimately, the RoadMapFilter algorithm returns a best hypothesis to the user.

Architecture of the Positioning Strategy
In the next sections we will set up the vocabulary necessary to discuss the particularities of RoadMapHash, cover the sensors and data we use in this research, propose a new data-centric language for conveying road curvature data, analyze RoadMapHash, and finally provide an overview of the future components of the Remark. A Jog is not bidirectional. If three Nodes n 1 , n 2 , and n 3 belong to ways indicating travel is permitted both from n 1 to n 2 to n 3 as well as from n 3 to n 2 to n 1 , then two unique Jogs must represent each navigable path.
A Jog may not begin and end at the same node. In other words, U-Turns are not considered as drivable paths.
The Jog structure is useful when calculating the change in direction, road curvature, and distance along a path of connected nodes.
Remark. See that the set of Jogs J C traversing through a center node n C is a subset of the Cartesian product of the set N in of nodes, for which there exists a way in-bound to n C , with the set N out of nodes, for which there exists a way out-bound from n C . Because U-turns are not included in the definition of a Jog, J C is usually a proper subset of this Cartesian product, and does not include the set of pairs where the start node n S is the same as the end node n E .
Definition 2.2.4. Sharp Jog A Jog is "sharp" with respect to a given radius of curvature if the circle circumscribing the Jog has a radius less than the given one. On a map these look like what we think of when we say "Turns" but because of the challenges in sensing the phenomenon associated with Turns, a sharp Jog has only this constraint. The radius of curvature R J of a Jog consisting of three Nodes N S , N C , and N E is equal to the radius of the circumcircle of the triangle 4N S , N C , N E . We remark that the intersection of B S,C and B C,E is equidistant to each of N S , N C , and N E and thus the center of the circumcircle of 4N S , N C , N E .

Sensors and Data 2.3.1 Odometric Sensor
In this research we intend to use the ABS wheel speed sensors to record the di↵erential odometry of the moving vehicle 1 .
We refer here to [3], which makes the following remark on the accuracy of ABS wheel speed sensors.
Typical accuracy of ABS wheel speed sensors over OBDII is 0.025 meters/second, where as the accuracy of the transmission rotation sensor is approximately 0.28 meters/second.
Although ABS wheel speed sensors are accurate and can be used to perform di↵erential odometry, they are unfortunately di cult to interface with. Whereas vehicle speed (as measured from the transmission) is part of the "Mode 1" On Board Diagnostic (OBD) interface, the OBD request codes for other systems such as ABS are not openly published, and often come at a significant cost for scan tool manufacturers.
Researchers use several strategies to determine these proprietary Parameter ID (PID) codes 2 . An step-by-step overview of one of our strategies is given below. pattern is a circle as in a roundabout. This will provide two di↵erent rear wheel speeds that are generally constant during the evaulation period. Figure 4 shows the response from the PID code 0x2103 4 indicating that a sensor reading was zero, increased in value during a reverse movement, returned to zero, increased during a forward movement, and finally settled at zero.

Map Data
This research uses the OpenStreetMap dataset. The OpenStreetMap (OSM) dataset is an open source competitor to Google Maps and provides direct access to geospatial vector data via its Planet.osm data file. The OpenStreetMap Markup Language, denoted by the ".osm" file extension, is a spatial implementation of XML and provides a convenient way to define geographic types, especially roadways, and assign attributes to them. As in other vector file formats, nodes are given in a coordinate system, and edges are implied by the inclusion of multiple nodes within a shape. In OSM, the shapes are linestrings and polygons. Road Selection: [5] succinctly summarizes the issues when selecting roads for localization: This problem ... of selecting the "good" segments from the subset {S1, ..., Sn} ... is di cult because of several factors.
-The position is estimated with errors that can be magnified by multipath e↵ects. In addition, the transformation between the GPS coordinates (World Geodetic System 1984 reference system) and the projection frame of the map [here, the French Nouvelle Triangulation Française (NTF) Lambert coordinate system] can induce errors.
-The coordinates of the segments are falsified by errors due to terrain measurements that are carried out by cartographers as well as due to numerical approximation.
-The road network in the database does not always correspond to reality, i.e., it can contain old roads that no longer exist or new roads that are not yet in the database.
-The map does not contain all road network details. For example, a roundabout can be represented as a simple point.
-The vehicle is moving on a 3-D surface, whereas the map represents a planar view.
-The vehicle does not travel exactly on the segments representing the roads.

Data Centric Programming Language 2.4.1 Introduction
Data Centric Programming Languages form a nexus between data and computation. The focus of a data language's use coheres with its structure, and with the rise of network analysis, graph-centric data languages have recently achieved first class status [6,7,8]. In this research we devise an extended graph data language in order to achieve three main goals. Primarily, the new language will provide a means to serialize special data structures used in the research. Second, and more importantly, the new data specification, in binary form, will form a basis for a selfreferencing database engine. Finally, distributed execution environments, such as MapReduce, will benefit from the JogML and JogBin formats.

Jog Modeling Language (JogML) JogML Introduction
Existing graph data languages have three features in common. One, they emphasize universality with commonly used data specifications, such as XML.
Two, they provide extensibility for arbitrary types and attributes, such as with tags or attributes. These features are unnecessary for this research because this research provides its own data manipulation tools. And three, most current graph languages are limited in their ability to describe hyper-edges [9]. This is unsuitable for this research because it uses unique data structure called a "jog," which is a sub-graph consisting of three nodes. Thus, the data language requires the ability to describe hypergraphs. Below is a summary of the nature of a need for Jog Modeling Language (JogML) in order to further this research.

Why Yet Another Graph Language
The OpenStreetMap (OSM) dataset is an open source competitor to Google Maps and provides direct access to geospatial vector data via its planet.osm data file. The OpenStreetMap Markup Language, denoted by the .osm file extension, is a spatial implementation of Extensible Markup Language (XML) and provides a convenient way to define geographic types, especially roadways, and assign attributes to them. As in other vector file formats, nodes are given in a coordinate system, and edges are implied by the inclusion of multiple nodes within a shape.
In OSM, road shapes are linestrings, which is denoted in OSM as Ways.
Although this street map data is well laid out for rendering maps and adequate for data transfer online, OSM requires multiple passes to recreate the network topology of the roadway system itself and is somewhat bloated for the purposes of RoadMapHash. Although a graph is implied by the data shapes in OSM, a graph-specific data language can reduce the overhead in parsing and recreating the graph structure by edges directly. Several such graph data languages exist.
The most prominent is Graph eXchange Language (GXL) described in [9] and [10]. Despite the prevalence of GXL, Graph Modeling Language (GML), created by Michael Himsolt [11,12] provides an excellent base for redefining the Open-StreetMap dataset for this research. Below is an explanation why this is.
Although GXL avails itself to existing XML parsers, GXL is unnecessarily general and verbose for this research. In particular, one goal of the JogML is to limit the value space of the terminals used in order to minimize the size of the serialized data files. Additionally, community support for a proposed file type is not necessary because this research provides a JogML parser, compiler, serializer, and deserializer. Finally, although GML does not provide a way to describe hypergraphs, it can be readily extended to do so. Hypergraphs are necessary here because the research makes use of a unique data structure called a Jog, consisting of three nodes. These three nodes comprise a one-way journey from a Start Node, to a Central Node, and to an End Node (see Figure 2 for an example of three Jogs over a sample road network). The three-node structure of a Jog is necessary for measuring road curvature, which must be computed for comparison with inertially sensed movement. Curvature is thus central to this research, and a data language that directly describes curvature during graph traversal will significantly reduce computation during data pre-processing. By redefining a road map as a set of Jogs, the graph becomes a hypergraph. Each Jog describes a subgraph consisting of a roadway node connected to two other roadway nodes, albeit in sequence.
Hence the need to extend GML to support the Jog data structure.

JogML Grammar Specification and Example
The grammar specification of JogML is provided in Figure 6. Of particular note, Jogs are specified with a start, center, and end node, and each node optionally includes a list of Jog Starts, Jog Centers, or Jog Ends. This is due to the fact that a node may be member of one or more Jogs as its start, center, or end, but perhaps at the exclusion of the other(s). In order to allow for a reduction in storage space,

JogML Parse
As alluded to above, this work includes a recursive-descent LL(1) parser for the JogML format [8]. This simple hand-written parser uses the C++ extraction operator >> of the standard template library object std::stringstream as a lexer of white space delimited tokens. There is a one token bu↵er kept in a string variable "word", and although the parser style is recursive-descent, the JogML format never requires that recursion reach a depth greater than zero.

JogBin Data Format
In addition to JogML, this research produced the JogBin binary data format, whose specification is designed to make use of memory mapped files. By using the Unix-based mmap, or a similar system-specific memory interface, the binary data can be written and accessed as though it were virtual memory. Because our data is graph-like we can preserve the bidirectional connections between Nodes and Jogs by representing their edges, not as identification numbers, but as relative memory addresses. By retaining the connections within the binary data itself, the file can be used in-place as a complete data context. All preliminary computations are intrinsic to the file itself.

Issues with JogBin
In order to use relative memory addresses as a means to recreate the graph relationships in the data context, the machine writing the data must have the same data type sizes as the machine reading the data. Additionally, endianness may be a problem for raw binary reads and writes on di↵erent machines. Although there are some techniques to obviate these problems, the current implementation in this research only accounts for one architecture. Additionally, the version code in the file header is intended as a means to uniquely identify binary configurations, as well as version di↵erences. Also, there is currently no system in place to keep the JogBin memory-mapped file threadsafe. Compare this with the implementation as used in MongoDB where the mmaped files are sequentially locked for individual collections.
The three JogBin tables, Tables 1, 2, and 3, specify the three portions of a JogBin file. The data is first converted into data structures that have been optimized for 64-bit processor architecture [13], and then they are memory copied to their respective file locations in the memory-mapped file.

JogML Improvement Considerations MapReduce and Distributed Computation
A major advantage to serializing the data in the JogBin format is the compression that it a↵ords. Much like Google's Protocol Bu↵er, JogBin can be transferred over a network much more quickly without losing the structure necessary for followon computation [14]. That is, JogBin is an excellent transfer and archival format without having the expense of requiring additional processing to use it. It is thus very well-suited to be used in a MapReduce distributed execution environment.

Database Engine
Currently the implementation of RoadMapHash uses C++ standard library containers, especially the std::vector and std::map. However, with data serialized in the JogBin format, the data could be traversed in-situ without conversion, and thus duplication, back into the original data types. With similar considerations in mind, database developers such as those at MongoDB have similarly employed memory mapped files have as a basis for their database engines [15].

Language Conclusions
The RoadMapHash algorithm has substantially benefited from the improvements of analysis from a Programming Language perspective. The JogML and JogBin formats advanced the RoadMapHash from being a series of scripts to forming the basis of a distributed graph database engine. The specification of JogML allows for a text-based serialization of the RoadMapHash data structures, but more importantly, it permitted the creation of JogBin, a binary datatype that can be used as a graph-database. Finally, the added benefit of data compression and fast serialization makes a distributed computation environment for RoadMapHash more e↵ective.

Training Phase: RoadMapHash Algorithm
RoadMapHash is the first component of the RoadMapLocate system. It is our most unique contribution to the field of odometry-based localization. Just as in classic geometric hashing, the goal of RoadMapHash is to attempt to locate a shape within a larger one. However, the geometric hashing method used in this research does have two distinct di↵erences.
First, unlike in classical geometric hashing, the query, or test shape, need not be scale invariant because the scale of the map is the same as the scale of the odometric sensors. This alleviates the combinatorial cost of projecting each node's position into the bases defined by the pairs of its k-nearest neighbors' coordinate systems. Instead, the coordinate system used to describe features can be the ego reference frame of the vehicle, with the center of the rear axle serving as the origin.
Features can thus be described in terms of its hypothetical movements along a path, i.e. incremental changes in distance and direction.
Second, the features we seek to find in the hash table are not coordinates of nodes at all. This is because most nodes are distributed arbitrarily within a road section, and only describe along a continuous road space in the real world. As described in [16] as a "distinctive place," the localization framework must at some Fortunately, there is more data that can be used to build a suitable feature.
Because the vehicle is measuring path distance, and inter-turn distance can be calculated by projecting the geographic coordinates to a flat earth model, we can link associate pairs of turns as distinct features.
The resulting turn-to-turn features, which we have defined as TurnEvents above, have two useful properties. First they more adequately distinguish similar road phenomena, and thus they reduce the number of collisions in the hash table.
Second, because included in each feature itself is the distance from another, moving from TurnEvent to TurnEvent forms a near 5 transitive closure on the Ways in the map data. This fact will be used to threshold the likelihood that a sensed TurnEvent corresponds with a prior hypothesis.

Description
The RoadMapHash algorithm proceeds as follows.
Find Sharp Jogs Every Turn consists of at least one Sharp Jog. A Sharp Jog is a jog with a curvature above a specified threshold.
Find Turn Entry Jogs Every Turn has an Entry Jog and an Exit Jog. The entry and exit could be the same Jog, but not for all Turns. Consider a Turn that consists of a sharp curve going into the turn, followed by an intermediate curve of lesser but nonzero curvature, and finished with a sharp curve at the end. Such a Turn comprises several Jogs and must be identified with an approach that allows for multi-Jog Turns.
Find Turn Exit Jogs Starting with a Turn Entry as described above, Turns 5 Dead ends and u-turns are not navigable by design decision.
proceed through a series of adjacent Jogs until they reach a Turn Exit Jog, which is the last Jog of high curvature in the Turn. The goal in this step is to identify where these Turn Exit Jogs occur. This process produces completed Turns which are a combination of Turn Exit Jogs and Turn Entry Jogs, as well as the array of intermediate Jogs between them.
Set Turn Origins As mentioned in the description above, a Turn on its own is di cult to distinguish in the real world. The degree of the turn and the distance traveled to complete the turn are the most useful, and possibly only, features that can be derived from the turn. However, the combination of a turn preceded by another turn o↵ers a much richer set of data that can be both identified in a roadmap and sensed in the real world. In particular, the change in direction from the last turn, the distance traveled to the present turn, and the change in direction in the present turn can provide enough data for a geometric hash key to be specific but not result in an overly dense table. It is thus necessary to associate each Turn with an origin turn in order to create a Turn Event. This is done by a depth first traversal from the exit turn of a Turn T A to any and all entry Turns T {Entry} , within a search limit set by a configuration parameter. See Figure 11 for an example of a Turn with several origin Turns.
Create TurnEvents TurnEvents are for the basis of the geometric hash map key and are combinations of a Turn and a Turn Origin. Scaled rounding [17] is applied to map-based distance and angle displacements in order to create set of keys which are robust to the uncertainty of real world measurement.
The scale factor used here relates directly to the error variance used in the motion model. Table With TurnEvents The geometric hash table for a given area must be updated with the TurnEvents occurring in that area. The key is the string-encoded Turn pair phenomenon found in the map data. The value is the location (or optionally, several locations) where the phenomenon occurred.

Complexity Analysis
Using the Random Access Machine model of computation, we calculate up to a constant factor the worst case runtime of the RoadMapHash algorithm with only the number of Jogs in the roadmap as input size. Although this calculation relies on Jog-based data, one can also derive an upper bound on the number of Jogs within a geographic area by using only the number of Nodes. That derivation, followed by a brief time-complexity analysis of the steps of the RoadMapHash algorithm follow.

Number of Jogs in a Digital Road Map
Road map data describes a graph whose points and edges reside in a plane.
However, for a graph G to be planar not only must each node reside in the plane, but no edge may intersect with another edge. Luckily, we are given exactly that constraint as a stipulation in the OpenStreetMaps ( Proof. Each region defined by a drawing of G in the plane is bounded by a cycle if Sharp Jog Not Already Explored then 11: while DFS Each Upstream Jog J i = J i 1 ! J prev do 12: if J curvature C(J prev ) < C thresh or C(J) ⇤ C(J prev ) < 0 then if J curvature C < C thresh or C(J) ⇤ C(J next ) < 0 then for each Turn T in S T do . Set Turn Origins 27: while DFS Each Jog J prev Upstream from T ! J entry do 28: if J prev is a J exit for any Turn T i then for each TurnEvent T E in S T E do . Create Hash Table   40: Insert T E ! Signature, Location in M 41: end for 42: end function of G. If that cycle is not a triangle, we can add an edge between two opposite vertices and increase the number of edges.
We conclude then that a graph G on v vertices with the most edges will have triangles for all its faces.
Then each face has three edges on its boundary, and the number of edge-face pairs with the edge bounding the face will be 3f .
But each edge bounds 2 faces, so that the number of edge-face pairs with the edge bounding the face will also be 2e.
We deduce then that f = 2e/3, so that in this case we can write Euler's formula as v e + 2e 3 = 2 3v = e + 6 We notice also that the number of edge-vertex pairs with the vertex in the edge, is 2e and is also the sum of the degrees of all the vertices.
This tells us that the sum of the degrees of the vertices of any edge maximal planar graph on v vertices obeys: The sum of the degrees of the vertices of G is 2e or 6v 12.
The average degree of a vertex of G is therefore, 6 12/v. With this important observation as a basis, we can then draw the following conclusion about the greatest number of Jogs in a Roadmap. Proof. Choose any node n in the roadmap G. Let N in be the set of nodes adjacent to n which define edges in-bound to n, and let N out be the set nodes with edges out-bound from n. By Definition 2.2 of a Jog, the number of Jogs central to n is the size of the set of ordered pairs (N in ⇥N out ) C, where C = {(n in , n out )|n in = n out }, and C is then equal to the intersection N in \ N out . So we have that <= |E| 2 , where E is the set of edges in G (4) as well.

Set Turn Origins As lines 26 through 32 in Algorithm 2.5.1 indicate, Setting
Turn Origins is a process nearly identical to Finding Turn Entry Jogs, and its asymptotic cost is proportional. So we have for each Turn (of which we have O(N 2 )), we must search the space of Jogs once more. This step thus requires O(N 3 ) time with input size N given by the number of Nodes in the roadmap data. Note that this is consistent with the complexity analysis provided by Wolfson and Rigoutsos in [21], where regarding classical geometric hashing the authors claim that In general, if • The database contains M known models, each comprising n features, • The scene during recognition contains S features, and • c features are needed to form a basis, then the time complexity of the preprocessing phase is O(Mn c+1 ). [21, pg. 15] In this research, the number of Turn features we use is 2, and our preprocessing phase is dominated by a O(N 3 ) operation.
Create TurnEvents As seen in lines 34 through 37 of Algorithm 2.5.1, creating "TurnEvents", or the key-value pairs to be inserted in the hash table is an operation propotional to the number of Turn-TurnOrigin combinations found. This is bounded above by O(N 3 ), and because inserting into an ordered set is a O(1) operation, this operation is also bounded by O(N 3 ) for N Nodes in the roadmap 7 .

Create Hash Table With TurnEvents Inserting into a hash table is a O(1)
operation and this is also linear over the set of O(N 3 ) TurnEvents.
We remind the reader that in considering the runtime of RoadMapHash as a function of the number of input nodes, we do constrain the search for Turns and TurnEvents geographically. This is intuitive because a real-world turn event could not span across continents, for instance. Similarly, we constrain the search of Turn pairs (and thus TurnEvents) to be within the extent of a configured search radius, nominally 10 kilometers. Thus the runtime of the entire system becomes linear with respect to the total number of these search extents, as defined by the geographical area we wish to cover. See Figure 12 for an illustration of this distribution.

Distributed RoadMapHash
The RoadMapHash algorithm has been parallelized to the extent that it makes nearly maximum use of eight virtual cores. However, the vast data processing demands of the RoadMapHash system exceed the computational capacity of a single consumer PC. In order to further parallelize the RoadMapHash system, it must be distributed across multiple computational units. This section will discuss how the RoadMapHash system has now scaled horizontally as well as vertically.

Phases of Parallelization
Below is a brief summary of the RoadMapHash data processing algorithm, which can be broken down into four key phases.
1. Raw Data Download. The unprocessed data in the form of OpenStreetMaps's version of XML, known as OSM, is downloaded from public servers. These servers also provide some data filtering, such as limiting the type data only to larger, arterial roads, for instance.
2. Jog Assembly from Nodes and Ways. The unprocessed data is a set of nodes and a set of linestrings, known in OSM as Ways. In order for the curvature based RoadMapHash algorithm to quickly traverse the roadmap graph in search of curvatures, this data is reassembled into three-node sets called Jogs.

Turn Search and Turn Pair Matching. Once the set of Jogs is available,
RoadMapHash can determine where in the road network turns can be sensed by an inertial measurement unit and a speedometer. These turn features need not simply be Jogs with high curvature; rather, they must be uniquely identifiable with sensors. Thus locating "Turns" is somewhat more complicated and requires traversing the Jog graph extensively. Additionally, each Turn is paired with another Turn by means of calculating the distance and change in heading between the two. This is done in order to further distinguish Turn features to spread out the lookup table. Table Updating. When the Turn features are discovered, they each provide a unique turn signature and a set of coordinates to the location of the turn. This key-value pair is entered into a MongoDB database by means of batch uploading, and in turn upserting, JSON documents over the Internet. This is the "Reduce" phase of the MapReduce process.

Distributed Implementation
Before the implementation of a distributed architecture, RoadMapHash had been implemented in C++ without a command line interface. Raw data was acquired before execution and processed hash tables were uploaded to the database one at a time with a manually executed script. Additionally, the actual data processing, comprising the second and third phases of the RoadMapHash algorithm, was performed by one machine on the same set of data from start to finish. This following implementation provided opportunities for improvement using distributed parallelization. Note that the parallel decomposition relies on two variables: the number of servers as well as the number of map segments (and thus client threads).
Overall Workflow 1. Divide the map area into X equal sized rectangloids (not quite rectangles because they are segments of the surface of an ellipsoid).

Provision N RoadMapHash worker servers.
3. Allocate the X segments to the N servers to do work.
As mentioned above, the RoadMapHash algorithm itself is implemented in C++ and uses LLVM C++ standard library threads (std::thread) in order to parallelize work within each task.
• Go. The workers serve a web service written in Golang. There are REST endpoints corresponding to the functions of the RoadMapHash algorithm.
There is not currently seamless integration between the RoadMapHash algorithm and this web service. Rather, the binary 'rmhash' utility is called as an external process and the file system is used to poll the completion of each file.
• Python. The distributed worker driver is written in Python with the Requests library used to perform HTTP requests on the servers. The workflow described above is implemented in Python and extends the 'threading.Thread' class in order to achieve parallel computation there.
• Docker. This project made use of Docker containers in order to deploy the web application. A future goal of the research will be to orchestrate these containerized services with Kubernetes.
• Cloud Resources. This project made use of virtual compute resources from Microsoft Azure and Amazon Web Services.

Results
The results in Figure 13 show that the greatest speedup gained was approximately 2, when four map sections were processed. This is the result of a 1:1 map section-to-server ratio, and the fact that each server had to download map data.
This bottleneck at the data download process created a linear time overhead in the number of map sections, probably due to the slow down caused by multiple HTTP requests and file handling. In general, however, the distributed architecture shows promise. With 4 servers and 4 map sections, the distributed RoadMapHash algorithm achieved a 1.90x speedup over a single machine working on a single map section of the same area. This is consistent with the possibility that there is an optimal coverage area that will balance the speedup gained in parallel processing maps against the slow down caused by multiple data downloads and file operations.

Directions for Further Improvements
As mentioned above, the integration of the RoadMapHash algorithm with the web API could be improved by making direct calls on a linked library as opposed to making system calls to a binary executable, and then polling for completion.
Additionally, as mentioned in the results, the map data could be downloaded in segments of optimal size because the downloads against the OSM server took a significant portion of the within-worker time. Finally, the current system does not yet implement the "Reduce" phase of the MapReduce workflow. That is, the data is not yet merged back into a central data source. The scheme by which this data will be merged must also be carefully considered. Because lookup tables for each sub-region of the map may adequately describe a search space, each could be independently useful to delineate the data result between service regions.

Tracking Phase: RoadMapTrack
The RoadMapTrack algorithm is the second subcomponent of the overall RoadMapLocate system. Its purpose is limited and is designed operate on an embedded system with as few features as necessary to record sensor data and perform minor arithmetic calculations for final computation by another device. Ultimately, RoadMapTrack will provide estimates of path displacement U t , change in head- . Radius of Curvature return ( U t , ✓ t , R curvet , ⌧ t ) 8: end function 2.7 Localization Phase: RoadMapFilter Algorithm In order to accurately estimate the pose of the vehicle 8 we must review some of the arithmetic performed by the RoadMapTrack subcomponent.

Motion Model
Di↵erential odometry is commonly used in two-wheeled robots and vehicles with di↵erential drive in general. Here we use the di↵erential drive model described in [22, pg. 19] coupled with the odometry motion model described in [23, pg. 95]. State updates from the wheel speed sensors are interpreted as changes in position of the left and right wheels respectively. In the following description of our model we refer to the "pose" of the vehicle, Equation 6 as a three dimensional vector corresponding to its horizontal translation, vertical translation, and change in bearing from a previously known pose X t k 1 . This distinction is important for further discussion because we uniquely expand on the need for a single vehicleintrinsic coordinate frame by updating this reference frame at each measurement event k.
We now look at the motion model which is similar to those used in [22] and [24]. The di↵erential odometry model presented by Borenstein et al. describes a vehicle whose left drive wheel moves U L and whose right drive wheel moves U R . Borenstein's model describes x, y, and ✓ displacement as a function of these updates.
As in [22], the vector represented by U t k refers to a the control vector. Although we discuss the control vector to remain consistent with the terminology used to describe control theory in general, we point out that the measurements amounting to this control are taken after the fact in our input-free system. As in [22], we similarly use the convention of a positive D t k to refer to forward motion and a positive ✓ t k to refer to counter-clockwise rotation. One distinction to be made is that we do not refer to the subscript t to be a global time elapsed since the process began; rather we intend to refer to the time t k as the time instant since measurement event k, which itself refers to the time of an update event as prompted by recognizing a road feature. However, because t k is cumbersome, from here forward, we will refer merely to the time t.
In considering the di↵erential drive, we describe our update vector as Equa-tion 7.
These updates in path and heading change relate to our state vector with the di↵erential drive system described in System 8 [23], [24].
Finally, the system state vector can thus be written as X t = [x t , y t , ✓ t ] ⌧ , the update vector as U t = [ D t , ✓t ] ⌧ , and the function vector

Uncertainty
In Equation 7 we give the relative orientation given by di↵erence in change in distance of the left wheel D tL and change in distance of the right D tR , where b is the distance between the left rear wheel and the right rear wheel [22] 9 . However, because the wheel speed sensors are error prone, and the e↵ects of odometric error are cumulative, we model the true control vector as System 9.
In the literature an error in the observed or commanded change in heading ✓ is occasionally modeled as a triangular distribution [23]. This model is suitable for skidsteer vehicles and in robots with actual di↵erential drivetrains, where the data generating process is a control on the degree of z axis twist, and ultimately produces an "arc" of uncertainty. In [25] and [23], once the vehicle proceeds forward after a change in rotation (or some sequence of similar infinitesimal movements) the error in rotation should be considered from the perspective of z axis rotations followed by forward movement.
However, here the data generating process is not control on the vehicle's differential drivetrain, rather, we passively collect wheel speed sensor data gathered from both rear wheels. The error for this data needs to be modeled accordingly, and we plan to implement an exponential parametric error system, describing uncertainty in translation and rotation, as in [26]. In [26] the authors use a learned parametric exponential model to test goodness-of-fit between range measurements and model values. Figure 16 shows the rule set used to determine whether a vehicle traveling on a road of known curvature is in a turn or out of a turn. This finite state machine is designed to threshold two levels of curvature. One is for maintaining a turn state, when for example a vehicle travels a slightly curved portion of the road, but returns to a straightaway. The second is a threshold after which the vehicle is considered to be in a turn, which is nominally a turn radius of 15 meters. This two-phase turn state process allows for vehicles to move with variance in road curvature without overfitting too many turn events to the sequence of input.

RoadMapFilter
For the third phase of RoadMapLocate, we propose a sequential Monte Carlo estimation process similar to the particle filter. The system should best approach the ones specified by [27], [26], and [28] where estimates are probabilistic over a set of hypotheses, and in some cases, the measurement phase requires adjustment to the standard particle filter. Algorithm 3 sketches a possible method. Missing however, is the incorporation of assigning probabilistic weights to the hypotheses.
As mentioned above in Motion Model, we suspect that the error models in [26] will serve as a guide for this. Additionally, because the virtual measurements from the hashtable may be multiple and very di↵erent, we further propose using the gating technique in [27]. This is reflected in line 16 of Algorithm 3.
Algorithm 3 RoadMapFilter 1: function RoadMapFilter(X 0 , X , u t ) 2: for i = 1 to Len(X t ) do . Loop over Hypotheses 5: if Turn feature k detected from u t then 8: . Virtual Measurements 9: for i = 1 to N do 10: Sample from X t with replacement 11: end for 12: for j = 1 to Len(z t ) do . Loop over Candidates

13:
Add z j to X t . New Hypothesis 14: for i = 1 to Len(X t ) do . Loop over Hypotheses 15: if x i ⇡ z j then 16:       Table  CHAPTER 3 Testing Proposal Below we discuss an experiment design for the RoadMapLocate system. The experiment will be tested o↵-line after recording GPS coordinates and logging ABS Wheel Speeds and timestamps from the CAN bus of a consumer vehicle.
In order to carry out the RoadMapTrack and RoadMapFilter phases of the overall RoadMapLocate system, experimental data must be generated from rear wheel odometry over course where OSM data is available. The Arduino-bound RoadMap-Track system will record this data for analysis o✏ine. For a real-world control, we will use GPS and network location estimates taken from the Android operating system interface. After processing the odometry data with RoadMapFilter, we will analyze the results along the Performance Criteria stated below.

Performance Criteria
The most common performance measure is the physical distance between position estimates and a "ground-truth" position, which is usually measured by a GPS device or corrected GPS track. We certainly care about that measurement here, but there are several additional measures we will consider as listed below.

Extent of Map
In the literature, the test map is usually only large enough to contain the entire test track, and occasionally the size of the state space itself may not even be cited as a relevant performance criterion. However, the extent of the search on which a successful map-based localization strategy is performed is possibly the second most important measure of performance. Bigger map is better performance.
Computation Time We will benchmark each of the RoadMapLocate subcomponents on their respective hardware. RoadMapHash, executed on on an Intel I7 (6th Gen) with 32GB RAM time, should be evaluated for runtime as a function of N nodes in the roadmap. RoadMapTrack, executed on an ATmega328 with 2KB RAM, should be evaluated mostly for the speed of I/O operations. We are specifically interested in Bluetooth transfer rate. Finally, we expect RoadMapFilter to be run on a 1.6GHz quad-core Qualcomm Snapdragon 821 processor with 4GB of RAM, and we will estimate each particle update period in seconds.

Initial Position and Latency
We want to quantify the necessary number of features recognized in order to accurately determine a position. This will be a function of map extent as well as the distribution of initial hypothesis across that extent.
Data Size This is related to the extent of map necessary for localization, but in this case, we seek to determine the geographical extent that could be stored on a consumer SD card so that the mobile device need not have Internet connectivity.
Current estimates show that for an extent of approximately 100 square kilometers (Aquidneck Island) the required storage is 74KB. Assuming the rest of the 9 million square kilometers in the United States have similar road density, this translates to an estimated 6.5GB of storage space for the entire U.S. 1 CHAPTER 4

Conclusions and Future Research
Most map data-based localization strategies only tacitly recognize curvature as a road's fundamental feature. This research, in addition to developing recognizable turn features in the RoadMapHash algorithm, also contributes a unique technique to characterizing an entire roadmap based on an instinctual turn-byturn approach to navigation. With modern sensors, small form factor computers, and a distributed computation environment, the success of the fully implemented RoadMapLocate technique is realistic in the near future.
Future research may pertain directly to the performance criteria listed in the Testing Proposal. However, we make acknowledge several additional items we would like to consider.

Data
The road features extracted from curvature can be augmented including the change in altitude between turns. This could reduce the load factor in the hashtables. Along that vein, road slope can be included when calculating feature keys so that distances covering any elevation during a real world drive will be more accurately represented than in the current flat Earth model. Additional road peculiarities, such as road surface width or speed limits might be of value.

Algorithmic Analysis
The majority of the work here concentrated on RoadMapHash, but the other components of the RoadMapLocate deserve significant analysis also. Because the error of each wheel speed is modeled as zero-mean Gaussian, we must derive the propagated error in the ultimate motion model, which includes sine and cosine functions, as a specific exponential probability distribution. Additionally, the scaled rounding technique used in RoadMapHash to determine how to round lookup keys must be properly parameterized, and adequately reflect error distributions in distance and heading changes.

Application Environments
The current operating environment for the RoadMapLocate system is a consumer vehicle with rear wheel speed sensors. However, we recognize several applications that could benefit from this research. For instance, visual odometry, performed either from a land-based or aerial platform, could identify road segments and benefit from the virtual measurements provided by RoadMapHash as well. Indoor navigation o↵ers similar constraints as road-bound navigation and may benefit from a similar strategy. Finally, navigation in mines and tunnels, where GPS signals cannot travel but which may be entirely charted, could benefit from this strategy. [1]