Mobile device sensing: final report [Apr. 2012]

GDOT Research Project No. RP 10-27 Final Report
Mobile Device Sensing
EXPLORATION OF THE USE OF SENSORS IN MOBILE PHONES TO ASSIST GDOT IN CONDUCTING MAINTENANCE AND MANAGEMENT ACTIVITIES

GDOT Research Project No. RP 10-27
Mobile Device Sensing
Final Report EXPLORATION OF THE USE OF SENSORS IN MOBILE PHONES TO ASSIST GDOT IN CONDUCTING MAINTENANCE AND MANAGEMENT ACTIVITIES
By Wayne Daley - Principal Research Engineer
Sim Harbert Senior Research Engineer Ai-Ping Hu Senior Research Engineer James Matthews Research Engineer II
Jay Zuerndorfer Coop Student Matt Giannelli Coop Student Georgia Tech Research Institute Georgia Institute of Technology
In cooperation with
U.S. Department of Transportation Federal Highway Administration
April, 2012
The contents of this report reflect the views of the author(s) who is (are) responsible for the facts and the accuracy of the data presented herein. The contents do not necessarily reflect the official views or policies of the Department of Transportation of the State of Georgia or the Federal Highway Administration. This report does not constitute a standard, specification, or regulation.

`
Acknowledgements
The researchers would like to acknowledge the assistance of the GDOT Research, Office of Design Policy and Support, Maintenance and IT departments that provided support for the work described in this report.
i

`
Abstract
GDOT (Georgia Department of Transportation) engineers and other transportation professionals regularly require a variety of data that describe the conditions of the roadway infrastructure to support a variety of operations such as planning, design and maintenance. The ability to collect data cost effectively through the use of a Smartphone for example could make them more efficient in conducting many of these operations through earlier notification at reduced costs. In this work it is shown that is possible to gather much of the needed data and with the appropriate tools to aid in analysis it could prove useful in many GDOT operations. Using accelerometer data for example it is shown that there are correlations for example between IRI (International Roughness Index) and PACES (Pavement Condition Evaluation System) data which are tools currently used for some GDOT operations. Evaluation of roadway acceleration profiles as the vehicle is driving could also provide feedback on the performance of the roadway design. The current generation of Smartphones also provides the ability to estimate the geometrics of roadway segments that could be useful in matching design to specifications as an example and also to evaluate the ride from roadways using measures that compare directly to what drivers experience. Through the estimate of Whole Body Vibrations (WBV) techniques for assessing the effectiveness of control devices such as rumble strips could be developed that tie to the human hearing and vibratory impact experienced by the passengers.
It is also shown that normalization techniques could be used to account for the effects of different vehicles and mounting types.
ii

` It appears that Smartphone data acquisition and analysis as an addition to the Transportation Engineers toolbox could provide timely information to support maintenance, design and planning activities.
Key Words
Smartphone data acquisition, Maintenance Support, Design Support, IRI, PACES, Whole Body Vibrations, accelerations, gyroscopes.
iii

`
Table of Contents
Acknowledgements .......................................................................................................................... i Abstract ........................................................................................................................................... ii Key Words...................................................................................................................................... iii List of Tables................................................................................................................................. vii List of Figures .............................................................................................................................. viii Introduction ..................................................................................................................................... 1
Problem Description.................................................................................................................... 1 Literature Review ........................................................................................................................ 2 Procedure......................................................................................................................................... 3 Apparatus..................................................................................................................................... 4 Hardware ..................................................................................................................................... 5 Software....................................................................................................................................... 6
Phone Software (Upload and analyze for view on device)...................................................... 7 Workstation Software (Python code: Run on any platform) ................................................... 7 Findings ........................................................................................................................................... 9 Mounting ..................................................................................................................................... 9 Position accuracy test ............................................................................................................ 11 Parameters to be estimated using phone.................................................................................... 12 Features for data analysis ...................................................................................................... 13
iv

`
Normalization of responses ................................................................................................... 18 Geometrics..................................................................................................................................... 22
Roll and Pitch Measurement ..................................................................................................... 22 Curvature Detection .................................................................................................................. 31 General Tool for Assessment ........................................................................................................ 34
Acceleration Profiles ............................................................................................................. 34 Conclusions and Future Work ....................................................................................................... 39 References ..................................................................................................................................... 41 Appendices .................................................................................................................................... 42
Appendix A ............................................................................................................................... 42 Droid X Specifications .......................................................................................................... 42 Definitions ............................................................................................................................. 42
Appendix B................................................................................................................................ 43 XSens Specifications ............................................................................................................. 43
Appendix C................................................................................................................................ 46 Specifications on the GPS accuracy tests .............................................................................. 46
Appendix D ............................................................................................................................... 47 Benchmark Specifications ..................................................................................................... 47
Appendix E................................................................................................................................ 49 GDOT Mobile Sensing Analysis Software Instructions Introduction ................................... 49 Mobile Phone Software ......................................................................................................... 49 v

` KMLgenerator.exe................................................................................................................. 50 plot_circle_radius.exe............................................................................................................ 51 StdDevThreshold.exe ............................................................................................................ 52 To view KML files in Google earth: ..................................................................................... 53
vi

`
List of Tables
Table 1 PACES/IRI ratings at sample sites ................................................................................... 16 Table 2 Curvature Computations.................................................................................................. 34
vii

`
List of Figures
Figure 1 Block diagram of overall system....................................................................................... 4 Figure 2 Mounting for Phone, XSens, Laptop in Van.................................................................... 6 Figure 3 XSens and Phone showing coordinate systems ................................................................ 6 Figure 4 User interface (UI) for data acquisition on Droid Phone .................................................. 7 Figure 5 Z axis response of different mounting types ................................................................... 10 Figure 6 X axis response of different mounting types................................................................... 10 Figure 7 Benchmark at Carnegie Building on GT campus (USGS J4/1916 Elev. 979.808 feet) .. 11 Figure 8 GPS Benchmark position accuracy ................................................................................. 12 Figure 9 Accelerometer Z data US 78 E........................................................................................ 13 Figure 10 Sample Sites for the collection of PACES/IRI data ...................................................... 15 Figure 11 Newly paved segment of roadway (I-75/85 south of Atlanta before split) ................... 16 Figure 12 PACES with acceleration standard deviation (y- PACES rating, x-std. deviation of z acc. over segment) ......................................................................................................................... 17 Figure 13 IRI comparison with acceleration standard deviation (y- IRI rating, x-std. deviation of z acc. over segment) ......................................................................................................................... 18 Figure 14 PACES with smooth road reference (y- PACES rating, x-number of ref. std. dev. of z acc. over segment) ......................................................................................................................... 19 Figure 15 IRI with smooth road reference (y- IRI rating, x-number of ref. std. dev. of z acc. over segment) ........................................................................................................................................ 19 Figure 16 WBV Old vs. new road surface (Y-axis m/s^2, X-axis sample numbers) .................... 21 Figure 17 WBV Correlations with IRI (Blue - IRI 998, Red IRI 864) y-sum of WBV over segment, x- sample numbers ......................................................................................................... 21
viii

