University of Southern California Dissertations and Theses

The benefits of participatory vehicular sensing

(USC Thesis Other)

The benefits of participatory vehicular sensing

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content THE BENEFITS OF PARTICIPATORY VEHICULAR SENSING
by
Matthew McCartney
A Thesis Presented to the
FACULTY OF THE GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
MASTER OF SCIENCE
(COMPUTER SCIENCE)
August 2018
Copyright 2018 Matthew McCartney
Table of Contents
List of Tables iii
List of Figures iv
Abstract v
1: Introduction 1
2: Vehicular Sensing Background 4
3: Cavalcade: ACrowd-SourcedVehicularSensingSys-
tem 6
4: Dataset Analysis Results 16
5: Related Work 27
6: Conclusion 29
Bibliography 30
ii
List of Tables
3.1 Average sample rates of vehicle sensors used in our analysis . . . 15
4.1 Intersections classified by OSM and our classifier . . . . . . . . . 18
4.2 Pavement condition index classification precision and recall . . . 21
4.3 OSM road hierarchies and their speed limits . . . . . . . . . . . 23
4.4 Daily operational costs of a fleet of 7 mail vans . . . . . . . . . 24
iii
List of Figures
3.1 Cavalcade components . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Heat map showing areas of dense sensor readings represented
by warm colors and sparse areas by cool colors . . . . . . . . . . 14
iv
Abstract
Many aspects of our transportation ecosystem (like traffic regulators, or pave-
ment conditions) have not been captured in digital format, or require significant
human effort to do so. In this paper, we explore how participatory sensing can ben-
efit these tasks, by examining a novel dimension in participatory sensing, namely
crowd-sourced vehicular sensing. To achieve this goal, we build a crowd-sourced
vehicular sensing platform called Cavalcade, and deploy it on a testbed of 7 fleet
vehicles. We monitor the testbed for a period of 6 months, accumulating a dataset
of billions of sensor readings. Through analysis of the crowd-sourced dataset we
were able to detect nearly 6 times as many intersection regulators than what is
reported on OpenStreetMap, a community driven map project rich in local knowl-
edge. Additionally, we use crowd-sourced vehicular sensors to measure the condi-
tion of road pavement, that detects poor roads with 94% precision compared to
manual measurements made by a city transportation department.
v
Chapter 1
Introduction
In recent years, many entities have attempted to capture many aspects of
our transportation ecosystem in digital form. Most recently, commercial [Google
(2015)] and volunteer organizations [Haklay & Weber (2008)], and even urban gov-
ernment transportation departments [Office of Mayor Eric Garcetti (2015)], have
digitized features and usage patterns of our road transportation infrastructure.
These efforts attempt to document aspects, such as street locations, roadside sig-
nage, and traffic patterns; however, coverage and accuracy are limited, expensive,
and difficult to achieve.
We explore how we can use vehicles as sensors to digitize aspects of the trans-
portation ecosystem cheaper, easier, and with comparable accuracy to existing
methods. These existing methods, which typically involve some combination of
manual measurement and/or the development of highly specialized sensors, are
costly and labor-intensive. Thus, they do not scale well to a vast and expanding
road network. We instead consider how to improve upon or complement these
methods, by using sensor data collected from vehicles that traverse the road net-
work every day. We refer to this participatory sensing technique as crowd-sourced
vehicular sensing.
Crowds of vehicles have the sensing potential to capture many aspects of the
transportation ecosystem. Vehicles contain dozens of computer-controlled elec-
tronic subsystems that govern modern vehicular features, such as electronic fuel
1
injection, anti-lock braking, and emissions control. Correct operation of these sub-
systems depends on the capabilities of the vehicle to sense fuel pressure, driver
brake pedal input, and exhaust oxygenation. The vehicle captures these events
with thousands of sensors, whose readings can be extracted from on-board serial
ports, and used for other applications unrelated to vehicle subsystem control.
Wetakeadvantageofvehicularsensoraccessibilityandtheprevalenceofmobile
computing, to explore crowd-sourced vehicular sensing. Simple and inexpensive
hardware exists that enables mobile devices to access vehicular sensors, and store,
process and share these sensor readings. In the absence of this capability, vehicular
sensor readings would remain confined to the internal vehicle communication bus.
In this work, we explore the benefits of crowd-sourced vehicular sensing using
a smartphone-based vehicular sensing platform called Cavalcade. This platform
consists of a smartphone application (app) and a suite of cloud services. The
app runs on a driver’s smartphone and communicates with their vehicle, collecting
sensor data seamlessly in the background. The app periodically reports collected
readings to a centralized storage repository where web services process the data.
We used Cavalcade in a testbed of 7 university mail service vehicles and col-
lected a large number of vehicle sensor readings. The testbed was fully operational,
collecting about 6 hours each day per vehicle, for a total period of 6 months. Cav-
alcade gathered, in that time, 3.7 billion vehicular sensor readings within an area
of 60 square miles in the city of Los Angeles. Within this area, the testbed vehi-
cles traveled 10,000 miles of roads ranging from residential streets, to interstate
highways.
2
In order to demonstrate the types of benefits achievable from a deployment,
such as our testbed, we perform several analyses to extract additional transporta-
tion ecosystem information, and compare our results with existing publicly avail-
able datasets. We apply heuristics based on first principles as well as machine
classification techniques to derive new insights concerning traffic patterns and the
featuresofthetransportationinfrastructure. Specifically,wemonitorthefuelusage
patterns of the vehicle fleet and find that they spend around 30% of their time in
congested traffic each day, which costs the fleet an additional $100 per week in fuel.
Another analysis classifies with 97% precision the types of intersection regulators
(stop signs or traffic signals) installed at 652 intersections along the testbed routes;
this is nearly 6 times as many as are documented in OpenStreetMap [Haklay &
Weber (2008)]. Lastly, we train an SVM-based classifier to infer the quality of
road pavement based on the suspension movement of multiple vans passing over
the same segment of road. We show that this technique achieves an accuracy of
94% on a dataset of pavement conditions in Los Angeles. Taken together, these
results suggest that crowd-sourced vehicular sensing can be used to augment maps,
identify opportunities for improved fuel usage, or to prioritize road infrastructure
improvements.
3
Chapter 2
Vehicular Sensing Background
Automotive manufacturers equip cars sold in America with sophisticated elec-
tronics that govern an increasing number of electronic subsystems, such as the
powertrain, the entertainment subsystem, or cabin temperature control. Upwards
of 100 microprocessor-equipped Electronic Control Units (ECU) make engineering
the correct operation of these subsystem components possible. Through an in-car
communication network, these subsystems transfer state and sensor readings. This
information, obtained from multiple subsystems may influence the operation of
other vehicle components. For example, in an internal combustion engine-powered
car, the powertrain control module ECU uses sensor readings from the emissions-
sensing CPU to govern fuel and air intake. To meet these demands, one or more
internal communication networks called vehicle buses, interconnect all CPUs in a
vehicle. These communication networks aid vehicle diagnostics, by transmitting
errorcodesorgeneralsubsystemstatestotheheadsupdisplay(HUD)orotherout-
put devices. To formalize these sensing mechanisms across multiple manufactures,
theSocietyofAutomotiveEngineers(SAE)definedtwoprimarystandardizedcom-
munication protocols that dictate the basic requirements of how an in-car network
should operate.
CAN Standard. Cars sold in America after 2008 contain a standardized pair
of vehicle buses called the Controller Area Network (CAN) [Bosch (1991)]. Two
data wires, allowing for 2 distinct buses make up the CAN. One bus is a high
speed link that utilizes both wires for streaming up to 500Kbps of fine grain sensor
4
information, such as instantaneous engine RPM. The other bus is a low speed
single wire link for transmitting event-driven (e.g., door ajar) sensor updates at
a moderate sample rate. The CAN standard defines a messaging protocol that
provides, among other functions, configuration of individual subsystem sensors or
groups of sensors. ECUs request periodic data readings from these sensors over
the CAN. The reporting rate of CAN sensors varies significantly across different
subsystems; some sensors are event-driven, while others sample at up to 100 Hz.
OBD-II Standard. Mandatory on all cars sold in the United States after 1996,
the second On Board Diagnostics standard (OBD-II) [Standard (2002)] describes:
1) the core electrical system components of a vehicle that must exist as CAN-
accessible sensors, and 2) how the vehicle makes these sensors externally accessible.
The standard includes requirements for basic vehicle fault diagnostic sensors, such
as the vehicle speed, engine speed, and instantaneous fuel consumption. In addi-
tion, manufacturers often leverage the CAN messaging protocol for communication
of non-standard sensors; these manufacturer-specific sensors often outnumber the
quantity of standard sensors by two orders of magnitude. The OBD-II standard
also describes a standardized hardware port, to serve as an interface to internal
vehicle electronics. This port contains data pins for communication across several
standardized serial buses, with two of these pins reserved for the CAN buses.
5
Figure 3.1: Cavalcade components
Chapter 3
Cavalcade: A Crowd-Sourced
Vehicular Sensing System
Cavalcade sources data from drivers willing to grant us access to the sensors
contained in their vehicles; in this paper, we refer to this as crowdsourcing. From
participating vehicles, Cavalcade collects sensors and the streams of data the sen-
sors produce. Many of these sensor readings describe only low-level vehicle func-
tions of a single participant. However, when aggregated across other sensors and
across other cars, we can infer additional information about the environment.
The components of Cavalcade are shown in Figure 3.1. These include a mobile
sensing Collector, a Repository, and a suite of web services. Drivers equip their
vehicles with the Collector application (app). The app runs in the background
on a mobile smartphone located inside the passenger compartment of the vehicle,
logging raw sensor readings during instances of driving. Provided the phone has
an adequate power source, the Collector app may run in this state for months at
a time, transmitting recorded sensor readings to the Repository. In this sense, the
6
Repository acts as a sink, archiving and indexing traces collected from a fleet of
vehicles each containing a Collector. The Repository has a suite of web services
that process and visualize traces, revealing additional map and vehicle information
that benefit fleet operation.
Vehicle Crowd-Sensing Requirements
An implementation of a vehicle sensor readings collector that can fully utilize
the sensing capabilities of modern vehicles has several non-obvious requirements.
We describe these requirements below in the context of only the Cavalcade Collec-
tor. Since the Cavalcade Repository and Web Services are composed of standard
database and web technologies, we omit the requirements and present only the
design in Section 3.
Sensor Access. The Collector must provide, to one or more requesting apps,
a transparent vehicle interface for accessing sensors. Influenced by the sensor sub-
scriptionmodeloftheCAN[Bosch(1991)], thisinterfacemustsupporttheaddition
andremovalofsensorrequests, andamechanismtoforwardsensorreadings. These
apps, running on the same device as the Collector, may act independently; an app
requesting one set of sensors should not affect sensor sets requested by other apps.
The Collector however, can satisfy this requirement with a best effort; hardware
limitations associated with different vehicles and dongles may limit the total num-
ber of concurrent sensor requests. For example, if a particular dongle supports
only 20 distinct sensor requests, the first requesting app may block another from
requesting additional sensors beyond the original set of 20.
Spatiotemporal. Vehicle sensing is inherently time-dependent, geospatial, and
must facilitate map-based applications. This requires that all sensor readings are
7
associated with a time and location field throughout the entire data pipeline. The
obtained location information must have high accuracy and temporal resolution.
High location accuracy is needed to accurately and efficiently identify the road a
vehicle is traversing. Location readings need also to be sampled as close to the rate
of the vehicle sensors as possible, in order to know where the vehicle was when the
sensor measurements were taken.
Robustness. A vehicle sensing testbed must operate over long periods of
time requiring minimal user input. The desired duration depends on the type of
mapping analysis and can be up to several months. During this time, the Col-
lector should perform the necessary sensing and data communication operations
in a manner that tolerates faults, requires minimal system memory and compute
resources, does not affect other concurrent mobile applications, and conserves bat-
tery when a vehicle power source is unavailable.
The Collector must read and report all requested sensors in a way that avoids
the loss of any sensor reading data. This requires that the Collector communicate
with the vehicle, validating at all times that the correct sensors are activated. It
must then package the recorded sensor readings for local storage and transmission
to the remote Repository. When the vehicle ignition is turned off, or when all
sensor reporting is terminated, the Collector should react accordingly in an effort
to conserve energy.
Collector Design
The design of the Collector is motivated by the requirements of remotely sens-
ing vehicles. The Collector is a mobile application that reliably captures smart-
phone and vehicle sensor data over long periods of time. The Collector runs on
8
web-enabled phones and accesses vehicular sensors through a proprietary dongle
attached to the OBD-II port [Standard (2002)]. The Collector first initializes the
vehicle sensors available to the dongle device. Then, an app can issue, to the Col-
lector, a subscription request to receive periodic updates from available sensors.
The Collector establishes a connection to the dongle and forwards requests for sen-
sor data to the vehicle. The Collector handles vehicle responses, forwarding sensor
readings to local flash storage, to subscribing apps, and to the remote Repository.
Sensor Definitions. Different manufacturers can define sensors using dif-
ferent formats; even within a single manufacturer, different vehicle models may
have different sensor architectures. To decouple sensor definitions from the rest
of the sensing capabilities of the Controller, Cavalcade uses a dictionary of sensor
definitions. Sensor definitions are program resources that describe the byte signa-
ture and payload conversion functions of sensor readings. A unique numerical key,
a human-readable sub-system name, and a numerical payload value describe the
contents of a sensor reading. The Collector parses sensor definitions in order to
decode sensor readings from the stream of bytes originating from the dongle.
Sensor Subscription. Mobile apps issue subscription requests to the Collector
for periodic updates to decoded sensor data. The initial subscriber initiates the
process of activating the dongle for reporting updates from specific sensors. Only
when all active subscribers to a specific sensor have unsubscribed or disconnected
from the Collector are sensors deactivated on the dongle. The ability to deactivate
sensorsinthedongleiscrucial, asdonglesareoftenlimitedinthenumberofsensors
they can process simultaneously. In the event of over-subscription, the Collector
simply throws an error and ignores all subsequent subscription requests.
9
Dongle Communication. The requirement that the Collector never loses even
a single sensor reading requires (a) persistent connections, and (b) reliable deliv-
ery. The Collector persists established bluetooth connections by issuing periodic
heartbeats to the dongle, which prevent it from turning off. Forcing the dongle to
remain active has the benefit of ensuring that sensor subscriptions are maintained
during driving, and of reducing the delay between sensor subscription and data
acquisition. The Collector achieves reliable delivery of messages to and from the
vehicle, over the lossy communication medium, with retransmissions. If a Col-
lector message goes unacknowledged by the dongle for 5 seconds, the message is
deemed lost in transmission, and is pushed to the end of the commands queue for
retransmission. If a message is retransmitted 10 times consecutively, it is deemed
invalid and is abandoned.
Vehicle Interface Robustness. The design of the Collector is motivated by
the requirement of the vehicle sensing platform, that the Collector must operate
for months on end with minimal user input. The hardest challenge in building the
ControllertomeetthisrequirementinvolvedengineeringtheBluetoothInterfaceto
lastbeyond atleast 1hour ofcontinuoussensing. Achieving consistentoperation of
the Bluetooth Interface during long duration vehicle sensing required overcoming
challenges in establishing a solid connection to the dongle, and consistently reading
from the network stream.
All parts of Cavalcade depend on the Collector being able to reliably establish
a connection to the vehicle for sensing. When dealing with the potentially noisy
wireless communication bus employed by Bluetooth, a reliable connection is one
that is established quickly and persists. Establishing a connection quickly enables
sensing of initial driving actions, such as seatbelt fastening and door actions, that
can happen within the first 30 seconds. This can help, for example, in algorithms
10
that attempt to disambiguate drivers by their in-car habits. To this end, we found
that by simply avoiding resetting the dongle each time shaves minutes off of the
connection establishment time. Additionally, we found that improperly closing the
Bluetooth connection prevents re-connection. Freeing all system resources associ-
ated with the Bluetooth connection is a prerequisite for establishing a connection
free from interruptions or delays.
Another important part of the Cavalcade Bluetooth Interface is its ability to
consistently read messages from the dongle. The Bluetooth interface needs to
read from the Bluetooth connection at least as fast as the rate at which messages
are generated by the dongle and the vehicle. This way, the system-level queue
associated with the Bluetooth communication channel never becomes backed up,
and no messages are dropped. We achieved this by separating the Collector and its
apps into separate processes. This creates a clean separation between the system
resources allocated for the apps and the rest of the Collector, so a computationally
intensive app has minimal effect on the operation of the Bluetooth Interface.
Vehicle Location Services. Consistent GPS data for all sensor readings is
crucial to mapping analyses. During tests lasting more than 1 day however, we
observed stale location information from the mobile device. The reported GPS
coordinates begin to lose resolution and accuracy after 24 hours, and eventually
freeze at a single incorrect value. Simply restarting the Collector periodically is
effective in addressing this issue.
Cloud Communication. WiFi and mobile telephony are the two main
technologies available for achieving mobile Internet connection on the Collector.
Since the driving routes of our testbed are localized to the USC campuses, we
expected that the campus-wide WiFi services supplied by the university would be
sufficient for uploading sensor readings to the Repository. We found that the WiFi
11
services were indeed in range, however Internet connection drops became more
frequent, and files in transfer were corrupted. With both technologies relying on
thesame2.4GHzISMband,heavyuseofbothresultedininterference[Fu&Plumb
(2011)]. For this reason, the Collector uses a cellular connection to upload data,
but with the Collector dependent on a potentially capped data plan for Internet
connection, it becomes important to transfer files efficiently. The collector employs
standard gzip compression for uploading sensor readings to the repository.
Readings Repository and Mapping Web Services
The Repository is a suite of three backend services: the Gateway, an Archive,
and an Analyzer. These web services enable centralized storage, processing, and
visualization of the collected sensor readings. Web services exist on the Repository
to archive sensor readings in a geospatial database for later use by mapping anal-
yses. The mapping analyses can analyze large collections of vehicle sensor traces
and display the results in an effort to extract useful information about the driving
environment.
Readings Storage. Collectors transmit compressed sensor readings to the
pre-configured Repository location. The Gateway daemon process asynchronously
queues up all submissions for insertion into the geospatial database. During inser-
tion, the Gateway serially extracts the sensor readings from their archives, logs the
access time, and performs a bulk insert, careful to avoid duplicate entries caused
by sporadic readings on vehicle startup. The Repository Archival service catalogs
all sensor readings in a single time series table consisting of user-id, time, sensor
ID, value and location fields. A database trigger maintains a geospatial generalized
search tree index on the GPS fields of the readings. This type of index is expensive
12
in terms of space, but can offer fast lookup times for many common map-based
queries.
Map Matching. Most of the mapping analyses presented in this work rely on
map matching. The process of extracting static road features from vehicle traces
of GPS points depends on the accurate location of the vehicle as it traverses roads;
map matching achieves this by associating a GPS point (potentially inaccurate by
10’s of meters) with a point on the known road network, that is consistent with
previous vehicle trace positions. Map matching is an expensive operation that
is most effective when performed on an entire trace. For this reason, and since
other apps depend on the results, we perform map matching on all traces in a
pre-processing step. The Repository sends entire traces to a remote web service
[Marchal (2015)] for map matching. The results contain corrected GPS points
and OSM-based road IDs for all input entries. Both of these attributes are used
extensively by analysis approaches presented in this work.
TrackMatching [Marchal (2015)] is an Amazon cloud-based service that
matches vehicle GPS traces to the OSM-documented network of roads. As is
typical with many Software As a Service (SAAS) platforms, the TrackMatching
creators conceal the details of their map matching algorithm. The results however,
when applied to testbed traces, are highly accurate, failing only on complex road
junctions, such as on-ramps. The free usage licenses offered by TrackMatching
allows us to process 20 day-long traces per hour, which was more than sufficient
for our dataset. Prior to trace analysis by the mapping analyses, the repository
submits traces for processing, and receives results via a REST API to the Track-
Matching service. These results greatly increase the accuracy of the trace locations
andimprovetheperformanceofapplicationsthatrequirereversegeocodingofloca-
tions to street names.
13
Figure 3.2: Heat map showing areas of dense sensor readings represented by warm
colors and sparse areas by cool colors
Virtual Sensors. In addition to extracting information from the geospatial
data fields, the Analyzer component of the Repository derives virtual sensors from
one or more vehicle sensors. These virtual sensors can describe, for example, the
change in a single raw sensor over time, or a complex aggregate of multiple raw
sensors. For example, the speed sensor readings integrated over time can be used
to derive a virtual odometer sensor, or the yaw rate sensor can be integrated to
derive changes in heading. The Analyzer computes virtual sensors when a query is
posed by the apps since they are relatively more specific and less computationally
expensive compared to map matching.
We deployed Cavalcade on several vehicles and collected a large number of
vehicle traces, referred to in this work simply as the dataset. The vehicle traces
that make up the dataset originate from a collaboration with the USC Mailing and
Material Management Services Department, in which we were granted 6 months
of access to 7 of their daily-operated fleet vans. The Campus Mailing Services
Department uses these vans to deliver packages between the USC campuses and
14
Table 3.1: Average sample rates of vehicle sensors used in our analysis
Name Avg. Sample Rate (Hz.)
Shifter Position 40.0
Rough Road Magnitude 20.8
Vehicle Speed 10.0
Engine Speed 10.0
Throttle Position 10.0
Instantaneous Fuel Consumption 10.0
theregionalpostagedeliveryoffices. Figure3.2showsamapofLosAngelesCounty,
and the geographic extent of all traces included in the dataset.
The proprietary sensors present in the vans, and accessible to us through a
collaboration with GM, offer rich functionality. They include high-level sensors
that report forms of driver input and chassis movement. These sensors include the
ignition key position, the actuation of the turn signals, lateral chassis movement,
andanti-lockbrakingsystemactivity. Someofthesesensorsreportreadingsonlyin
response to occasional events, such as changing the cruise control speed. Many of
the sensors used in our tests however, continuously report readings once activated,
at a rate of at least 10 Hz (Table 3.1). At these sampling rates, the testbed as a
whole gathered over 30 million readings a day, and a total of 3.7 billion readings
during the deployment period. The vans reported these readings while logging
10,000 driving miles over an area of about 60 square miles in the county of Los
Angeles.
15
Chapter 4
Dataset Analysis Results
In this section, we demonstrate that a dataset of this scale and type, consist-
ing of historical multi-vehicle traces, has great potential to uncover new informa-
tion related to an urban transportation ecosystem. Specifically, Cavalcade can
uncover new information that would otherwise require extensive manual studies
or expensive domain-specific sensing hardware; indeed, we perform analysis of the
dataset that reveals additional information concerning both static road features,
and characteristics of traffic dynamics. We implemented three qualitative analyses,
described below, to demonstrate the benefit of crowd-sourced vehicular sensing in
quantifying aspects of the transportation infrastructure.
Intersection Regulator Classification
Often in urban environments, where 2 roads intersect, transportation agencies
install traffic regulators like stop signs and traffic lights that regulate the flow of
traffic. These intersection regulators serve to manage road congestion and access,
and to reduce traffic collisions [Kell & Fullerton (1991)]. Flows of traffic often
consist of 2 roads intersecting at 90
◦
; however, more complex intersections do
exist, but these are typically paired with more sophisticated regulators not covered
in this work. Regulators are often installed during the construction or significant
modificationofaroad, andarerarelyaddedorremovedonceinstalled; thus, forthe
16
sake of this work, we consider them to be static road features of the transportation
ecosystem.
Determining whether an intersection has a stop sign or a traffic light can have
significant benefits, and this is the problem we address in this section. Both stop
signs and traffic signals have a significant impact on several aspects of the trans-
portation ecosystem. At applicable intersections, they directly influence speed,
contention, and congestion of nearby traffic. It follows that vehicle navigation
tools that route through urban roads stand to benefit from stop sign and traffic
signal location information. Increasing the efficiency of navigation in general, and
in this way in particular, can have a large influence on not only the mobility, but
also the health [Wjst et al. (1993)] and safety [Jain et al. (2015)] of the people
living in urban areas.
Methodology
Weclassifythetypeoftrafficregulator(eitherstopsignortrafficsignal)present
at known intersection locations along the routes of our crowd-sourced dataset. We
do this by taking advantage of the crowd-sensing properties of our dataset, and of
thetypicalpatternsthatvehiclesexhibitduringthenavigationofregulators. When
approaching a regulator that commands a stop before passing (red traffic signal or
stop sign), drivers will decelerate, come to single or series of complete or partial
stops, and then accelerate through the intersection. These actions are clearly
captured with Cavalcade, through vehicle sensors, such as the brake, throttle,
shifter, and speed sensors. During deceleration, the vehicle speed decreases as
the driver releases the throttle and depresses the brake, which results in down-
shifting of the automatic transmission. Traversing the intersection, the vehicle
speed increases as the driver depresses the throttle, and the vehicle up-shifts.
17
Table 4.1: Intersections classified by OSM and our classifier
Source Type # of Intersections
Signs 38
OSM
Signals 106
Signs 28
Classifier
Signals 624
A single observation of the regulated intersection driving pattern is not enough
to perform an accurate distinction between a traffic signal and a stop sign. This is
because a traffic signal may or may not constrain the flow of traffic in a particular
direction, depending on the time of observation. Because of this, the addition of
crowd sensing is needed to make a more informed classification. To achieve this,
we perform classification on intersections for which we have greater than 9 distinct
vehicle traces.
We consider 10 instances of driving through a traffic signal-regulated inter-
sections sufficient for observing at least one instance of a red and green light; the
necessaryconditionsfordistinguishingasignalfromastopsign. Ourpoolofknown
intersections originates from the GeoNames web service [GeoNames], an OSM data
backed tool we used to retrieve the distinct set of all nearest intersections to all
GPS points in our dataset.
Results
To verify the precision and recall of the classifier, we manually labeled 23
additional signals and 152 signs, not included in the OSM data. We treat the
intersection classifier as a binary classifier, and use the metrics of precision and
recall to quantify the accuracy of our results. When compared to the OSM and
manual intersection labels, the classifier achieves 97.50% precision and 96.29%
recall.
18
We observed that the testbed vehicles traveled, during their daily routes,
through a total of 1779 OSM-labeled intersections. 1127 of these intersections
were navigated by too few traces. Of the intersections for which we had significant
data, the classifier returned 28 intersections regulated by stop signs, and 624 inter-
sections regulated by traffic signals (Table 4.1). Table 4.1 shows the total number
of signals and stop signs (out of the total 2906 discovered by the testbed) labeled
by the OSM community.
Implications
Our tests show that, with only a small fleet of participants, crowd-sensing
vehicles of moderate age for 6 months, yields new accurate map information. The
intersection classifier returned 6 times more intersections than what is currently
available from the efforts of the OSM project. Though there are still many more
intersections left unchecked; we had insufficient coverage for nearly half of the
intersections traversed by the testbed. This shows that the modern public map
data is significantly limited in this respect, and that crowd-sensing can label many
more intersections when scaled out in time or number of vehicles.
The large discrepancy between the number of traffic signals and stop signs
classified is due to the driving characteristics of our testbed participants. The
operatorsofthecampusmaildeliveryvehiclestypicallyfollowroutesusingprimary
and motorway roads, rather than secondary and residential streets. On these main
trunks of the road network traffic signals are more prevalent in a densely populated
urban area like Los Angeles.
19
Pavement Condition
Roads degrade over time, requiring city transportation departments to monitor
their condition for scheduling periodic maintenance. Road surface deformations,
such as cracks, bumps, potholes, caused by weathering and normal use, have a
significant impact on drivers and vehicles traversing these roads [Robson (1979)].
Indeed, vehicle maintenance costs [Chatti & Zaabar (2012)] and accident frequency
[Al-Masaeid (1997)] both increase as a result of decreased pavement quality. For
thesereasons, transportationengineerscarefullymonitorthechangeinroadsurface
conditions over time to prioritize maintenance operations [Camahan et al. (1987)].
To measure road surface quality transportation departments use a standardized
metric called Pavement Condition Index (PCI) [Sharaf et al. (1987)]. The PCI is
a numerical index from 0 to 100, of observed pavement quality. In addition to the
numericalindicator, PCImeasurementsarealsocategorizedasPoor, Fair, orGood.
The Los Angeles city Transportation Department employs both of these metrics in
their tri-annual survey of road segment surface conditions of Los Angeles County
[Bureau of Street Services (2015)] and publishes the results of these surveys online
[Bureau of Street Services (2015)]. We use these survey measurements to explore
how crowd-sourced vehicular sensing can be used to monitor the quality of roads
cheaper, faster, and with similar accuracy to traditional methods. Specifically,
we explore whether a supervised machine classifier can accurately determine the
categorization of road conditions.
Methodology
As a vehicle travels over a road at a certain speed, its chassis undulates verti-
callyinreactiontoroadsurfacedeformations, suchascracks, bumps, potholes, and
20
Table 4.2: Pavement condition index classification precision and recall
Good Fair Poor
Precision 81% 78% 93%
Recall 80% 80% 91%
Support 230 496 564
others. To explore this phenomena, we analyze entries contained in our dataset
relating to the speed and Rough Road Magnitude (RRM) vehicle sensors. RRM
measures the magnitude of the average vertical displacement of all 4 suspended
wheels at a rate of about 20 Hz. Since the speed at which a vehicle travels over a
road bump or dip influences the duration and magnitude of chassis suspension dis-
placement, the RRM sensor readings must be analyzed with respect to the vehicle
speed. We summarize a vehicle’s sensitivity to a pavement as a feature vector con-
sisting of the following metrics: average RRM, maximum RRM, minimum RRM,
average speed, maximum speed, and minimum speed.
We use this feature vector to classify pavement quality with supervised machine
learning. We train a Support Vector Machine (SVM) classifier on 30 road segments
from both ours and the LA City datasets. Our dataset contains a total of 5162
samples of vehicles traversing these roads, and the number of samples for each road
range from 1 to 1024. For the PCI labels of Poor, Fair, and Good, we consider
2145, 2074, and 943 samples respectively. We train the SVM classifier on 25% of
the samples, and test on the remaining 75%.
Results
We test the PCI classifier by the metrics of precision and recall for each class.
Shown in Table 4.2, we find that our supervised machine learning approach clas-
sifies road quality with 78% to 93% precision and 80% to 91% recall with respect
to the manual transportation department measurements. The classifier identifies
21
Poor classes with almost 10% more precision and recall than the other two classes.
Although the training set (identified by the Support row in Table 4.2) for the Poor
class is larger than the rest, we observe similar precision and recall results during
tests where all 3 classes are limited to 230 training samples.
Implications
The PCI classifier results suggest that we can use groups of vehicles collecting
speed and chassis movement data to aid the process of monitoring road pavement
condition. Critically, having high Poor PCI classification precision, the PCI clas-
sifier is well suited to the task of reporting roads in need of common forms of
maintenance, such as pothole and crack repair. The classifier however is only able
to classify the quality of pavement that vehicles are capable of traversing. In the
event of a single collapsed or obstructed lane, drivers may simply pass via another
lane or route. Consequently, we see this method being best used in addition to
periodic manual surveys. Road surveyors can use the PCI classifier to constantly
monitor the quality of roads during the times between manual surveys. Once a
new survey is scheduled the results of the classifier can guide surveyors to roads
that have degraded in quality since the last inspection.
Energy Usage
Transportationbyinternalcombustionpoweredvehiclesrequiresexpendingfuel
a certain amount of time to get from one place to a desired destination. The fuel
cost and time required to navigate a certain route however, depends on several
driving factors. Driving technique, traffic conditions, and road type all have an
impact on the rate of fuel consumption and duration of travel. Driving technique
22
can vary greatly, but one clear operator decision made often during mail delivery,
is the choice to turn off (conserve fuel) or leave the vehicle running (expend fuel)
during short mail delivery stops. Similarly, adverse traffic conditions in the form of
congestion on a typically free-flowing road can greatly reduce the speed of travel,
which costs additional fuel and time. During times of low congestion, a free flowing
type of road, such as a highway, requires less fuel and time per mile to navigate
than a densely regulated urban street.
We analyze the dataset to quantify the time and monetary fuel costs associated
with driving technique, traffic conditions, and road type. Similar to past studies,
we use the IFC vehicle sensor to measure how much fuel is consumed while driving,
but we do so in the context of traffic congestion and over an order of magnitude
more miles driven than past studies [Ganti et al. (2010)]. Additionally, we use the
previously unexplored vehicle shifter position sensor to distinguish between fuel
consumed while the vehicle is parked or stopped [Ganti et al. (2010)]. Drivers of
these vehicles use the same mail vans each day to travel roughly the same route;
this gives us a dense per-road sampling of weekday fuel consumption patterns.
With these features, we can quantify time and fuel costs associated with operating
a fleet of similar vehicles in typical urban driving scenarios.
Methodology
Wetakeadvantageofseveralvehiclesensorsandmap-matchedGPSlocationsof
the mail vans to compute daily time and energy expenditures. The Instantaneous
Fuel Consumption (IFC), shifter position, and vehicle speed sensors describe the
amount of fuel used, the parked state, and the distance traveled respectively. We
say that a car is parked if the shifter is in the Park position, and is Stopped if the
vehicle speed is 0 mph and the shifter is in Drive. Whether or not a vehicle is
23
Table 4.3: OSM road hierarchies and their speed limits
Road Type Speed Limit (mph)
Motorway 65
Primary 40
Secondary 35
Tertiary 35
Residential 25
Unclassified 25
Service 10
Table 4.4: Daily operational costs of a fleet of 7 mail vans
Road State Gallons Hours Cost Miles
Urban
Moving 8.31 4.39 29.07 119.35
Congested 4.41 4.36 15.42 20.37
Stopped 0.63 1.03 2.22 -
Parked 0.29 0.53 1.02 -
Highway
Moving 3.80 1.40 13.31 70.73
Congested 1.45 1.07 3.75 16.49
Stopped 0.05 0.09 0.19 -
Moving at speed or in Congested traffic is dependent on the relative speed of the
vehicle with respect to the speed limit of the road it is traveling. We map-match
the GPS locations of the vans to classify the roads they travel into the categories
shown in Table 4.3. If a vehicle travels at a non-zero speed less than half of the
maximum allowed speed for a particular road, we say that the vehicle is traveling
in congested traffic.
Results
The average daily fuel, time, fuel cost, and distance measurements for different
driving states of the fleet of 7 mail vans is shown in Table 4.4. We report sepa-
rate driving state measurement averages for both highway and urban road. The
motorway OSM road type shown in Table 4.3 represents Highway roads, and all
other road types represent urban roads. For each type of road and driving state
24
we report the number of Gallons consumed, the number of Hours driven, the fuel
Cost, and the number of Miles driven on average each day by the entire fleet of
mail vans. The fuel cost is the average per-gallon price of fuel in Los Angeles dur-
ing our testbed deployment ($3.50) [LosAngelesGasPrices.com (2015)] multiplied
by the number of gallons consumed.
We observe from Table 4.4 that the mail van drivers spend most of their time
(4.4 hrs.) and distance (119.4 mi.) traveling urban roads at a speed above 50% of
the speed limit for urban roads. While moving on these roads, they consume 8.3
gallons, which results in a fleet-wide fuel cost of almost $30. Interestingly, each
day the drivers are stuck in congested traffic on urban roads for a similar amount
of time as they spend on uncongested urban roads, but only travel 20.4 miles while
consuming 4.4 gallons. This accounts for a daily expenditure of $15 in fuel costs.
During short stops on urban roads where the vehicle is in the drive gear selection
(e.g. stopping at a regulated intersection) the vans consume 0.6 gallons over 1 hour,
for a total cost of $2. At designated urban stops where the drivers put the vehicle
in park for a short amount of time, the vans consume nearly half as much fuel, but
over nearly the same amount of time as drive stops.
Similartourbanroads,whentravelinghighwayroadsthedriverstravelthemost
distance (70.7 mi.), and spend the most time (1.4 hrs.) and fuel (3.8 gal.) while
traveling on uncongested roads. Transportation via congested highways accounts
for 16.5 miles of their route, which costs 1.1 hours and $3.75 in fuel (1.5 gal.).
As expected, the drivers make no designated stops on the highway, but they do
encounter on average 5.5 minutes of stopped highway traffic. Highway stops cost
the fleet $0.20 (0.05 gal.) a day.
25
Implications
These results give us new insights concerning how much it costs to operate
vehicles in different driving settings. To the best of our knowledge, this is the first
study to quantify, through real-world fuel consumption measurements, the cost of
urban and highway traffic congestion. We find that the testbed vehicles spend
a significant amount of time and fuel navigating congested traffic. On average,
while traveling urban roads, the test vehicles spend 4.4 hours, or nearly 30% of the
vehicle running time in congestion. This results in a reduction of average urban
fuel efficiency by about 30% compared to the average Moving fuel efficiency of 14.4
miles per gallon, which costs the fleet an additional $20 per day in fuel. The excess
cost associated with driving in traffic could be used by the mail van fleet managers
to motivate route or departure time changes in an effort to avoid areas and times
of high traffic congestion.
In addition to traffic conditions, we see that the type of road also has a signif-
icant effect on the cost of transportation. Although the vans rely on the highways
to a far lesser degree than they do the urban streets, we see faster and more
fuel efficient driving. Counterintuitively, the van drivers do not always choose the
highways when traveling in between campuses and post offices, instead choosing to
travel by primary and secondary streets. One reason to take urban streets over the
highways is to avoid peak usage hours and times of extremely high traffic conges-
tion. If this is the case, these results may present an incentive to purchase access
to highway toll lanes, or meet the requirements for carpool lanes.
26
Chapter 5
Related Work
In the area of mobile sensing, Hull et. al developed a mobile vehicle sensing
system called CarTel [Hull et al. (2006)]; lacking manufacturer-specific sensors,
they perform only networking, location, and vehicle diagnostic related analysis
on their dataset. Conversely, because our work takes advantage of previously
unexplored vehicle sensors, we are able to sense aspects of the transportation
environment that previously required the use of expensive sensors or significant
human effort.
Researchers have explored distributed road surface monitoring by analyzing
vehicle movement patterns, such as cars traveling over potholes, using the smart-
phone’s accelerometer [Mednis et al. (2011)] [Eriksson et al. (2008)]. These
approaches however are tailored to specific road anomalies and have not been
extended to standardized road condition assessments, such as the PCI. In the
realm of vision-based sensing, researchers have used digital cameras to detect
road anomalies [Koch & Brilakis (2011) Karuppuswamy et al. (2000)]. Although
unlike Cavalcade these approaches do not require require vehicles to drive over the
anomaly, they do suffer in poor lighting conditions, such as shadows caused by
close proximity cars and roadside trees.
GreenGPS [Ganti et al. (2010)] computes fuel efficient routes according to a
model they formulated according to crowd-sourced vehicular measurements. They
achieve significant fuel savings through route optimization and find traffic con-
gestion has the largest effect on fuel consumption variations. Unlike our analysis
27
however, they do not directly measure the impact traffic congestion has on fuel
consumption.
SmartRoad by Shaohan et. al [Hu et al. (2013)] presents a smartphone-based
participatorysensingapproachtodetectingtrafficregulatorsatintersections. They
achieve accuracy comparable to our approach, but because of their reliance on only
smartphone sensors, their trace segmentation technique is susceptible to phone
movement and GPS inaccuracies. Our work also goes further, exploring coverage
of traffic regulator discovery vis-a-vis a crowd-sourced map augmentation platform
(OSM).
28
Chapter 6
Conclusion
Maps and online services either lack or require significant human effort to dig-
itize aspects of our transportation ecosystem. We show in this paper a novel
participatory vehicular sensing approach to this problem. We built Cavalcade, a
participatory vehicular sensing and processing platform, deployed it on 7 mail vans
for 6 months, and used the collected sensor data to analyze traffic regulator clas-
sification, fuel usage breakdowns, and pavement condition. The results of these
analyses show that our approach can classify 6 times as many intersections as a
popular community driven mapping project, and that we can monitor the quality
of road pavement with 94 precision compared to manual road surveys.
29
Bibliography
Al-Masaeid HR (1997) Impact of pavement condition on rural road accidents.
Canadian Journal of Civil Engineering 24:523–531.
Bosch R (1991) Can specification version 2.0. Rober Bousch GmbH, Post-
fach 300240.
Bureau of Street Services OoMEG ipwtCRG (2015) Road surface condition map.
Camahan J, Davis W, Shahin M, Keane P, Wu M (1987) Optimal mainte-
nance decisions for pavement management. Journal of Transportation Engi-
neering 113:554–572.
Chatti K, Zaabar I (2012) Estimating the effects of pavement condition on vehicle
operating costs, Vol. 720 Transportation Research Board.
Eriksson J, Girod L, Hull B, Newton R, Madden S, Balakrishnan H (2008) The
pothole patrol: using a mobile sensor network for road surface monitoring In
Proceedings of the 6th international conference on Mobile systems, applications,
and services, pp. 29–39. ACM.
Fu IK, Plumb W (2011) Method of in-device interference mitigation for cellular,
bluetooth, wifi, and satellite systems coexistence US Patent App. 13/136,861.
Ganti RK, Pham N, Ahmadi H, Nangia S, Abdelzaher TF (2010) Greengps: a par-
ticipatory sensing fuel-efficient maps application In Proceedings of the 8th inter-
national conference on Mobile systems, applications, and services, pp. 151–164.
ACM.
GeoNames Find nearest intersection.
30
Google (2015) Directions.
HaklayM,WeberP(2008) Openstreetmap: User-generatedstreetmaps. Pervasive
Computing, IEEE 7:12–18.
Hu S, Su L, Liu H, Wang H, Abdelzaher TF (2013) Smartroad: a crowd-sourced
traffic regulator detection and identification system In Information Process-
ing in Sensor Networks (IPSN), 2013 ACM/IEEE International Conference on,
pp. 331–332. IEEE.
Hull B, Bychkovsky V, Zhang Y, Chen K, Goraczko M, Miu A, Shih E, Balakrish-
nan H, Madden S (2006) Cartel: a distributed mobile sensor computing system
InProceedings of the 4th international conference on Embedded networked sensor
systems, pp. 125–138. ACM.
Jain S, Borgiattino C, Ren Y, Gruteser M, Chen Y, Chiasserini CF (2015) Lookup:
Enabling pedestrian safety services via shoe sensing In Proceedings of the 13th
Annual International Conference on Mobile Systems, Applications, and Services,
pp. 257–271. ACM.
Karuppuswamy J, Selvaraj V, Ganesh MM, Hall EL (2000) Detection and avoid-
ance of simulated potholes in autonomous vehicle navigation in an unstructured
environment In Intelligent Systems and Smart Manufacturing, pp. 70–80. Inter-
national Society for Optics and Photonics.
Kell JH, Fullerton IJ (1991) Manual of traffic signal design.
Koch C, Brilakis I (2011) Pothole detection in asphalt pavement images. Advanced
Engineering Informatics 25:507–515.
LosAngelesGasPrices.com (2015) Historical price charts.
31
Marchal F (2015) Trackmatching.
Mednis A, Strazdins G, Zviedris R, Kanonirs G, Selavo L (2011) Real time pothole
detection using android smartphones with accelerometers In Distributed Com-
puting in Sensor Systems and Workshops (DCOSS), 2011 International Confer-
ence on, pp. 1–6. IEEE.
Office of Mayor Eric Garcetti ipwtCRG (2015) Datala.
Robson J (1979) Road surface description and vehicle response. International
Journal of Vehicle Design 1:25–35.
Sharaf EA, Reichelt E, Shahin M, Sinha K (1987) Development of a methodology to
estimate pavement maintenance and repair costs for different ranges of pavement
condition index Number 1123.
Standard S (2002) E/e diagnostic test modes. SAE J1979, Apr http:
//standards.sae.org/j1979_201202/.
Wjst M, Reitmeir P, Dold S, Wulff A, Nicolai T, von Loeffelholz-Colberg EF,
Von Mutius E (1993) Road traffic and adverse effects on respiratory health in
children. Bmj 307:596–600.
32

