http://myride.heinz.cmu.edu
myRide is a real-time transit information system for the Carnegie Mellon University Shuttle. It was built by Heinz College graduate students in the fall of 2009. The pilot will end in December 2009, but the website (http://myride.heinz.cmu.edu) will remain up as we work to make myRide a permanent system at Carnegie Mellon.
myRide: A Real-Time Information System for the Carnegie Mellon University Shuttle
1. a a real-time pilot for the CMU Shuttle Daiying Chen DAVId LevinsonAddam Hall KAREN MESKOLisa Hall EI EI MIN THUNolan Leavitt SUDHEER SOMESHWARA Fall 2009 Heinz College, Carnegie Mellon University
5. Our Solution: Real-Time Information Real-Time Transportation Information Cutting-edge technology Novel solution to reliability problems Many benefits To riders To transit providers To community
7. Deliverables Port Authority Technical Capabilities Report Public Transit Ridership Surveys myRide website - http://myride.heinz.cmu.edu Funding Request for permanent system Future coursework plans Android Phone GPS tracking application Google Transit Feed Specification compliant database Mobile Webpage Project Document Report
8. Benchmarking University of Michigan TransLoc ~60-bus fleet covers 10 routes ~Magic Bus was designed by students ~Maintained by staff and students ~Funded by Transportation Dept. ~Newer company based in Raleigh ~Provides services for 15 schools, including Princeton, Auburn, and Yale
9. Internal CMU Ridership Survey Goal: identify the most effective and desired dissemination methods for the CMU shuttle Small, N= 51 Conducted in person at CMU Shuttle stops and on the Shuttle. Time frame: Weekdays at various times in mid-October.
10. CMU Ridership Survey Takeaways Shuttle riders do have issues with the timeliness of service. A wide range of people use the shuttle. Shuttle riders have very high levels of access to Internet and Text plans. iPhones would not be the most effective way to reach the largest number of people. Focus on a webpage that can be viewed on mobile devices.
11. Pittsburgh Community Survey Goal: Measure attitudes and perceptions in regards to public transit and technology. Key factors we wanted to measure: Ridership habits Factors affecting demand elasticity for public transit Access to information dissemination methods Receptiveness to various real-time services Perceived value of a real-time system The questions posed to respondents were modeled after a series of questions used in a 2006 study by the FTA in estimating benefits of a real-time system. Source: Real-time Bus Arrival Systems Return on Investment Study. Federal Transit Administration, 2006.
12. Pittsburgh Community Survey Methodology Our survey was limited in breadth and depth by a limited time frame and limited resources. The sample size is not intended to be a random sampling of Allegheny County residents; instead, it attempts to measure riders and advocates in the Oakland-Downtown corridor. N=148 Survey conducted in-person and online 31% Random sample of pedestrians and bus riders in the Oakland corridor and downtown 35% Students, faculty and professionals in the Higher Education field 34% Developmental, cultural and transportation advocacy groups
16. Pittsburgh Community Survey Takeaways When compared with other metro regions, the Oakland-Downtown corridor has: The FTA estimated that a system widereal-time system would increase ridership by 6%-8%. Source: Real-time Bus Arrival Systems Return on Investment Study. Federal Transit Administration, 2006.
17. Scope Framework Transmitting Real-time Bus Location Part Bus with GPS Send GPS data to Web server G-phone & T-mobile Web Application Web server Mobile Web Riders Map Plug In Estimated Time Module Location Retrieval Module Accessing Real-time BUS Location Part GTFS Data Schema
18. Use Case Diagram myRide System Add new Alert for riders Start auto-GPS transmission for any Route Add another Admin user Transport Admin Stop auto-GPS transmission for any Route View myRide on their Mobile Phone View Current Bus location on the map Driver View estimated arrival time for their bus stop Change the Route View full schedule for each route Rider General User Use Twitter to follow, share the updates
25. Highlighted tables are GTFS-compliant schema Improve scalability and future enhancement with Google GTFS-Compliant Database Schema
26. Data Source Challenges Bus stop information not available Collected bus stop information Obtained GPS longitude/latitude from Google Maps Collaborated with drivers to get accurate schedule Route and schedule data population 3 Routes 23 Stops 78 Trips 1140 records of Stop-times
28. Runs as background service on Google Android Phones Transmits GPS data every 5 seconds Easy to use for different routes User-friendly User Interface (UI) for Shuttle Drivers GPS Transmission
29. GPS Transmission Challenges Get GPS Learning curve of Android Platform GPS providers Network vs. GPS satellite provider Adjusting GPS transmission interval 1 minute or 50 seconds or 5 seconds Performance vs. Accuracy Deployment to real phone Versions crisis GPS background service challenge Reliability of hidden service Does phone screen lock stop our application? Transmit to Web Server Background Service
31. Challenges Behind the Scene Geographic Information System Calculating distance by Vincenty’s formula with ellipsoidal model of earth Accuracy within 0.5mm[1] Route distances vs. straight-line distance Mapping raw GPS to nearest bus stop Geocoding with Google Map Reverse Geocoding Encoded Geopolyline mapping Ajax and timer for updating real-time Cross-Browser Compatibility [1] Source: http://www.movable-type.co.uk/scripts/latlong-vincenty.html
32. Challenges: Estimated Time Prediction Inaccurate schedule stop times Exponentially Weighted Moving Average Problem with frequent stop times Kalman-Filter Prediction Algorithms[1] Consider dwelling times Various Scenarios Select stop time Schedule time Last trip [1] Source: Prediction Models of Bus Arrival and Departure Times, University of Toronto
33. Challenges: Estimated Time Prediction Is Schedule running? No Display Not Running Now Yes Display Location without Time Get Latest GPS data Yes Last Trip of the day and passed by? Is GPS data outdated? Yes Get Next Schedule Time Yes No No speed? Or Morewood is in between? No Get the distance and speed to selected stop Predict time
34. Mobile Phone Interface
35. Challenges Display and bandwidth limitations Layout changes for mobile Decrease page load time Request redirection Device detection Users Request
40. Test Reports Test for Route AB – by Ei Ei Min Thu 11/08/09 Procedure: attached the phone on bus window without interaction. Phone is charged with laptop on.
48. Acknowledgements Robert Hampshire (team advisor) (donation of G1 Phones) CMU Shuttle: Lt. Gary Scheimer, Jim Heverly, Jim McNeil, Colton Brown, James Collins, & Jason Brown RamayyaKrishnan, Rick Stafford, Dave Roger, Steve Bland, and Joe Hughes (advisory board) Hillman Foundation Gary Franko (design and printing support)
49. Contact Information Addam Hall (project manager): aehall@andrew.cmu.edu EiEi Min Thu (IT manager): eiei@cmu.edu Robert Hampshire (advisor): hamp@cmu.edu