CityDrive: A Map-Generating and Speed-Optimizing Driving System
Yiran Zhao, Yang Zhang, Tuo Yu, Tianyuan Liu, Xinbing Wang, XiaohuaTian
Department of Electronic EngineeringShanghai Jiao Tong University, China
Xue LiuSchool of Computer Science, McGill University, Canada
2
Outline Introduction
MotivationsObjectives
Android smartphone capabilities
City map construction
Traffic signal schedule inference and
update
Routing and speed advising
Concluding Remarks
3
Motivation I/II
Without traffic signal schedule information, vehicles’ accelerating and stopping cause increased fuel consumption, air
pollution and accidents.
Fuel burned Energy wasted
4
Motivation II/II
Smartphones are ubiquitous, it’s easy to deploy intelligent transportation system on a smartphone in each vehicle.
5
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
6
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.
7
OutlineIntroduction
Android smartphone capabilitiesVarious sensing modulesCoordinate system transformation
City map construction
Traffic signal schedule inference and
update
Routing and speed advising
Concluding Remarks
8
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.
9
Coordinate system transformation
Coordinate systems:
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.
(a) Body coordinate system (b) Local NED coordinate system
device Earth
North
EastDown
10
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.
11
Outline Introduction
Android smartphone capabilities
City map constructionLocating candidate intersectionsClarifying intersection structureLinking intersections
Traffic signal schedule inference and
update
Routing and speed advising
Concluding Remarks
12
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.
13
Locating candidate intersections
Using mean shift to localize possible intersections:
Possible
locations of
intersections.
14
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
15
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.
16
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.
Anchor points
(red circles),
stored in database
Intersections
(blue circles)
17
Linking intersections
How to generate road segment from a set of anchor points? – Second order B-spline 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 B-spline curve on longer applies, so we use a straight line
between A and B instead (like (b)).
18
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.
19
OutlineIntroduction
Android smartphone capabilities
City map construction
Traffic signal schedule inference and
update Vehicle acceleration data structureTraffic signal phase and phase sequence
inferenceTraffic signal timing calibration and
update
Routing and speed advising
Concluding Remarks
20
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.
21
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 , , 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{, } necessarily equal to Tc?
-- We calculate the probability.
22
Traffic signal phase and phase sequence inference
Let be the probability that does NOT equal to Tc after n cycles. And the probability of an event of in one
traffic signal cycle is .
Then probability is equal to probability 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.
23
Traffic signal phase and phase sequence inference
Let denotes the probability that equals to Tc.
The relationship between , , and n is shown. We want >0.8, so that the probability that
min{, } 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.
24
Traffic signal phase and phase sequence inference
Once the traffic signal cycle length Tc is obtained, the sequence of states {} are to be determined.
Ideally, and typically, there are four states after complete merging:
And the above four states should happen in sequence:
…
We give a new name to states that are in sequence and in closed loop: phase.
25
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.
26
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: , and .
Notation:
event time of
Process start time (first event time)
Process start time after calibration
Number of times occurs till now
Time duration of
27
Traffic signal timing calibration and update
The server collects smartphone reports and store the events in the table below:
is obtained from (), , and Tc. And we are going to calibrate , and get .
We resolve the above table into (N+1) columns, each forming a vector, namely: ,. The size of each vector is M.
28
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 are to be calculated.
Minimize this target function by taking partial derivative of each variable in Equ.(1):
Solving the above equations yields calibrated and . And these values are used to predict future traffic signal
schedule.
29
OutlineIntroduction
Android smartphone capabilities
City map construction
Traffic signal schedule inference and
update
Routing and speed advising
Concluding remarks
30
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.
31
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
and are time intervals used to reduce the impact of prediction error, and are empirically set to 10 seconds.
32
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 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.
33
OutlineIntroduction
Android smartphone capabilities
City map construction
Traffic signal schedule inference and
update
Routing and speed advising
Concluding remarks
34
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.
Thank you !
36
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.