Abstract (if available)

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Crowd-sourced collaborative sensing in highly mobile environments

PDF

Improving efficiency, privacy and robustness for crowd‐sensing applications

PDF

Efficient pipelines for vision-based context sensing

PDF

Sense and sensibility: statistical techniques for human energy expenditure estimation using kinematic sensors

Asset Metadata

Creator McCartney, Matthew Scott (author)

Core Title The benefits of participatory vehicular sensing

School Viterbi School of Engineering

Degree Master of Science

Degree Program Computer Science (Multimedia and Creative Technologies)

Publication Date 01/26/2019

Defense Date 07/26/2018

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag crowd-source,geographic information,Mobile,OAI-PMH Harvest,on-board diagnostics,road quality,sensing,system,Transportation,vehicle

Format application/pdf (imt)

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Govindan, Ramesh (committee chair), Halfond, William (committee member), Sukhatme, Gaurav (committee member)

Creator Email mattsmccartney@gmail.com,mmccartn@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c89-33329

Unique identifier UC11668909

Identifier etd-McCartneyM-6522.pdf (filename),usctheses-c89-33329 (legacy record id)

Legacy Identifier etd-McCartneyM-6522.pdf

Dmrecord 33329

Document Type Thesis

Format application/pdf (imt)

Rights McCartney, Matthew Scott

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA