CityDrive: A Map-Generating and
Speed-Optimizing Driving System
Yiran Zhao, Yang Zhang, Tuo Yu, Tianyuan Liu,
Xinbing Wang, XiaohuaTian
Department of Electronic Engineering
Shanghai Jiao Tong University, China
Xue Liu
School of Computer Science, McGill University, Canada
Outline
 Introduction
 Motivations
 Objectives
 Android smartphone capabilities
 City map construction
 Traffic signal schedule inference and update
 Routing and speed advising
 Concluding Remarks
2
Motivation I/II
 Without traffic signal schedule information, vehicles’ accelerating and
stopping cause increased fuel consumption, air pollution and
accidents.
Fuel burned
Energy wasted
3
Motivation II/II
 Smartphones are ubiquitous, it’s easy to deploy intelligent
transportation system on a smartphone in each vehicle.
4
Objective – I/II
 In our work, we design an infrastructure-less speed advisory
driving system that tries to make vehicles arrive at intersections in
green phase.
 Our system only runs on Internet server and smartphones, using
crowd-sourced smartphone sensor data to infer traffic signal
schedule.
 Our system also provides foundations for many other applications:
 Commercial map revision and refinement
 Traffic signal planning advisory service
 Driving behavior and road condition estimation
 Red light violation advisory
5
Objective – II/II
 We first construct city map using crowd-sourced smartphone
data from GPS, accelerometer, and magnetometer.
 Then in each identified intersection, we design a method to
merge traffic movements and infer traffic signal schedule
from vehicles’ acceleration events.
 After the traffic signal schedule of a certain intersection is
successfully deduced, our system provides speed advisory
service for vehicles heading toward this intersection.
6
Outline
Introduction
Android smartphone capabilities
 Various sensing modules
 Coordinate system transformation
 City map construction
Traffic signal schedule inference and update
Routing and speed advising
Concluding Remarks
7
Various sensing modules in smartphones
3-axis Accelerometer
 Measures the acceleration applied to the device in device’s body
coordinate system, including the force of gravity.
 We need acceleration data to infer intersection location and traffic
signal phase transition.
3-axis Magnetometer
 Measures the geomagnetic field in device’s body coordinate system.
 We need magnetometer data when transforming acceleration vector
into different coordinate systems.
Global Positioning System (GPS)
 Devices’ position (longitude and latitude), speed (m/s), bearing
(heading direction, in degrees), UTC time (in milliseconds since
January 1, 1970), accuracy (in meters).
 Average accuracy of position is about 4 -11 meters.
8
Coordinate system transformation
Coordinate systems:
North
Earth
device
Down
(a) Body coordinate system
East
(b) Local NED coordinate system
 Measurements of accelerometer and magnetometer are in device’s
body coordinate system. We have to transform acceleration vector
from body coordinate system into local NED coordinate system
using two reference vectors: gravity and geomagnetic field.
9
Coordinate system transformation
 Using Android library function to get rotation matrix:
 Transform acceleration vector from body coordinate system
(𝑎𝑏 ) to Local NED coordinate system (𝑎𝑛𝑣 ):
 Transformed acceleration data are easier to be processed and
mapped to a geological map.
10
Outline
 Introduction
 Android smartphone capabilities
 City map construction
 Locating candidate intersections
 Clarifying intersection structure
 Linking intersections
 Traffic signal schedule inference and update
 Routing and speed advising
 Concluding Remarks
11
Locating candidate intersections
 Assumption: during map-construction phase, vehicle
acceleration after a sufficient long halt only happens at
intersections when red light turns into green light.
 Then it’s reasonable that locations with high acceleration
vector density are likely to be intersections with traffic
signals.
 We use an approach similar to mean shift, in which
successive computations of the mean shift yield a path
leading to a local acceleration density maximum.
12
Locating candidate intersections
 Using mean shift to localize possible intersections:
Possible
locations of
intersections
.
13
Locating candidate intersections
 The result of mean shift may contain false positives, so we
analyze the vector pattern in each intersection to confirm its
validity.
 We group acceleration vectors with approximately the same
direction into one cluster, and each cluster should represent one
branch of the intersection.
 Then intersections with cluster (branch) number less than 3 or