`
Figure 18 Site of dynamic testing in NARA Research Area at Georgia Tech .............................. 23 Figure 19 Elevation profile for the test area .................................................................................. 23 Figure 20 Pitch in degrees at test points on NARA road segment ................................................ 24 Figure 21 Correlation for XSens Pitch measurement vs. Electronic level .................................... 25 Figure 22 Correlation for phone vs. electronic level ..................................................................... 25 Figure 24 Correlation XSens in vehicle vs. electronic level ......................................................... 26 Figure 25 Correlation Phone Hard Mount in vehicle vs. electronic level ..................................... 26 Figure 26 Correlation Phone velcro mounted vs. electronic level in vehicle ............................... 27 Figure 27 Pitch measurements 0-5mph NARA test segment ........................................................ 27 Figure 28 Pitch measurements 5-10mph NARA test segment ...................................................... 28 Figure 29 Pitch measurement 15-20mph on NARA test segment................................................. 28 Figure 30 Measurement roll, pitch on level and inclined surface.................................................. 29 Figure 31 Average difference in roll, pitch going from level to inclined surface (std. roll and pitch 0.3 and 0.2 degrees respectively) .................................................................................................. 30 Figure 32 Radius computations using GPS and Magnetometer Data............................................ 33 Figure 33 Sample curve fit to estimate radius of curvature........................................................... 34 Figure 34 Sample run that shows an acceleration anomaly (Lateral and Transverse) .................. 35 Figure 35 Sample run that shows an acceleration anomaly (Transverse) ..................................... 36 Figure 36 Roll and pitch data collected with Droid Smartphone .................................................. 37 Figure 37 Roll and pitch data using the XSens ............................................................................. 37 Figure 38 Passing zone determination on a segment of roadway.................................................. 38
ix

`
Introduction
Problem Description
GDOT's (Georgia Department of Transportation) current method of checking travel lane quality and other maintenance parameters is expensive, time consuming and potentially dangerous. At the present time for example GDOT requires the use of a laser profileograph to test the ride quality and cross slopes is measured using survey equipment or a level. PACES (Pavement Condition Evaluation System) data collection requires stopping vehicles along the roadway and making visual observations. The ability to collect data in motion could improve efficiency and safety. The new generations of cell phones now have many sensing capabilities built in that could potentially provide much of the information required to support maintenance as well as other road design applications. A project to evaluate the use of this technology to support the above described operations for the GDOT is needed; especially as GDOT continues to look at how to streamline and improve the efficiency and efficacy of the design and maintenance operations.
We anticipate that tools developed for the Smartphone which would be installed in a vehicle so that data acquired in motion would be able to provide data that correlates with data currently generated by using more costly approaches and systems to support maintenance planning and design. This approach would be able to improve efficiency, provide cost savings while improving safety for many of the current operations that are conducted by GDOT. Specific applications that would be targeted are listed below:
Providing an easy assessment for roadway quality when investigating complaints regarding roadway conditions and other safety concerns.
1

`
Automatically inventorying current roadways (measuring cross slopes, roughness) thus helping identify problem areas earlier, and more efficiently scheduling maintenance activities.
Providing a quick quality control check for emergency repairs (culvert replacement, detecting roadway slides early, etc.)
Automating logging the location and video/photo log thus automating the process of filling out various construction and maintenance forms. This reduces the amount of effort to fill out forms and reduces the potential transcription errors. (Most of the construction and maintenance logs are written by hand and then transcribed to computers.)
The current generation of Smartphones has a suite of sensors that are accessible by programs running on the phones that could provide information to support the aforementioned activities. Specifically there are sensors for acceleration, magnetic field and GPS built into the phone. This allows us to sense not only the position of the device but also the roll, pitch and yaw as well as the forces that the device is seeing. This data can be logged and then further analyzed to determine activity of interest for various GDOT operations.
Successful implementation could provide this capability to the GDOT without significant incremental costs. A program that enhances the capabilities of these devices for use by the GDOT would improve on the suite of tools currently utilized by providing enhanced data acquisition while improving safety for the operators as much of the data could now be collected in motion in their vehicles.
Literature Review
Uses of Smartphones as sensing devices have been proposed for supporting Transportation operations in several ways. They have been proposed for pothole detection (Mednis, 2011). In addition the uses for logging pothole location as part of a network of devices have been proposed for example in (Rode, Vijay, Goyal, Kulkarni, & Arya, 2009). Other work
2

`
has been done looking at the use of electronic devices such as IMUs to monitor road conditions. These work support the idea of using the phones as they come in convenient package with many of the sensors built into the device that would provide utility for acquiring information of interest about many aspects of the transportation network.
Work has also been done looking at techniques for estimating the radius of horizontal curves. One technique utilized GPS data and showed this to be one of the more reliable approaches (Carlson, 2005). In addition accelerometer has been used to correlate road roughness to vehicle speed and whole body vibration (Kjella, 2002) which implies that it might be possible to monitor road conditions using the accelerometer that are an integral part of the current generation of Smartphones. Other work has also been done looking at the correlation of IRI road roughness data based on the effect of different types of suspensions (Misaghi, 2010). These works highlight the possibilities for using the sensor suite in a Smartphone for supporting a variety of GDOT maintenance and operational tasks.
Procedure
The goal of the overall effort was to assess the possibilities for using a Smartphone to support several operations that are conducted by GDOT personnel. In order to do this we looked at several aspects for potential use and issues with implementation. The GDOT currently uses several tools to assist in their maintenance and planning activities. These include PACES and IRI (International Roughness Index); in addition knowledge of acceleration profiles would be useful for design assessments. The main goal of the effort was the development of tools to assist the GDOT in assessing the possibilities for using the phone to support these activities.
3

