{'fraction_non_alphanumeric': 0.030332612788508472, 'fraction_numerical': 0.011017362805941008, 'mean_word_length': 4.832452216348109, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Ford Highway Driving RTK Dataset: 30,000 km of North American Highways

There is a growing need for vehicle positioning information to support Advanced Driver Assistance Systems (ADAS), Connectivity (V2X), and Autonomous Driving (AD) features. These range from a need for road determination ($<$5 meters), lane determination ($<$1.5 meters), and determining where the vehicle is within the lane ($<$0.3 meters). This paper presents the Ford Highway Driving RTK (Ford-HDR) dataset. This dataset includes nearly 30,000 km of data collected primarily on North American highways during a driving campaign designed to validate driver assistance features in 2018. This includes data from a representative automotive production GNSS used primarily for turn-by-turn navigation as well as an Inertial Navigation System (INS) which couples two survey-grade GNSS receivers with a tactical grade Inertial Measurement Unit (IMU) to act as ground truth. The latter utilized networked Real-Time Kinematic (RTK) GNSS corrections delivered over a cellular modem in real-time. This dataset is being released into the public domain to spark further research in the community.


INTRODUCTION
Autonomous vehicles and a growing number of increasingly automated driver assistance features push requirements for progressively increasing positioning accuracy [1]. Today, Global Navigation Satellite Systems (GNSS) are used to provide position information as a driver navigational aid. This provides an attractive solution, as it offers global positioning using relatively lowcost hardware with lightweight computational load. In recent years, accuracy and robustness have increased, thanks to the availability of substantially more GNSS satellites, multiple civil frequencies such as L5, multi-frequency capable mass market receivers, and continental-scale coverage of corrections services like networked Real-Time Kinematic (RTK), Precise Point Positioning (PPP), and other model based approaches such as PPP-RTK [2].
One of the challenges facing adoption of RTK and other precision GNSS solutions in next-generation automotive systems is understanding the environment that vehicles will be operating in, as this could potentially be used as a core component of a safety critical system. General Motor's (GM) Super Cruise is an example use of GNSS as a core input to the feature activation criteria, only allowing the feature to be active on divided highways [3]. In order to address the integrity of such a system, the GNSS conditions on roads in terms of service denials must be understood. Some of the factors that affect the performance of GNSS and RTK use on highways include obstructions (e.g. overpasses and overhead signs), Radio Frequency (RF) interference (unintentional or otherwise), and reliability of cellular connectivity to receive the corrections. Characterizing these factors requires real-world driving data that is geographically diverse covering rural, urban, and highway driving over a large number of kilometers.
Here, we present the Ford Highway Driving RTK (HDR) dataset, an open source dataset intended for the navigation and self-driving research community to help answer these questions. This data was collected as part of a larger campaign used to develop and validate other vehicle features. While this experiment was not designed with GNSS analysis in mind, the data still allows for insights into the current highway environment for GNSS performance. An analysis of this data was presented previously by Ford in 2019 [4].
Such a large scale GNSS dataset has not been released publicly before. There are a few detailed datasets specifically for GNSS applications, but they are available only at a much smaller scale. For example, in 2019, Humphreys et al. released a 2-hour GNSS dataset of urban driving in Austin, Texas [5]. There are a number of Autonomous Driving datasets available, but they generally are focused on components of Autonomous Driving such as perception and do not have much in the way of GNSS-specific data, often providing post-processed GNSS + IMU data as ground truth only. These include Argoverse [6], Apollo [7], KITTI [8], the Canadian Adverse Driving Conditions (CADC) [9], and the Ford multi-agent seasonal [10] open datasets . The authors hope to further the trend of the industry to share more data and enable other researchers to gain additional insights beyond the basics of accuracy, availability, and continuity.
This paper provides a detailed description of the data collection, the dataset itself, and provides some example analyses. We close with some open questions to the research community that this dataset can either help answer or that can inform future Ford open datasets or data collection campaigns.

DATA COLLECTION
The GNSS data presented here was part of a larger data collection campaign used for the development and validation of other vehicle features. This particular dataset was driven in mid-2018, primarily targeting the population centers of the east and west coasts of the U.S. and Canada on the route shown in Figure 1. Two separate vehicles were used in the data collection, one on each coast. The experiment design and hardware setup were largely the same on both vehicles. A high-level overview of the data collection vehicle is shown in Figure 2.
A total of 27,500 kilometers (17,088 miles) was driven, representing 355 hours (∼15 full days) of data. This was mostly highway driving although some of the route did pass through major urban centers. It also includes a wide variety of highway environments, including challenging mountain roads. To put this number of miles in perspective, the U.S. National Highway System (NHS) consists of approximately 350,000 kilometers (220,000 miles) of road. Hence, the data shown here represents roughly 8% of the NHS.
Two separate GNSS systems were used in data collection, one representative of that used in production vehicles today and the other a survey-grade system to act as a reference or ground truth. The production-oriented GNSS was automotive grade, multi-constellation capable (GPS + GLONASS + Galileo), and utilized the L1 frequency only. The survey-grade system was an Oxford Technical Solutions (OxTS) RT3000. The RT3000 Inertial Navigation System (INS) combines two survey-grade GNSS receivers with an Inertial Measurement Unit (IMU) to provide the ability to coast through reasonable GNSS outages. The RT3000 units used in this experiment were GPS + GLONASS and capable of tracking both the L1 and L2 frequencies.
The MEMS IMU is tactical grade with a gyro bias stability of 2 degrees / hour. The two GNSS receivers are used to constantly  calibrate the attitude of the RT3000 IMU, primarily to provide heading.
Networked RTK corrections were also used in this experiment. Cellular connectivity was available on the vehicle and corrections were delivered to the RT3000 via an RTK Bridge-X modem from Intuicom Wireless Solutions. The networked RTK corrections were provided by Hexagon's SmartNet, where coverage was available along the entire data collection route.
Both systems provided high level GNSS information including UTC time, latitude, longitude, altitude, number of satellites tracked, and Dilution Of Precision (DOP). The production GNSS data was collected at 1 Hz and the RT3000 at 30 Hz. The RT3000 also output several other parameters related to the full inertial navigation solution including attitude (roll, pitch, heading), position mode (RTK fixed, RTK float, differential code, Standard Positioning Service (SPS), or no service), age of differential corrections, and the 1σ uncertainty of the position solution.

DATA DESCRIPTION
This dataset is available as set of * .csv files, shared on the Ford GNSS data website (currently at http://ford-hdr-gnss. s3.amazonaws.com/ford-hdr-gnss.zip). Each file consists of an array of data with a header line that contains the field names.
The first of these fields is geohash, a unique identifier for each 4.8x4.8 km tile that uses a 5 character Morton code. As an example, Figure 3 shows the tiles for the San Francisco Bay Area in California. A complete map showing all the tiles is included with the dataset. The geohash tiles in Washington and part of Oregon begin with c. The rest of the tiles in Oregon, California, Texas, and Louisiana begin with 9. The bulk of the east coast tiles begin with d, all the way through Detroit, with the exception of the tiles in Quebec, which begin with f . As described above, there are two GNSS systems in the vehicle. The fields associated with the production system are preceded by a P , such as P GPS Heading. Those from the OxTS RT3000 are preceded by an R, such as R AngleHeading.
There are a few fields worth noting from the production GNSS system. The P GPS timestamp field is formatted as yyyymm-dd hh:mm:ss. The field for the number of satellites, P GPS Sat num in view, represents an expected number based on the constellation geometry, rather than the actual number being tracked by the system. P Gps B Fault describes if there is a fault in the production GNSS system, with 1 representing a fault state, and 0 representing no fault. P Latitude and P Longitude are for the reference point on the vehicle, which is represented on the ground at the centroid of the vehicle.
To keep the dataset a manageable size, the data fields from the OxTS RT3000 INS were down-sampled to 1 Hz to match the data rate for the production system. The nearest timestamp from the original 30 Hz recording is shared in the R RT3k timestamp field, which is formatted as yyyy-mm-dd hh:mm:ss.ddd. Many of the included fields from the RT3000 are related to the velocity and acceleration from the IMU, and are defined by the frames described in Section 3.1. Additional information about the OxTS RT3000 outputs can be found in the manuals provided by the manufacturer [11,12].
The only field (other than geohash) that is not specifically for one system or the other is D Dist m. This represents the distance between the Lat-Lon position of the two systems, reported in meters. This was calculated directly from the fields shown here, and thus does not account for the difference in reference points. The distance between the reference points can be calculated by estimating the lever arm between them [4].

OxTS Frames
As described in the OxTS user manual for RTv2 GNSS-aided inertial measurement systems [12], three frames are used in this dataset. The first is the global North-East-Down (NED) navigation frame. The OxTS navigation frame is attached to the vehicle but does not rotate with it. The Down axis is always aligned to the local gravity vector and North always points towards geodetic North. The fields in this frame are labeled with North, East, or Down, such as R VelNorth.
The second frame is the OxTS local horizontal frame. The OxTS horizontal frame is attached to the vehicle. The longitudinal and lateral axes remain parallel to a horizontal plane. The fields in this frame are labeled with Lateral, Forward, or Down, such as R VelLateral. Down for both the NED navigation frame and the horizontal frame point in the same direction.
The final frame is the vehicle frame. The OxTS vehicle frame is attached to the vehicle and rotates with it in all three axes. The X-axis remains parallel to the vehicle's heading, while the Y-axis points to the right and is perpendicular to the vehicle's vertical plan of symmetry. Fields in this frame are labeled with X, Y, or Z, such as R AccelX. All of the OxTS frames have their origin at the center of the rear axle of the vehicle.

EXAMPLE USAGE
Already, some analysis has been performed on this dataset, and findings for on-road GNSS accuracy, availability, and continuity were presented previously in [4]. Availability and continuity were broken down in terms of satellite visibility, satellite geometry, position type (RTK fixed, RTK float, or SPS), and RTK correction latency over the network. The results showed that current automotive solutions capable of meeting road determination requirements, but are not suitable for lane determination. A system using multi-frequency multi-constellation receivers with a correction service substantially increases capability. An example of the sorts of insights that can be gained from this data can be seen in Figure 4. The R GpsP osM ode field is shown here in the San Francisco Bay Area. The difference between the sky view of the San Mateo Bridge and the Richmond-San Rafael Bridge (eastbound) can be seen in the resulting RTK mode. Along the San Mateo Bridge with an unobstructed sky, the RT3000 maintains RTK integer (fixed) positioning mode, while on the lower deck of the Richmond-San Rafael Bridge with a heavily obstructed sky view, it bounces between SPS and no service at all. Further insights could be gained by looking in closer detail at other locations where the system loses RTK positioning.

DISCUSSION AND CONCLUSION
The Ford Highway Driving RTK dataset represents a first in terms of large scale automotive GNSS data being publicly available. While this dataset has been evaluated for insights into GNSS performance on highways [4], the collected data was not intended for that use, and future data campaigns could be encouraged to make changes that enable additional GNSS-specific analysis. These could include usage of more recent GNSS hardware, particularly in terms of multi-constellation and multi-frequency elements; recording additional data types such as pseudorange or carrier phase; and extending into other road types, such as urban or rural settings. In the future, an equivalent dataset that includes urban centers could be used to compare expected and measured performance due to occlusions and multipath effects, providing validation for algorithms such as shadow matching.
The hope of the authors is that other researchers will glean additional insights from this dataset. For example, combined with a map of overpasses and overhead signs, the locations where RTK-fixed mode is lost can be evaluated more extensively to understand if all such instances are due to environmental geometry or if there are other factors at play, such as other vehicles making use of Personal Privacy Devices (PPDs).

ACKNOWLEDGEMENTS
The authors would like to thank Ford Motor Company for supporting this work.