1. 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

2. 2 Outline  Introduction  Motivations  Objectives  Android smartphone capabilities  City map construction  Traffic signal schedule inference and update  Routing and speed advising  Concluding Remarks

3. 3 Motivation I/II  Without traffic signal schedule information, vehicles’ accelerating and stopping cause increased fuel consumption, air pollution and accidents. Fuel burnedEnergy wasted

4. 4 Motivation II/II  Smartphones are ubiquitous, it’s easy to deploy intelligent transportation system on a smartphone in each vehicle.

5. 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. 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. 7 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

8. 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. 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  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 East Down

10. 10 Coordinate system transformation

11. 11 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

12. 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. 13 Locating candidate intersections  Using mean shift to localize possible intersections: Possible locations of intersections.

14. 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. 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. 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. 17 Linking intersections

18. 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. 19 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

20. 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: I 1, O 3 ; ID} to the server.

21. 21 Traffic signal phase and phase sequence inference

22. 22 Traffic signal phase and phase sequence inference

23. 23 Traffic signal phase and phase sequence inference

24. 24 Traffic signal phase and phase sequence inference

25. 25 Traffic signal phase and phase sequence inference

26. 26 Traffic signal timing calibration and update Process start time (first event time) Process start time after calibration

27. 27 Traffic signal timing calibration and update

28. 28 Traffic signal timing calibration and update

29. 29 Outline Introduction Android smartphone capabilities City map construction Traffic signal schedule inference and update Routing and speed advising Concluding remarks

30. 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. 31 Best speed calculation

32. 32 Best speed calculation

33. 33 Outline Introduction Android smartphone capabilities City map construction Traffic signal schedule inference and update Routing and speed advising Concluding remarks

34. 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.

35. Thank you !

36. 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.