greater than 5, or with out-pointing mean vectors, are invalid.
(a) Invalid intersection
(b) Valid intersection
14
Clarifying intersection structure
 GPS traces between intersections are further analyzed to clarify
branches. Traces starting and ending with the same pair of
intersections are grouped into one road segment. Road segments
(with direction) connected to each intersection are indexed.
 GPS traces within each intersection are then analyzed to clarify
the structure of that intersection, resulting in a connectivity table
which supports one-way traffic situation.
(a) Raw GPS traces
within an intersection.
(b) Clarified connectivity
information of the intersection.
15
Linking intersections
 We want to use several directed points (Anchor Points) to represent the road
segment between two neighboring intersections.
 We use an algorithm similar to weighted mean shift that finds the centroid
point and mean direction of a cluster of GPS points sharing approximately the
same direction. Such points are anchor points.
Intersections
(blue circles)
Anchor points
(red circles),
stored in
database
16
Linking intersections
 How to generate road segment from a set of anchor points? – Second order Bspline curves to fit those points.
 E.g. For every two successive anchor points (A and B in (a)), the control
points of the B-spline curve are D, C and E, such that 𝐷𝐴 = 𝐶𝐴, 𝐶𝐵=𝐵𝐸.
Note in some cases especially when A and B are on a straight line, the Bspline curve on longer applies, so we use a straight line between A and B
instead (like (b)).
17
Linking intersections
 The constructed map of our test bed is shown below, with
comparison to real map from Google Map. The blue segments
are B-spline curves and the magenta segments are straight lines.
18
Outline
Introduction
Android smartphone capabilities
City map construction
Traffic signal schedule inference and update
 Vehicle acceleration data structure
 Traffic signal phase and phase sequence
inference
 Traffic signal timing calibration and update
Routing and speed advising
Concluding Remarks
19
Vehicle acceleration data structure
 Future vehicle acceleration at a specific intersection will generate a data
package sent to the server to help infer traffic signal schedule.
A vehicle stops and waits for
green light. Waiting at time T0.
On detection of acceleration,
smartphone records time T1.
On detection of entering
another branch,
smartphone records time T2.
Smartphone sends {wait
time:(T1-T0); acc. time:
(T2-T1); branch: I1,O3; ID}
to the server.
20
Traffic signal phase and phase sequence inference
 Denote (𝑂𝑖 , 𝐼𝑗 ) as the traffic movement from 𝐼𝑗 branch to 𝑂𝑖
branch.
 At the beginning of traffic signal schedule inference, each (𝑂𝑖 , 𝐼𝑗 )
is called a state, 𝑆𝑖𝑗 .
 Some states start at approximately the same time, so we merge
them into one state. We simplify the subscript and denote the
states as 𝑆𝑖 , 𝑖 = 1,2, … 𝑁, N is the total number of states.
 As the number of states (N) decreases due to merging, we try to
find the traffic signal cycle length (denoted as Tc). (Assume that
each state only happens once in each cycle.)
 Denote ∆𝑡𝑖 as the minimum time gap between consecutive
acceleration events of state 𝑆𝑖 .
 So, does min{∆𝑡𝑖 , 𝑖 = 1,2, … 𝑁} necessarily equal to Tc?
-- We calculate the probability.
21
Traffic signal phase and phase sequence inference
 Let 𝑋𝑖 𝑛 be the probability that min{∆𝑡𝑖 , 𝑖 = 1,2, … 𝑁} does
NOT equal to Tc after n cycles. And the probability of an event
of 𝑆𝑖 in one traffic signal cycle is 𝑝𝑖 .
 Then probability 𝑋𝑖 𝑛 + 2 is equal to probability 𝑋𝑖 𝑛 + 1 if
the (n+2)th cycle has no event plus probability 𝑋𝑖 𝑛 if (n+2)th
cycle has an event and (n+1)th cycle has no event:
 Solving this equation yields:
 The 𝑝𝑖 is estimated to be the ratio of the two-minute intervals
that have an event to all such intervals.
22
Traffic signal phase and phase sequence inference
 Let 𝑃𝑖 𝑛 = 1 − 𝑋𝑖 𝑛 denotes the probability that min{∆𝑡𝑖 , 𝑖 =
1,2, … 𝑁} equals to Tc.
 The relationship between 𝑃𝑖 𝑛 , 𝑝𝑖 , and n is shown. We want