` The end result would be devices and software to allow them to support these operational functions utilizing the Smartphone. This required the development of software for data acquisition on the phone along with analysis of the data on a PC. Tools to view processed data phone to help in carrying out maintenance and operational functions were also developed.
Apparatus
The block diagram in Figure 1 describes the overall proposed system and its operation.
Figure 1 Block diagram of overall system
4

`
Hardware
The devices used in the testing and evaluation were Smart Phones (2 Droid Xs running the Android operating system; a commercial IMU (Inertial Measurement Unit) and a laptop computer for data acquisition in the vehicles. Two vehicles were used that were deemed to be representative of the types of vehicles that might be used by GDOT. These were a Ford mini-van and an F150 pickup truck (by the end of the project the mini-van was involved in an accident and totaled). An IMU is capable of making the measurements in a vehicle that would be of use and interest to transportation engineers. Smartphones today have many of the same sensors which make then candidates for conducting measurements that could be useful to transportation professionals. The phone chosen to be used on the project was the Droid X. Its full specifications are presented in Appendix A but it has a suite of sensors that allow for the tracking of x, y, z accelerations, GPS position along with a magnetic compass.
A commercial IMU was also selected for comparing data acquired with the phone to what could be considered a gold standard. For this purpose we chose the XSens Mti-G. We choose this device compared to comparable devices based on its API (Application Programming Interface) and our experience with their technical support. The full specifications for this device are in Appendix B.
The installation of the data acquisition system in the mini-van is shown in Figure 2 in which a frame was attached to the frame of the vehicle to which was then attached the sensors (XSens and phones). The coordinate systems defined for both the XSens and Smartphone is shown in Figure 3.
5

`
Figure 2 Mounting for Phone, XSens, Laptop in Van
Figure 3 XSens and Phone showing coordinate systems
Software
As described in the plans, two main software elements were constructed for overall implementation. As illustrated in the block diagram in Figure 1 there are two main software elements: the software on the phone and the software meant to reside on a PC or workstation. The major function of the phone software is the acquisition of sensor data while the software on the PC is meant to provide most of the analysis and display functions.
6

` Phone Software (Upload and analyze for view on device)
The software on the phone is called GDOT Mobile Sensing and a picture of what the user interface for the phone looks like is shown in Figure 4. It allows for acquisition and storage of data along with notes related to the particular data acquisition event. In addition a picture can be taken and stored that might be significant to the data acquisition event.
Figure 4 User interface (UI) for data acquisition on Droid Phone
Workstation Software (Python code: Run on any platform) The PC software uses the files generated during data acquisition or outputs from other
analysis programs to generate what are called KML (Keyhole Markup Language a file format used to display data in Geographic Information Systems such as Google Earth) files. Utilities were developed to read in a data file and output a specially formatted CSV file for passing into
7

` KMLgenerator. Reading in data files is handled by MobileSensingAnalysis, which prepares the data from the files to be analyzed. These analysis programs can use our radius of curvature program as an example for writing out the results in a CSV file. Brief descriptions of the programs are given below.
KMLgenerator o Outputs KML file with all available data included o Optionally includes data from another analysis program via CSV file
Other analysis programs o Use MobileSensingAnalysis to read in data o Analyze data and return a CSV file for KMLgenerator to parse
MobileSensingAnalysis o Only needs to be used in analysis programs internally o Will not need to be a stand-alone EXE
The details on the operations of these programs are provided in Appendix E.
8

`
Findings
Mounting
In order to provide the most utility while at the same time provide useful data some consideration needs to be given to how to mount the device as the type of mount used could affect the readings obtained by the devices. An experiment was conducted to determine the possible effect. This was done by mounting the one of the phones on a shaker with a fixed mount and vacuum mount and stimulating it at a known frequency in the z direction. The way the vacuum mount (referred to as a soft mount) there is an arm that acts like a cantilever that serves to amplify vibration. The results for the responses are shown in Figure 5 and Figure 6 and an illustrates that undesirable modes of vibrations can be generated using some mounting techniques that could complicate analysis of the data. The z response is observed in Figure 5 and shows amplification of the z acceleration by the soft mount. Since we are stimulating in z we would not expect vibration in the x direction. This is what we observe for both hard mounts but not for the soft mount in Figure 6. This illustrated the fact that it would be necessary to be aware of the mounting techniques and their potential effect on the acquired data.
9

`
Figure 5 Z axis response of different mounting types
Figure 6 X axis response of different mounting types
10

`
Position accuracy test Whenever data was collected it was useful to know the location through the GPS coordinates. The goal of this test was to get an idea on the accuracy of the position location for logging data. A test was done to compare the ability of the different devices to locate the position of a standard USGS benchmark. The results of the initial test are shown in Figure 8. The blue dot in the middle denotes the position of a documented benchmark a picture of which is shown in Figure 7 . The yellow pin denotes the position based on the lat long data for the benchmark. It turns out that the stated accuracies for the benchmark is approximately 0.5 minutes which could account for the differences noted in the positions. According to the data for this benchmark presented in Appendix C the most recent data on its position was derived from estimates using topographic maps per the benchmark specification. The phone and the XSens were approximately 12 feet from each other and the benchmark. This would probably meet the need of many visual location operations on roadways but in some instances there would need to be route number identification to tie with the GDOT roadway or GIS segment.
Figure 7 Benchmark at Carnegie Building on GT campus (USGS J4/1916 Elev. 979.808 feet)
11

`
Figure 8 GPS Benchmark position accuracy
Parameters to be estimated using phone
The initial thoughts on using these devices were that they could aid GDOT engineers in planning, maintenance and research. The measurements and computations that are commonly used by the GDOT in different areas are shown below.
IRI Road Roughness PACES Pavement condition Cross slope, pitch/roll, super elevation Acceleration profiles Radius of curvature Passing zone We will now discuss the approaches taken to correlate phone/IMU measurements to GDOT requirements.
12

`
Features for data analysis
Once the data acquisition software was completed sample data was taken along US 78 in Atlanta between the Mountain Industrial and East Park Place exits. The z acceleration from the smart phone along this road segment is shown in
Figure 9.
Figure 9 Accelerometer Z data US 78 E
Several potentially useful elements are observed. First it appeared that the data labeled "Older Pavement" had a higher deviation in z-accelerations than the segment labeled "Newer Pavement". It also appeared that magnitude thresholds might also be used to identify the location of bridges where there were significant spikes in the z-accelerometer data at the transition to the bridge decks. This therefore seemed like one feature that might be used to characterize the surface of pavements are the z acceleration standard deviation and magnitudes.
PACES is a system used by the GDOT to make an assessment of the conditions of roadways. It requires that engineers examine segments of roadway and rate them based on identified criteria and guidelines. These ratings are then formulated into a score that provides a numerical rating that reflects the quality of the roadway and is used to assist in the scheduling of maintenance operations. The technique is somewhat subjective and requires that the engineer stop at several points on the roadway creating the possibility for undesirable interaction between workers and moving vehicles. IRI (International Roughness Index) is another measure of road
13

`
condition assessment used by the GDOT mostly at this time to determine if new construction matches design specifications. This technique requires specialized equipment which generates a profile of the road by operating a specially equipped vehicle. This profile is then used to drive a "golden car" model which produces a number which is a measure of the vertical movement of the seat in the model over a fixed distance of travel; the higher the number the worse the condition of the road surface. We will now describe the experiments and results for PACES and IRI correlations with data from the Smartphone.
GDOT maintenance personnel identified several segments of road ways that had varying PACES and IRI ratings. The locations in Newton and Jasper counties are shown in Figure 10 and the ratings in Table 1. Data was then collected using the phones and reference sensor to explore relationships between these sensors and the PACES and IRI numbers. It was found that the data obtained from the smartphone was able to distinguish between the different PACES ratings of the three roads, as shown in the graphs below. Data was also recorded at a point of interest on I-575. Some preliminary results of that analysis are shown below. Finally, data was recorded data on a section of newly paved road on I-75/85 shown in Figure 11 to be used as a reference as described later.
14

PACES Data comparison

` Japser County, Route 16

Newton County, Route 212

Jasper County, Route 212
Figure 10 Sample Sites for the collection of PACES/IRI data
15

`

Figure 11 Newly paved segment of roadway (I-75/85 south of Atlanta before split)

Table 1 PACES/IRI ratings at sample sites
Jasper County, Route 16 Newton County, Route 212 Jasper County, Route 212

PACES rating 89 73 60

Average IRI rating 763.5 980.5 1082.1

The data in Figure 12 and Figure 13 indicate that there is a correlation between the PACES and IRI data and the standard deviation of the accelerations. It also indicates that the type of mount has an effect on the data as predicted from earlier results.

16

`

100 90 80 70 60 50 40 30 20 10 0 0

PACES comparison

Xsens Phone-hard Phone-velcro

0.2

0.4

0.6

0.8

1

Figure 12 PACES with acceleration standard deviation (y- PACES rating, x-std. deviation of z acc. over segment)

The XSens is mounted directly to a plate attached to the frame of the vehicle as described earlier. Phone-hard is a phone mounted on another plate which is then clamped to the plate in the vehicle. Phone-velcro is a phone mounted to the plate in the vehicle with Velcro. The diamond shows the relationship for the Xsens, the square for the hard mounted phone and the triangle for the Velcro mounted phone. It can be observed in Figure 9 that as the PACES numbers decrease the standard deviation of the z-acceleration increases corresponding to increased roughness of the roadway. A similar relationship is observed for the IRI numbers in Figure 13 except now there is a positive correlation.

17

`

1200 1000
800 600 400 200
0 0

IRI comparison

0.2

0.4

0.6

0.8

Xsens Phone-hard Phone-velcro
1

Figure 13 IRI comparison with acceleration standard deviation (y- IRI rating, x-std. deviation of z acc. over segment)

Normalization of responses Using smooth road data from location in Figure 11 a standard unit of measurement is
computed using the standard deviation of the z-acceleration for the smooth road as a reference. New computations are then normalized to obtain the number of smooth road standard deviation for each type of mount. Using this approach to normalization it appears that the types of mount and vehicle becomes less of a factor as shown in Figure 14 and Figure 15 for both the IRI and PACES correlations. This would be one approach to account for mounting differences and vehicle types.

18

`

100 90 80 70 60 50 40 30 20 10 0 0

PACES comparison

Xsens Phone-hard Phone-velcro

0.5

1

1.5

2

Figure 14 PACES with smooth road reference (y- PACES rating, x-number of ref. std. dev. of z acc. over segment)

1200 1000
800 600 400 200
0 0

IRI comparison

0.5

1

1.5

Xsens Phone-hard Phone-velcro
2

Figure 15 IRI with smooth road reference (y- IRI rating, x-number of ref. std. dev. of z acc. over segment)

19

`
Another technique that could be used to assess the conditions of roadways is the use of a measure called `Whole Body Vibrations' (WBV) (Kjella, 2002). This approach attempts to relate the roughness of the road to the level of discomfort experienced by a human in a vehicle subject to the vertical accelerations. Whole Body Vibrations (WBV) are computed by using frequencies to which the body is sensitive. This is obtained by filtering the acceleration signals using a filter named Wk (defined in ISO 2631, 19197) that represents floor vibration due mostly to the acceleration in the z direction (defined to be perpendicular to the floor of the vehicle). The RMS (root mean square) value of this filtered signal is then integrated over a period of one second and averaged over a distance of travel and this number is used to represent the roughness of the road surface. The method for computation is shown in the Equations below where Xn is the filtered z acceleration.



) )

Where

and N is the number of points in a sample.

The effectiveness of this measure was investigated looking at sample roadway for old and

new surfaces are shown in Figure 16. In addition, correlations for roadways with differing IRI in

are shown in Figure 17. The data is for five different sample runs for two sites with average IRI

values of 864 and 998 as measured by the Office of Materials Research (OMR) vehicle. The data

represents the WBV values summed over each segment. The data implies that the WBV measure

could also be a feature derived from accelerometer data that could be a useful discriminant for

surface quality that could be correlated with IRI measurements.

20

`
Figure 16 WBV Old vs. new road surface (Y-axis m/s^2, X-axis sample numbers)
Figure 17 WBV Correlations with IRI (Blue - IRI 998, Red IRI 864) y-sum of WBV over segment, x- sample numbers
21

`
Geometrics
Roll and Pitch Measurement
The accelerometers in the phone can be used to measure the pitch, roll and yaw of the vehicle. It turns out that the readings are only valid when the vehicle is not accelerating as there is an assumption that the resultant acceleration is due to gravity. Truth data was taken using a M-D Building Products 92296 SmartTool 47-1/4-Inch Digital Electronic Level. The specifications on this device quote an angle accuracy of 0.1 degrees.
Tests were designed and executed in the North Avenue Research Area (NARA) at Georgia Tech. The course used for the test is shown in Figure 18 and its elevation profile in Figure 19. Blue push pins identify points where reference data was taken (numbered 1-24 going right to left in image). The red line shows the approximate path of the test vehicle used for the motion tests. These plots were generated using Google Earth and the corresponding GPS data generated during the testing.
The experimental procedure was as follows: 1) Mark sample points on pavement 2) Take stationary ground data with electronic level, Xsens sensor, and mobile phone
sensor. 3) Plot ground data to look at general trends 4) Examine correlation between the sensors and truth data 5) Calibrate sensors in vehicles to account for mounting offsets 6) Take data with the "van" and "truck" of the stretch of road. Data should be
stationary/moving and at speeds slow(0-10)/med(10-20)/fast(20-30) 7) Analyze the acquired data
22

`
Figure 18 Site of dynamic testing in NARA Research Area at Georgia Tech
Figure 19 Elevation profile for the test area
The stationary data was taken from 24 spots all marked on the pavement at NARA. Calibrating the phone and Xsens is done prior to collection through taking two sets of data facing opposite directions at the same location. The main focus at this point is the pitch of the road as the same sensors are used for roll. The static data for all the sensors are shown in Figure 20.
23

`
Figure 20 Pitch in degrees at test points on NARA road segment
For each of these points the correlation between the various sensors and the truth data derived from the electronic level was calculated. Two static conditions were examined, sensors on the ground, and sensors mounted in the vehicles. The results are presented in Figure 21 through Figure 25. Figure 21 and Figure 22 is with the devices just placed on the ground while Figure 23 through Figure 25 are with the devices mounted in the vehicle. The R^2 values for the vehicle mounts are higher as the placement in the vehicle did not change and only the vehicle was moved. It can be observed that there is a strong correlation between the phone readings and the ground truth.
24

`
Figure 21 Correlation for XSens Pitch measurement vs. Electronic level Figure 22 Correlation for phone vs. electronic level
25

`
Figure 23 Correlation XSens in vehicle vs. electronic level Figure 24 Correlation Phone Hard Mount in vehicle vs. electronic level
26

`
Figure 25 Correlation Phone velcro mounted vs. electronic level in vehicle
The next tests were then done with the vehicle in motion. The pitch profile for the NARA test segment obtained from the vehicles at different speeds are shown in Figure 26 through Figure 28. In motion the pitch profile as measured by the phones and the XSens begin to deviate from the true pitch profile for the segment shown in Figure 20 and gets worse with increasing speed.
Figure 26 Pitch measurements 0-5mph NARA test segment
27

`
Figure 27 Pitch measurements 5-10mph NARA test segment
Figure 28 Pitch measurement 15-20mph on NARA test segment
For dynamic conditions the gyroscopes would have to be used to sense accelerations other than gravity to compensate to make more accurate estimates of the pitch and roll. This does not appear to be the case for the generation of software that is on these phones (Unknown, GrepCode, 2012).
We also looked at the ability to measure differences in roll and pitch under static conditions as shown in Figure 29. For this test differences were measured moving from the
28

` position marked with the cones to the position of the vehicle in the middle on the incline. The average differences in roll and pitch are shown in Figure 30 where the actual data was again obtained using the M-D Building Products electronic level. The standard deviation for the roll and pitch data was 0.3 and 0.2 degrees respectively. It appears that under static conditions these devices are able to provide information that would allow for evaluation of roll and pitch and could potentially be useful for maintenance and design evaluations. In motion, the values can be inaccurate but useful data might be obtained if the vehicle is moving with constant velocity. The XSens seems to compensate somewhat for this. Utilizing the full suite of sensors in the current generation of phones (rate gyroscopes and accelerometers) could also improve on the accuracy of the data in motion but improvements in the software on the phones would have to be made to take full advantage of the additional sensors (such as rate gyros).
Figure 29 Measurement roll, pitch on level and inclined surface
29

`
Figure 30 Average difference in roll, pitch going from level to inclined surface (std. roll and pitch 0.3 and 0.2 degrees respectively)
30

`
Curvature Detection
One measurement that is of interest for some GDOT operations is the radius of curvature for a road segment. Current techniques utilize manual measurements which can be time consuming and dangerous if the roadway is operational. This could possibly be done with the Smartphone. One technique is to use the phone to log the lat/long coordinates of the curve and to then estimate the radius of curvature. Several approaches are explored below in which the site is shown in the picture with the numbers calculated using the different techniques in the adjoining columns.
Google Earth and GPS calculations 1. Choose three points along the curve 2. Convert longitude and latitude to radians 3. Use the following equations to convert to x, y coordinates X = (Radius of Earth) * (Lon2 Lon1) * cos(Lat1) Y = (Radius of Earth) * (Lat2 Lat1)
Calculate radius of circle using formula given by following reference (Unknown, Circle Through Three Points, 2012) for calculating the radius of a curve given three points:
Magnetometer calculations 1. Calculate headings in radians from magnetometer x, y by taking arctangent of x/y 2. Calculate change in time from start of curve to end 3. Divide change in heading by time 4. Radius is average speed divided by change in heading over time
The computations for several sample curves are shown in Figure 31. The Google Earth data in this case serves as the ground truth and is computed using sample points manually chosen along the roadway from the Google Earth views.
31

`

Google Earth estimated radius (meters)

GPS calculated radius (meters)

Magnetometer calculated
radius (meters)

-269

-438

-429

(*Magnetic interference due

to overpass)

-332

-316

-274

-432

-422

-459

-360

-350

-366

32

`

Google Earth estimated radius (meters)

GPS calculated radius (meters)

Magnetometer calculated
radius (meters)

408

428

529

Figure 31 Radius computations using GPS and Magnetometer Data

The GPS calculated radii appeared to be more accurate when compared to the estimates generated using points chosen on Google Earth than using the change in compass direction as indicated by Carlson et. al (Carlson, 2005). The three point technique described earlier might not be the approach to do the calculation in this case. It might be better to use additional sample points on the curve. This is accomplished by assuming the form of the equation of the curve as in the Equation that follows.

)

)

Where

denote the coordinates of the center of the circle and the radius. The

lat/long coordinates are converted to Cartesian coordinates and the values for

are estimated in a least squared error sense as shown in Figure 32.

33

`

Figure 32 Sample curve fit to estimate radius of curvature

Table 2 Curvature Computations

Curve Google Earth

number (R) m

1

431

2

332

Hard Mount (R) m 430 331

Velcro Mount (R) m 459 367

Suction Mount(R) m 382 303

XSens Hard Mount (R) m 423 313

Comparative calculations using this technique are shown in Table 2. This data also

shows some of the effects of using different techniques for mounting the devices. The simplest

technique for mounting that provides representative data will in the end be the most likely to be

employed. It appears however that a SmartPhone system could provide initial estimates on radii

of curvature on for example for new construction.

General Tool for Assessment

Acceleration Profiles For planning and road design the acceleration profiles as vehicles traverse various
sections of roadway can be illustrative of the effectiveness of the design and performance of vehicles using the roadway as they reflect the actual forces on the vehicle. In Figure 33 for example at the position marked with the red arrow in the upper portion of the image the lower
34

` portion of the graph shows a line marking this position the red graph shows the lateral acceleration and the blue graph the perpendicular (or z) acceleration. This point shows a significant change in the z acceleration along with a corresponding change in the lateral accelerations. This could be brought on by a change in the vertical change along with possibly a change in roll. These are observable differences from similar curves. We see a similar situation in Figure 34 where there is an observable difference in the lateral accelerations. Features such as these might signal a need to look more closely at these segments of roadway.
Figure 33 Sample run that shows an acceleration anomaly (Vertical and Transverse)
35

`
Figure 34 Sample run that shows an acceleration anomaly (Transverse)
With each data collection run significant amounts of data are collected and a tool to help in assessment would be useful. Sample tools for conducting this assessment are described in Appendix E. Google Maps is an easily available tool that provides features that help in the analysis of data. It is able to read what are called KML files (KML was chosen as a convenient format to display data for this project but not currently supported by GDOT IT) that can be displayed on a computer on maps of the area from which the data was collected. The KML files hold the lat/long position as well as the other data of interest. Examples are shown in Figure 35 in which we show the pitch and roll (red and blue plots at bottom) along a segment of I-575 using phone data and Figure 36 which uses data from the XSens. As mentioned earlier the pitch and roll data on the phone in Figure 35 does not reflect the true measurements under the dynamic conditions as in Figure 36 for the XSens which utilizes data from gyroscopes in its calculations. Moving the vertical line in the bottom panel of these displays allows the user to see the value of
36

` the parameter of interest at any point along the track where the current point would be marked by the red arrow. In Figure 37 an example is shown where no-passing zones are determined with data collected using a Smartphone and the guidelines from the AASHTO Green Book (Officials, 2004).
Figure 35 Roll and pitch data collected with Droid Smartphone
Figure 36 Roll and pitch data using the XSens
37

`
Figure 37 Passing zone determination on a segment of roadway
38

`
Conclusions and Future Work
Smartphones appear to be able to provide data to GDOT personnel that could be useful in support of many planning and maintenance tasks through analysis of data from the sensor suite on the phone. There a several potential options for mounting the devices. A hard mount (fixed to the body of the vehicle) appears to provide the best fidelity in the data but other possibilities such as using Velcro is worth consideration. The lack of a gyroscope in the Droid X hinders the acquisition of data under some dynamic conditions but this could probably be addressed through the use of phones with gyroscopes and additional software to take advantage of the data from this additional sensor. Also, techniques for accounting for different vehicle types need to be considered for example using reference data to a common surface as in the normalization approach described in the report.
The potential to collect huge amounts of data could also pose significant analysis problems but tools to support the analysis that could pre-filter and provide graphical interfaces to assist the user in conducting analysis could be useful. The ability to continually monitor a variety of conditions could also be helpful by being able to provide early notification of issues that might be of concern. It might be possible for example to setup Twitter feeds for segments of roadway that the appropriate personnel could follow in order to be notified in a timely manner of issues that deserve further attention such as a more detailed assessment. Areas that are of concern could also be identified to the engineer when in the area through his GPS position and direction. It might also be possible for the GDOT to "crowd source" the acquisition of data on its roadways by making the App available to commuters thereby having many more eyes and ears monitoring the infrastructure.
39

`
Monitoring the absolute values and standard deviation of accelerations, Whole Body Vibrations (WBV), changes in the acceleration values in the orthogonal directions appear to be useful features for accessing road conditions. These measures also appear to correlate strongly with IRI and PACES measurements which are used by the GDOT for roadway monitoring and assessment. These features could also be used to assess the effectiveness of features such as rumble strips in attracting the attention of inattentive drivers by choosing frequencies that maximize WBV in addition to the audio cues that could also be monitored by the phone.
For reasons of availability and ease of use Google Earth was used in this effort but similar capabilities are available in comparable GIS systems approved for use by GDOT. It is also possible to provide Augmented Reality (AR) views of data on phone such to be used by engineers when visiting sites of interest.
New rate gyro sensors on most phones can help to address the deficiency with the Droid X used in this work related to acceleration determination when in motion. Many phones also now have barometric sensors that could improve altitude calculations by GPS.
Wireless interfaces to other sensors is also a possibility if the capability and accuracy of the built in sensor suite does not provide the data fidelity or accuracy required for some applications. These sensors are now available in OEM packages and would be relatively inexpensive to install in vehicles and is an option to address the mounting issues.
The Smartphone is a very capable and powerful sensor and computational engine that could support in a cost effective way many GDOT operations while reducing costs and increasing safety and efficiency of GDOT personnel. This work has laid the groundwork for practical studies looking geared towards specific applications. Tools such as these would serve to support a variety of GDOT personnel by providing support that enables them to be more safe and productive in the execution of their duties.
40

`
References
Carlson, P. J. (2005). Comparison of Radius-Estimating Techniques for Horizontal Curves. Journal of the Transportation Research Board, No. 1918, 76-83.
Kjella, A. G. (2002). Relating Road Roughness and Vehicle Speeds to Human Whole Body Vibration and Exposure Limits. The International Journal of Pavement Engineering Vol. 3(4), 207-216.
Mednis, A. S. (2011). Real Time Pothole Detection using Android Smartphones with Accelerometers. Distributed Computing in Sensor Systems and Workshops (DCOSS), 2011 International Conference on (pp. 1-6). IEEE.
Misaghi, S. N. (2010). Impact of Truck Suspension and Road Roughness on Loads Exerted to Pavements. El Paso: FHWA-RD-07-1008-02.
Rode, S., Vijay, S., Goyal, P., Kulkarni, P., & Arya, K. (2009). Pothole Detection and Warning System: Infrastructure Support and System Design. Electronic Computer Technology, 2009 International Conference on (pp. 286-290). IEEE.
Unknown. (2012, April 28). Circle Through Three Points. Retrieved from Circle Through Three Poings -CGAFaq: http://www.cgafaq.info/wiki/Circle_Through_Three_Points
Unknown. (2012, April 27). GrepCode. Retrieved from GrepCode: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4. 0.3_r1/android/hardware/SensorManager.java#SensorManager.getRotationMatrix%28flo at%5B%5D%2Cfloat%5B%5D%2Cfloat%5B%5D%2Cfloat%5B%5D%29
41

`

Appendices

Appendix A
Droid X Specifications
OS Processor RAM GPU Display Internal user Memory External user Memory GPS Accelerometer
Compass Network Wi-Fi Bluetooth USB Battery Weight Camera DSP

Android 2.0 Arm Cortex A8 processor 550 MHz (TI OMAP3430) 256MB PowerVR SGX 530; w/ OpenGL ES 1.0 3.7"; WVGA (480 x 854 pixels); 16:9 widescreen 256MB 16GB microSD FAT32 aGPS (assisted); sGPS (simultaneous) STMicroelectronics LIS331DLH 3-axes linear nano accelerometer AKMicrosystems AK8973 3-axis Electronic Compass CDMA / EVDO / 3G 802.11 b,g v2.1 +EDR 2.0 microUSB 1400mAh Li-Ion 169g (6oz) 5MP Texas Instruments TMS320C64x

Definitions aGPS Assisted GPS uses an assistance server or other data from a network to improve the startup performance of the GPS system. sGPS Simultaneous GPS allows a cell phone to transmit both GPS and voice data at the same time, via two radios.

42

`

Appendix B

XSens Specifications Contact

XSens Mti-G Jack Mawson (Jack.Mawson@xsens.com)

Cost

Device

DevKit

GPS Ant. & Receiver

4850 (w/DevKit & GPS Ant) -

GPS

Channels

Up. Rate

Cold Start

Hot Start

50 L1, C/A Galileo L1 4 Hz 29s -

Overall

Position - Hor Position - Vert Pos. Max Update Rate Pos. Max Update Rate Static Att. - Heading Static Att. - Roll/Pitch Dynamic Accuracy Attitude Resolution Att. Max Update Rate Att. Max Update Rate

2.5m 120 (onb) 512(ext) 1deg 0.5deg 1deg rms 0.05deg 120Hz (onb) 512Hz (ext)

Interface

Comm. Comm. Other Data GPS Antenna Conn. Voltage Power

RS-232 w/ USB conv. SMA Conn. 5-30 V ~650mW Typical

Software GUI Manual

GUI and Calibration, etc. C++ DLLs and Source Code

Acc.

Axes

Full Scale (standard)

3 50m/s2
43

`

Gyro Mag. Press.

Linearity Bias Stability Scale Factor Stability Noise Alignment Error Bandwidth Max Update Rate

XSens Mti-G 0.2% FS 0.02 m/s2 0.0003 0.002m/s2/sqrtHz 0.1deg 30Hz 512Hz

Axes Full Scale (standard) Linearity Bias Stability Scale Factor Stability Noise Alignment Error Bandwidth Max Update Rate