𝑃𝑖 𝑛 >0.8, so that the probability that
min{∆𝑡𝑖 , 𝑖 = 1,2, … 𝑁} equals to Tc is 1-(1-0.8)^N=0.9984 if N=4.
So we can almost
make sure that Tc
is correctly obtained
after 2n minutes of
data collecting, n is
solved by 𝑃𝑖 𝑛 =0.8.
23
Traffic signal phase and phase sequence inference
 Once the traffic signal cycle length Tc is obtained, the sequence
of states {𝑆𝑖 , 𝑖 = 1,2, … 𝑁} are to be determined.
 Ideally, and typically, there are four states after complete
merging:
 And the above four states should happen in sequence:
𝑆1 → 𝑆2 → 𝑆3 → 𝑆4 → 𝑆1 …
 We give a new name to states that are in sequence and in closed
loop: phase.
24
Traffic signal phase and phase sequence inference
 How to find such phases? – Linking states and see if their time
interval adds up to Tc.
 For each state 𝑆𝑘 , we find the nearest following state 𝑆𝑙 , which
means in the entire set of recorded events at server side, there is
an event of 𝑆𝑙 that most closely follows an event of 𝑆𝑘 . We make
the two states into a link: 𝑆𝑘 → 𝑆𝑙 , and the time interval is ∆𝑡𝑘𝑙 .
 Moving on to finding the nearest following state after 𝑆𝑙 , and so
on. If at some point, it loops back to 𝑆𝑘 , and sum{∆𝑡𝑖𝑗 }≈ 𝑇𝑐,
then we say that a loop chain is formed: 𝑆𝑘 → 𝑆𝑙 → 𝑆𝑚 … →
𝑆𝑝 → 𝑆𝑘 . And each state is then called a phase.
 Note that merging of states is still happening, we skip the details
of this process.
25
Traffic signal timing calibration and update
 Given a loop chain, we calculate the timing schedule of each
phase in this loop chain.
 E.g. for a loop chain of N phases: 𝑆1 → 𝑆2 → 𝑆3 … → 𝑆𝑁 → 𝑆1 ,
and su𝑚 ∆𝑡𝑖,𝑖+1 , 𝑖 = 1,2 … 𝑁 = 𝑇𝑐.
 Notation:
𝑡𝑖
𝑘
𝑘 𝑡ℎ event time of 𝑆𝑖
𝑡𝑠
Process start time (first event time)
𝑡0
Process start time after calibration
𝑛𝑠𝑖
Number of times 𝑆𝑖 occurs till now
𝑑𝑡𝑠𝑖
Time duration of 𝑆𝒊
26
Traffic signal timing calibration and update
 The server collects smartphone reports and store the events in the
table below:
 𝑛𝑠𝑖 is obtained from ∆𝑡𝑖,𝑖+1 (𝑑𝑡𝑠𝑖 ), 𝑡𝑠 , and Tc. And we are going
to calibrate 𝑑𝑡𝑠𝑖 , and get 𝑡0 .
 We resolve the above table into (N+1) columns, each forming a
vector, namely: 𝒕, 𝒏𝒔𝟏 , 𝒏𝒔𝟐 ,… 𝒏𝒔𝑵 . The size of each vector is M.
27
Traffic signal timing calibration and update
 We formulate a target function 𝐹 that represents the mean square
error (MSE) of predicted time:
 Note that 𝑡𝑠 , 𝒕, 𝒏𝒔𝒊 are known variables, 𝑑𝑡𝑠𝑖 and 𝑡0 are to be
calculated.
 Minimize this target function by taking partial derivative of each
variable in Equ.(1):
 Solving the above equations yields calibrated 𝑡0 and 𝑑𝑡𝑠𝑖 . And
these values are used to predict future traffic signal schedule.
28
Outline
Introduction
Android smartphone capabilities
City map construction
Traffic signal schedule inference and update
Routing and speed advising
Concluding remarks
29
Route planning
 The system has to know whether to turn left or go straight
at each intersection in order to get the corresponding traffic
signal timing. So prior knowledge of route is required.
 Dijkstra algorithm is employed on smartphones to calculate
a route with the least travel time.
 If the average speed of the planned road segment is
available in real-time, then the travel time can be predicted
more accurately. If not, system assume that the speed limit
is 60 km/h.
 On finishing one road segment, smartphone also reports the
average speed of that road to the server, so the server can
provide real-time routing service to other vehicles.
30
Best speed calculation
 Once the route is determined, the smartphone requests traffic
signal schedule information of the next intersection.
 Server returns:
Traffic signal cycle length: Tc;
The remaining time for the desired phase to turn green: 𝑡𝑔 ;
The remaining time to turn red: 𝑡𝑟 ;
 Thus the time of reaching the intersection should be 𝑡 𝑛 :
𝑡𝑔 + 𝑡𝑠𝑔 + n × 𝑇𝑐 < 𝑡 𝑛 < 𝑡𝑟 − 𝑡𝑠𝑟 + n × 𝑇𝑐
 𝑡𝑠𝑔 and 𝑡𝑠𝑟 are time intervals used to reduce the impact of
prediction error, and are empirically set to 10 seconds.
31
Best speed calculation
 To calculate the remaining distance to the next intersection, the
smartphone integrates the B-spline curves or straight lines
formulated in the City Map Construction section.
 Once the distance (d) and travel time 𝑡 𝑛 is obtained, the
optimal speed should be 𝑣𝑜𝑝𝑡 such that:
𝑑
𝑑
< 𝑣𝑜𝑝𝑡 <
𝑡𝑟 − 𝑡𝑠𝑟 + n × 𝑇𝑐
𝑡𝑔 + 𝑡𝑠𝑔 + n × 𝑇𝑐
 n should be the least integer number that 𝑣𝑜𝑝𝑡 does not exceed
speed limit.
 d can be calculated multiple times on a road segment to provide
constantly adjusting optimal speed to the driver.
32
Outline
Introduction
Android smartphone capabilities
City map construction
Traffic signal schedule inference and update
Routing and speed advising
Concluding remarks
33
Conclusion
 In this paper, we have devised and implemented CityDrive, a
software service that utilizes a collection of smartphone sensor
and GPS data to continuously provide advisory speed for drivers.
 Such speed-advisory service significantly reduces energy
consumption and the number of complete halts.
 But CityDrive requires a large proportion of running vehicles to
use our system, and it may not work if the GPS signal is blocked
by dense high buildings. Also, to avoid too much load on a
single server, the central server system should be distributed to
different regions.
 Future work should figure out a way to identify flyovers, and to
properly assign road lanes to vehicles moving with different
speeds. In addition, incentives to use our service has to be
explored, and proper punish mechanism is needed if drivers run
the red light.
34
Thank you !
Reference (partial)
 [9] O. Servin, K. Boriboonsomsin, M. Barth, “An Energy and Emissions Impact
Evaluation of Intelligent Speed Adaptation,” in Proc. IEEE ITSC’06, Toronto, Canada,
September 17-20, 2006.
 [10] K. Perera, D. Dias, “An Intelligent Driver Guidance Tool using Location Based
Services,” in Proc. IEEE ICSDM’11, June 29-July 1, 2011.
 [11] M. Krause, K. Bengler, “Traffic Light Assistant - Driven in a Simulator,” in Proc. IEEE
IV’12, 2012.
 [12] E. Koukoumidis, L.-S. Peh, and M. R. Martonosi, “SignalGuru: lever-aging mobile
phones for collaborative traffic signal schedule advisory,” in Proc. MobiSys’11, New York,
NY, USA: ACM, 2011, pp. 127-140.
 [13] G. Mahler, A. Vahidi, “Reducing idling at red lights based on probabilistic prediction
of traffic signal timings,” in American Control Conference (ACC), 2012 (pp. 6557-6562).
 [14] M. Kerper, C. Wewetzer, A. Sasse, M. Mauve, “Learning Traffic Light Phase
Schedules from Velocity Profiles in the Cloud,” in NTMS’12, pp. 1-5, 2012.
 [15] P. Mohan, V. N. Padmanabhan, R. Ramjee, “Nericell: Rich Monitoring of Road and
Traffic Conditions using Mobile Smartphones,” in Proc. ACM SenSys, pp. 323-336, 2008.
 [16] S. Schroedl, K. Wagstaff, S. Rogers, P. Langley, C. Wilson, “Mining GPS traces for
map refinement,” in Data mining and knowledge Discovery, 2004, 9(1): 59-87.
36