3 300deg/s 0.1% GS 1deg/s 0.05deg/s/sqrtHz 0.1deg 40Hz 512Hz

Axes Full Scale (standard) Linearity Bias Stability Scale Factor Stability Noise Alignment Error Bandwidth Max Update Rate

3 750mGauss 0.2% FS 0.1mGauss 0.50% 1.5mGauss 0.1deg 10Hz 512Hz

Axes Resolution Full Scale Linearity Bias Stability Scale Factor Stability Noise Alignment Error Bandwidth Max Update Rate

1 30-120kPa 0.5% FS 100Pa/yr 4Pa/sqrtHz 9Hz
44

`

XSens Mti-G

Temp. How Many?

1 (?)

Oper.

Max Altitude Max Velocity Amb. Temp Specified Perf. Temp Weight Shock Lim (Powered) Shock Lim (UnPowered)

18km 515m/s -40-85degC 0-55degC 68g -

45

`

Appendix C

Specifications on the GPS accuracy tests

U.S. Coast and Geodetic Survey Bench Mark

PID:

DG0321

Designation: J 4

Latitude:

3346'21.00"N

Longitude: 8423'39.00"W

HorzAccuracy: +/- 6 seconds

Xsens

GPSage: HorzError: VertError: Latitude: Longitude:

16.14 2615.31 5399.73 3346'20.75"N 8423'39.12"W

Phone 1
Accuracy: Latitude: Longitude:

24 3346'20.28"N 8423'39.12"W

Phone 2
Accuracy: Latitude: Longitude:

33.9 3346'20.28"N 8423'38.76"W

*Both phones ranged from 5-9 satellites (this number was not recorded in the data). Sample Intervals: ~20 seconds

46

`

Appendix D

Benchmark Specifications

DATABASE = Sybase ,PROGRAM = datasheet, VERSION = 7.50

1

National Geodetic Survey, Retrieval Date = JULY 22, 2011

DG0321

***********************************************************************

DG0321 DESIGNATION - J 4

DG0321 PID

- DG0321

DG0321 STATE/COUNTY- GA/FULTON

DG0321 USGS QUAD - NORTHWEST ATLANTA (1997)

DG0321

DG0321

*CURRENT SURVEY CONTROL

DG0321

___________________________________________________________________

DG0321* NAD 83(1986) - 33 46 21.

(N) 084 23 39.

(W)

SCALED

DG0321* NAVD 88

-

298.717 (meters) 980.04 (feet)

ADJUSTED

DG0321

___________________________________________________________________

DG0321 GEOID HEIGHT-

-29.53 (meters)

GEOID03

DG0321 DYNAMIC HT -

298.384 (meters)

978.95 (feet)

COMP

DG0321 MODELED GRAV-

979,514.0 (mgal)

NAVD 88

DG0321

DG0321 VERT ORDER - FIRST

CLASS II

DG0321

DG0321.The horizontal coordinates were scaled from a topographic map

and have

DG0321.an estimated accuracy of +/- 6 seconds.

DG0321

DG0321.The orthometric height was determined by differential leveling

DG0321.and adjusted by the NATIONAL GEODETIC SURVEY in June 1991.

DG0321

DG0321.The geoid height was determined by GEOID03.

DG0321

DG0321.The dynamic height is computed by dividing the NAVD 88

DG0321.geopotential number by the normal gravity value computed on the

DG0321.Geodetic Reference System of 1980 (GRS 80) ellipsoid at 45

DG0321.degrees latitude (g = 980.6199 gals.).

DG0321

DG0321.The modeled gravity was interpolated from observed gravity

values.

DG0321

DG0321;

North

East Units Estimated

Accuracy

DG0321;SPC GA W

- 418,300.

678,930.

MT (+/- 180

meters Scaled)

47

`

DG0321

DG0321

SUPERSEDED SURVEY CONTROL

DG0321

DG0321 NGVD 29 (12/12/91) 298.637 (m)

979.78 (f)

ADJUSTED 1 2

DG0321

DG0321.Superseded values are not recommended for survey control.

DG0321.NGS no longer adjusts projects to the NAD 27 or NGVD 29 datums.

DG0321.See file dsdata.txt to determine how the superseded data were

derived.

DG0321

DG0321_U.S. NATIONAL GRID SPATIAL ADDRESS: 16SGC413399(NAD 83)

DG0321_MARKER: Z = SEE DESCRIPTION

DG0321_SETTING: 36 = SET IN A MASSIVE STRUCTURE

DG0321_SP_SET: BUILDING

DG0321_STAMPING: ELEV 979.808 FEET J 4 1916

DG0321_MARK LOGO: CGS

DG0321_STABILITY: B = PROBABLY HOLD POSITION/ELEVATION WELL

DG0321

DG0321 HISTORY

- Date

Condition

Report By

DG0321 HISTORY

- 1916

MONUMENTED

CGS

DG0321 HISTORY

- 1933

GOOD

NGS

DG0321 HISTORY

- 1982

GOOD

NGS

DG0321

DG0321

STATION DESCRIPTION

DG0321

DG0321'DESCRIBED BY NATIONAL GEODETIC SURVEY 1933

DG0321'AT ATLANTA.

DG0321'AT ATLANTA, FULTON COUNTY, AT THE GEORGIA INSTITUTE OF

TECHNOLOGY,

DG0321'AT THE LIBRARY, IN THE WALL AT THE SOUTHEAST CORNER OF THE

DG0321'BUILDING, ERRONEOUSLY STAMPED ELEV. 979.808 FEET J 4 1916 AND

DG0321'SET VERTICALLY.

DG0321

DG0321

STATION RECOVERY (1982)

DG0321

DG0321'RECOVERY NOTE BY NATIONAL GEODETIC SURVEY 1982

DG0321'RECOVERED IN GOOD CONDITION. THE 1933 DESCRIPTION IS ADEQUATE

EXCEPT

DG0321'THE LIBRARY BUILDING DESCRIBED THEREIN IS NOW THE CARNEGIE

DG0321'BUILDING. IT IS THE FIRST BUILDING EAST OF THE CAMPUS

DG0321'ADMINISTRATION BUILDING.

*** retrieval complete. Elapsed Time = 00:00:01

48

`
Appendix E
GDOT Mobile Sensing Analysis Software Instructions Introduction
This document describes the preliminary analysis software we've developed for the GDOT Mobile Sensing project. This set of analysis tools includes three programs: KMLgenerator, plot_circle_radius, and StdDevThreshold. Each of these programs relies on the GPS data from the phone or Xsens. These GPS data files will have file names that end with either "_gps.csv" (Xsens) or "_loc.csv" (Phone).
The primary way we've been looking at these GPS data files is through Google Earth. To do this, we generate a KML file containing all the GPS points from the GPS data file using the KMLgenerator program.
The other two programs, plot_circle_radius and StdDevThreshold, are two sample analysis programs we came up with to generate CSV files containing points of interest (in this case, sharp turns and rough roads). These points in these CSV files can be displayed in Google Earth with pushpins. To do this, run KMLgenerator, and enter the path of the CSV file into the first prompt. When the new KML file is generated, you will now see pushpins that represent the points from the CSV file. The instructions below give more detailed instructions on how to run these programs. Full paths pointing to the locations of the full set of data are necessary (i.e. the GPS and required sensor files should be in the same directory)
Mobile Phone Software An app called GDOT MobileSensing was developed for the phone to control data acquisition and storage activities. The data that is acquired on the phone is first stored to the phone. The phone is
49

`
then connected to a computer where it simulates a hard disk and the data can then be copied to the
relevant storage location for analysis.
KMLgenerator.exe
Used to generate a KML file from GPS data recorded from the Xsens or phone.
Optionally, a CSV file containing the latitude and longitude (and any other information) for
points of interest may be specified. Such CSV files would be generated by other analysis tools,
such as StdDevThreshold.exe or plot_circle_radius.exe.
Instructions:
Double click program to run. Enter the file path (or drag file into command prompt) to the CSV file generated by an
analysis program (such as StdDevThreshold), or just press Enter to generate the KML file without extra data points. Enter the full path of (or drag into command prompt) the GPS file of the dataset you want to generate a KML file for. For the Xsens, these files are named "<date>_<time>_gps.csv". For the phones, these files are named "<date>_<time>_loc.csv". Enter the full path, including file name, where you want the output KML file to be placed. Note: If you press the "up" arrow on your keyboard in the command prompt, it will show the most recent item you entered. This will allow you to easily keep the same directory as the GPS file. All you need to do is change the file name. Your file must end in a ".kml" extension. We suggest naming it "<date>_<time>_kml.kml" but you can name it whatever you want. Next you can add zero reference values. This will add a fixed offset to the pitch, roll, and yaw if the device has been calibrated. For most cases, you can just press enter to skip these steps. KML file will be written when processing is done. Example usage:
>Please input path to generated CSV file (or press Enter for none):
S:\FPTD_Shares\development\GDOT\SmartPhoneSensing\Research\2012-03-15 PACES
data collection\Location1\Xsens\20120315_150511\20120315_150511_stdDevs.csv
>Please input path to GPS data file: 50

`
S:\FPTD_Shares\development\GDOT\SmartPhoneSensing\Research\2012-03-15 PACES data collection\Location1\Xsens\20120315_150511\20120315_150511_gps.csv
>Please input desired output file path (.kml): S:\FPTD_Shares\development\GDOT\SmartPhoneSensing\Research\2012-03-15 PACES data collection\Location1\Xsens\20120315_150511\20120315_150511_kml.kml
>Please enter a YAW zero reference (or press Enter for none): >Please enter a PITCH zero reference (or press Enter for none): >Please enter a ROLL zero reference (or press Enter for none):
plot_circle_radius.exe Analysis program that takes in GPS data and determines the radius of curvature at each
point in the GPS data set. If the radius at a given point is greater than a specified threshold, the point is flagged as a point of interest and is put into the output CSV file.
Instructions:
Double click program to run. Enter the full path of (or drag into command prompt) the GPS file of the dataset you want
to analyze. For the Xsens, these files are named "<date>_<times>_gps.csv". For the phones, these files are named "<date>_<time>_loc.csv". Enter the full path, including file name, where you want the output CSV file to be placed. Note: If you press the "up" arrow on your keyboard in the command prompt, it will show the most recent item you entered. This will allow you to easily keep the same directory as the GPS file, just change the file name. Your file must end in a ".csv" extension. We suggest naming it "<date>_<time>_radius.csv" but you can name it whatever you want. Next, you will enter the time period (in seconds) over which to calculate the radius of curvature. We've found that a time between 5 and 20 seconds works best. Next, enter the radius threshold (in meters). Any point with a radius less than this number will be included in the output CSV file. Output CSV file will be written when processing is done. Example usage: >Please input path to GPS data file:
51

`
S:\FPTD_Shares\development\GDOT\SmartPhoneSensing\Research\2012-03-15 PACES data collection\Location1\Xsens\20120315_150511\20120315_150511_gps.csv
>Please input desired output file path (.csv): S:\FPTD_Shares\development\GDOT\SmartPhoneSensing\Research\2012-03-15 PACES data collection\Location1\Xsens\20120315_150511\20120315_150511_radius.csv
>Please input time interval (in seconds) over which to calculate the radius of curvature: 5
>Please input maximum radius (in meters) to display (i.e. 175): 175
StdDevThreshold.exe Analysis program that takes in GPS data and determines points where the standard deviation in the z-direction (i.e. vertical motion) exceeds a specified threshold. Such points are flagged as a points of interest and are put into the output CSV file. Instructions:
Double click program to run. Enter the minimum standard deviation in the z-direction of an unacceptably rough road. Enter the full path of (or drag into command prompt) the GPS file of the dataset you want
to analyze. For the Xsens, these files are named "<date>_<time>_gps.csv". For the phones, these files are named "<date>_<time>_loc.csv". Enter the full path, including file name, where you want the output CSV file to be placed. Note: If you press the "up" arrow on your keyboard in the command prompt, it will show the most recent item you entered. This will allow you to easily keep the same directory as the GPS file, just change the file name. Your file must end in a ".csv" extension. We suggest naming the file "<date>_<time>_stddevs.csv" but you can name it whatever you want. Output CSV file will be written when processing is done. Example usage: >Please input standard deviation threshold (default is 0.4):
52

`
0.4 >Please input path to GPS data file: S:\FPTD_Shares\development\GDOT\SmartPhoneSensing\Research\2012-03-15 PACES data collection\Location1\Xsens\20120315_150511\20120315_150511_gps.csv >Please input desired output file path (.csv): S:\FPTD_Shares\development\GDOT\SmartPhoneSensing\Research\2012-03-15 PACES data collection\Location1\Xsens\20120315_150511\20120315_150511_stddevs.csv To view KML files in Google earth: 1. Make sure Google Earth is installed (http://earth.google.com). 2. Double click on KML file to open in Google Earth. 3. If your KML file was generated with extra data points (from StdDevThreshold.exe or plot_circle_radius.exe), then these points will appear as pushpins on your map. Otherwise, you will just see the route from the GPS.
4. Clicking on each of the pushpins will display relevant information about the point. You can also click on any point along the route (in this case, the blue line) to view all the raw information generated from the GPS at that point.
53

`
5. To view the GPS information graphically, expand the KML file in the "Places" section (click the black arrow next to the KML filename), right click the device highlighted in blue, and select "Show Elevation Profile".
6. You can now select up to two different data types to graph simultaneously. Simply click on them on the top bar of the graph (Note: because there are so many data types, the list may run off the screen, and there is currently no way to scroll through them. To view most of them, maximize the window and hide the side bar by pressing Ctrl + Alt + B). 54

`
7. To close the elevation profile, click the small white `X' at the top right corner of the elevation profile window.
55