Leveraging smartphone cameras

Leveraging Smartphone Camerasfor Collaborative Road Advisories

Emmanouil Koukoumidis, Student Member, IEEE,

Margaret Martonosi, Fellow, IEEE, and Li-Shiuan Peh, Member, IEEE

Abstract—Ubiquitous smartphones are increasingly becoming the dominant platform for collaborative sensing. Smartphones, with

their ever richer set of sensors, are being used to enable collaborative driver-assistance services like traffic advisory and road condition

monitoring. To enable such services, the smartphones’ GPS, accelerometer, and gyro sensors have been widely used. On the

contrary, smartphone cameras, despite being very powerful sensors, have largely been neglected. In this paper, we introduce a

collaborative sensing platform that exploits the cameras of windshield-mounted smartphones. To demonstrate the potential of this

platform, we propose several services that it can support, and prototype SignalGuru, a novel service that leverages windshield-

mounted smartphones and their cameras to collaboratively detect and predict the schedule of traffic signals, enabling Green Light

Optimal Speed Advisory (GLOSA) and other novel applications. Results from two deployments of SignalGuru, using iPhones in cars in

Cambridge (MA, USA) and Singapore, show that traffic signal schedules can be predicted accurately. On average, SignalGuru comes

within 0.66 s, for pretimed traffic signals and within 2.45 s, for traffic-adaptive traffic signals. Feeding SignalGuru’s predicted traffic

schedule to our GLOSA application, our vehicle fuel consumption measurements show savings of 20.3 percent, on average.

Index Terms—Smartphone, camera, intelligent transportation systems, services, traffic signal, detection, filtering, prediction,

collaboration.

Ç

1 INTRODUCTION

WITH an ever richer set of sensors, increased computa-tional power and higher popularity, smartphones

have become a major collaborative sensing platform. Inparticular, smartphones have been widely used to sensetheir environment and provide services to assist drivers.Several systems have been proposed that leverage smart-phone GPS, accelerometer, and gyroscope sensors toestimate traffic conditions [11], [21], detect road abnormal-ities [21] and compute fuel-efficient routes [8].

Cameras, in contrast to other smartphone sensors, haveso far been underutilized for automated collaborativesensing. Cameras have been used only for a handful ofparticipatory sensing systems; both image capture andimage analysis are performed by a human user. Suchapplications include the monitoring of vegetation, garbage,and campus assets [24]. In all these services, users mustpoint their smartphone camera to the target object, capturean image and upload it to the central service where ahuman operator will analyze it. The adoption of collabora-tive sensing services that leverage smartphone cameraswithout manual user and operator effort has so far been

hindered because of two false beliefs: 1) the view ofsmartphone cameras is always obstructed (e.g., carried inpockets or placed flat on the table), and 2) image processingrequirements are prohibitively high for resource-con-strained mobile devices.

In this paper, we propose a novel collaborative sensingplatform that is based on the cameras of windshield-mounted smartphones. We show that accurate and near-real-time camera-based sensing is possible. Many driversare already placing their phones on the windshield in orderto use existing popular services like navigation. Once aphone is placed on the windshield, its camera faces the roadahead. Our proposed sensing platform leverages thesecameras to opportunistically capture content-rich images ofthe road and the environment ahead. Inter-device colla-boration is also leveraged to gather more visual road-resident information and distill it into knowledge (services)that can be provided to the drivers. With their cameras, anetwork of collaborating windshield-mounted smartphonescan enable a rich set of novel services.

In this paper, we focus on the description and evaluationof the SignalGuru service [17]. SignalGuru leverages thecameras of windshield-mounted smartphones in order todetect traffic signals ahead and predict their futureschedule. SignalGuru devices collaborate with other regio-nal devices in order to mutually improve their historictraffic signal status information and better predict when thesignal ahead will turn green/red.

Providing real-time services, like SignalGuru, on top of aconfederation of windshield-mounted smartphones andtheir cameras poses several challenges that need to beovercome:

1. Commodity cameras: The quality of smartphonecameras is significantly lower than that of high-end

IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 5, MAY 2012 707

. E. Koukoumidis is with the Department of Electrical Engineering,Princeton University, 5Y-Magie, Faculty Road, Princeton, NJ 08540.E-mail: [email protected].

. M. Martonosi is with the Department of Computer Science, PrincetonUniversity, 1 Brookside Drive, Skillman, NJ 08558.E-mail: [email protected].

. L.-S. Peh is with the Department of Electrical Engineering and ComputerScience, Massachusetts Institute of Technology, 245 East Street, Lexington,MA 02420. E-mail: [email protected].

Manuscript received 7 Sept. 2011; revised 25 Nov. 2011; accepted 10 Dec.2011; published online 22 Dec. 2011.For information on obtaining reprints of this article, please send e-mail to:[email protected] and reference IEEECS Log Number TMCSI-2011-09-0491.Digital Object Identifier no. 10.1109/TMC.2011.275.

1536-1233/12/$31.00 � 2012 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS

specialized cameras used in computer vision andautonomous navigation. Smartphone cameras haveboth lower color quality and lower resolution.Further, as capturing still images is very slow (1-2 seconds on an iPhone 3GS device), video framesshould often be used instead for low-overhead andhigh-frequency image-based detection. This furtherdegrades resolution, as video resolution is only upto 640� 480 pixels for iPhone 3GS and 1;280� 720pixels for iPhone four devices.

2. Limited processing power: Processing video frames todetect visual information takes significant computa-tional resources. In SignalGuru, traffic signal detec-tion is the most compute-intensive task. A trafficsignal detection algorithm that runs on resource-constrained smartphones must be lightweight sothat video frames can still be processed at highfrequencies. The higher the processing frequency,the more accurately SignalGuru can measure theduration of traffic signal phases and the time of theirstatus transitions.

3. Uncontrolled environment composition and false detec-tions: Windshield-mounted smartphones capture thereal world while moving. As a result, there is nocontrol over the composition of the content capturedby their video cameras. Results from one of ourdeployments suggest that the camera-based trafficsignal detection algorithm can confuse variousobjects for traffic signals and falsely detect trafficsignal colors. A misdetection rate of 4.5 percent cancorrupt up to 100 percent of traffic signal predic-tions. Schemes need to be devised to carefully filternoisy image-based object detections.

4. Variable ambient light conditions: Still image and videocapture are significantly affected by the amount ofambient light that depends on both the time of theday and the prevailing weather conditions. Byadjusting the camera exposure time to the fixedluminous intensity of traffic signals, SignalGururobustly detects traffic signals regardless of theprevailing ambient light conditions.

5. Need for collaboration: The visual information that anindividual smartphone senses is limited to itscamera’s view angle. Regional smartphones thusneed to collaborate in order to increase theirinformation reach. In the SignalGuru service, forexample, a device may not be able to see a far-awaytraffic signal, or may not be within view of the trafficsignal for a long enough stretch of time. Collaborationis needed between vehicles in the vicinity (even thoseon intersecting roads) so that devices have enoughinformation to be able to predict the schedule of trafficsignals. Collaboration is also needed in order tomaintain SignalGuru’s data over time and in adistributed fashion within the vehicular network.

Alternatively, collaborative services like Signal-Guru could be implemented on an Internet server,relying on always-available long-range cellular com-munication to the server. However, in this paper, wefocus on a completely infrastructure-less solutionthat relies solely upon opportunistic short-range

communication (ad hoc 802.11g) among the wind-shield-mounted devices. Such a grassroots servicearchitecture may have a more complex design, butavoids the cost of internet servers and the costly,high-latency, low-bandwidth and potentially over-loaded long range cellular connections [15], [16].

It should be noted that we do not consider batterylifetime as a major challenge. Mobile phones can be pluggedinto the ample energy resources of a vehicle. In cases wherethis does not hold, approaches proposed for lifetimemaximization in sensor networks [13], [32] can be used.Such approaches can determine if and when a given deviceneeds to perform certain power hungry tasks (e.g.,SignalGuru traffic signal detection, collaboration withwireless communication).

The contributions of this work are the following:

1. We show that, with their cameras, collaboratingwindshield-mounted smartphones create a powerfulsensing platform enabling a rich set of novelservices. We discuss five such services and proto-type SignalGuru demonstrating the ability of wind-shield-mounted smartphones to effectively detectand predict the schedule of traffic signals. Not onlypretimed but also state-of-the-art traffic-adaptivetraffic signals can be predicted with very goodaccuracy (2.45 s) by using customized SupportVector Regression (SVR) models.

2. Networks of windshield-mounted smartphones cangreatly increase their camera-based sensing frequencyand accuracy by fusing information from the smart-phone’s Inertial Measurement Unit (IMU) to reducethe video area that needs processing. Our IMU-baseddetection window, halves both the processing timeand the misdetection rate for SignalGuru. We alsopropose and evaluate low-pass filtering and a coloca-tion filter that effectively filter away false positiveevent (e.g., traffic signal transition) detections.

3. Many user-focused applications can be built on top ofthe traffic signal prediction system aka SignalGuru. Inparticular, our Green Light Optimal Speed Advisory(GLOSA) system offers speed advisories to avoidundue stops and waits at red lights. Testing thissystem using an onboard fuel efficiency monitor, weshow that when drivers follow the advisory of ourSignalGuru-based GLOSA system, 20.3 percent fuelsavings can be achieved.

In the next sections, we describe SignalGuru in detail. InSection 2, we present the motivation behind SignalGuruand in Section 3 the SignalGuru-enabled GLOSA applica-tion. Section 4 describes the operation of traffic signals andSection 5 the architecture of our collaborative SignalGuruservice. In Section 6, we present our experimental metho-dology and in Section 7, we evaluate the performance ofSignalGuru’s individual modules based on our two real-world deployments. Section 8 discusses the operation ofSignalGuru in complex intersections. In Section 9, wedescribe four more services that windshield-mountedsmartphones could support and discuss their challengesas compared to SignalGuru. Finally, Section 10 surveysrelated work and Section 11 offers our conclusions.

708 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 5, MAY 2012

2 SIGNALGURU MOTIVATION

There are more than 272,000 traffic signals in majorintersections of the USA alone [14], and our daily drivingexperience is significantly influenced by them. Trafficsignals are widespread in developed countries as theyallow competing flows of traffic to safely cross busyintersections. Traffic signals, however, do take their toll.The stop-and-go movement pattern that they impose,increases fuel consumption by 17 percent [2], CO2 emissionsby 15 percent [2], causes congestion [3], and leads toincreased driver frustration [14].

Drivers can be assisted with a Green Light Optimal SpeedAdvisory system [2], [30]. A GLOSA system advises driverson the optimal speed they should maintain when headingtoward a signalized intersection. If drivers maintain thisspeed, the traffic signal will be green when they reach theintersection, allowing the driver to cruise through. In thisway, the stop-and-go movement pattern can be alleviated.

Worldwide, only a handful of GLOSA systems have beendeployed [30], and they have so far been based on roadsidemessage signs (wired to traffic signals). These signs areplaced a couple hundred meters away from the signal anddisplay the optimal speed drivers should maintain. Theircostly and often impractical deployment and maintenance,however, has hindered their widespread usage.

Countdown timers at vehicular traffic signals constituteanother alternative approach to assist drivers; digital timersnext to the traffic signal display the time till the signalchanges from red to green and vice versa. Such trafficsignals are deployed only in a few cities around the world.The cost of updating existing traffic signals to include suchtimers has hindered their widespread deployment.

Countdown timers for pedestrian traffic signals are muchmore common in the USA and the rest of the world, anddrivers can sometimes use these to infer when the light willturn green. However, these are very often not visible fromfar away but only after one has reached the intersection. Atthat time, it is too late for drivers to adapt speed and so theyneed to come to a complete halt anyway. Furthermore, atsome intersections, it is not easy or even possible forthe driver to infer the time the signal will switch; theintersection may have a complex phase schedule and thegreen light for the driver may not come immediately aftersome pedestrian timer counts down to zero.

US and European transportation agencies recognize theimportance of GLOSA and access to traffic signal schedules,and thus have advocated for the integration of short-range(DSRC) antennas into traffic signals as part of their long-term vision. DSRC-enabled traffic signals will be able tobroadcast in a timely fashion their schedule to DSRC-enabled vehicles that are in range. Audi recently prototypeda small-scale DSRC-based GLOSA system for 25 trafficsignals in Ingolstadt (Germany) [2]. Once again, however,the widespread deployment of such an approach has beenhindered by the significant cost to equip traffic signals andvehicles with the necessary specialized computational andwireless communications infrastructure.

In this paper, we take an infrastructure-less approach toaccessing traffic signal schedules by leveraging the pro-posed collaborative platform of windshield-mounted

smartphones and their cameras. Windshield-mountedsmartphones use their cameras to detect and determinethe current status of traffic signals. Multiple phones in thevicinity use opportunistic ad hoc communications tocollaboratively learn the timing patterns of traffic signalsand predict their schedule. SignalGuru’s predicted trafficsignal schedule then enables GLOSA and other possibleapplications on the phone.

3 SIGNALGURU APPLICATIONS: GLOSA

The goal of the GLOSA application is to advise drivers onthe optimal speed they should maintain so that the signal isgreen when they arrive at the next intersection. In this way,the driver can cruise through the intersection withoutstopping. A GLOSA application can offer several benefitssuch as 1) decreased fuel consumption, 2) smoothed andincreased traffic flow (stop-and-go patterns avoided), andas a result of these, and 3) decreased environmental impact.

A GLOSA application needs four pieces of informationin order to be able to calculate the optimal speed:

1. the residual amount of time till the traffic signalahead turns green,

2. the intersection’s (stop line) location,3. the vehicle’s current location, and4. the queue length of the traffic signal ahead.

The first is provided by SignalGuru, the second by mapinformation [23], and the third by the available localizationmechanisms on the mobile device (e.g., GPS). The trafficsignal queue length and the time it will take to discharge canbe estimated by fusing information about the number andpositions of vehicles in the queue as described in [6], [14].

If no traffic signal queue length information is available,and when vehicles are very close (<100 m) to the intersec-tion, GLOSA should switch from a speed advisory to a timecountdown. Drivers can then look at the queue lengthahead and manually estimate their optimal speed.

Although GLOSA may often advise a vehicle to reduceits speed, the vehicle’s total travel time will not beincreased. On the contrary, GLOSA helps decrease averagetravel time by 1-18 percent [1]. Despite the speed reduction,a GLOSA-enabled vehicle will still travel through theintersection at the same traffic signal phase as it would ifit were traveling at its regular speed. Moreover, at the timethe signal turns green, a GLOSA-enabled vehicle will becruising through the intersection with an initial nonzerospeed, as opposed to a regular vehicle that would have tostart from a complete halt.

GLOSA also improves the overall flow reducing con-gestion. The traffic flow is smoother and faster whenvehicles are cruising through the intersections as opposedto when they come to a complete halt and then slowlyaccelerate one after the other to cross the intersection.Traffic flow improvements then lead to further gas andtravel time savings.

The larger the available lead-up time, i.e., the amount oftime in advance that predictions are available, the moreeffective the GLOSA. Predictions that are available at least20 sec in advance, while the driver is perhaps 250 m fromthe traffic light, provide enough room to control the

KOUKOUMIDIS ET AL.: LEVERAGING SMARTPHONE CAMERAS FOR COLLABORATIVE ROAD ADVISORIES 709

vehicles’ speed. The prediction accuracy should be less than10 percent of the traffic signal’s phase length to avoidwasting precious green time (i.e., to avoid vehicles arrivingat the intersection long after the light has switched to green).

Besides GLOSA, SignalGuru’s traffic signal schedulepredictions can be used to enable more applications like aTraffic Signal-Adaptive Navigation (TSAN) service and aRed Light Duration Advisory (RLDA) service [17]. A TSANservice will optimize the suggested route by also takingtraffic signal schedules into account. An RLDA servicewould advise the drivers when switching off their enginewould save them gas while waiting at a red light.

4 TRAFFIC SIGNAL BACKGROUND

In signalized intersections, different but nonconflicting (safeto coexist) vehicular and pedestrian movements aregrouped together to run at the same time. Such groups ofmovements are termed phases. A simple intersectiontypically has two phases. When the light is green for phaseA, vehicles or pedestrians moving North-South can safelymove at the same time. Later, the traffic signal will turn redfor phase A and green for phase B. At this time, vehiclesand pedestrians moving East-West can go. When this phasecompletes, the intersection has completed one cycle and thelight will turn red again for phase B and green for phase A.Many intersections may have more than two phases. Theamount of time that the light stays green in a given phase isphase length. The sum of all phase lengths of an intersectionis cycle length.

Most traffic signals in the US are pretimed traffic signals[25]. For pretimed traffic signals, the settings (phaselengths, cycle length) of the traffic signals are fixed andthe exact same schedule repeats in every cycle. The settingsonly change when the intersection switches mode ofoperation depending on the day or the time of day.Typically, pretimed traffic signals have three modes ofoperation: 1) off-peak, 2) a.m. peak, and 3) p.m. peak.Sometimes, there is a special schedule for Saturday peak.

In contrast to the US, Singapore adaptively controls itstraffic signals using the state-of-the-art GLIDE system thatis adapted from the SCATS system [27]. SCATS adaptivelyadjusts settings of the traffic signals based on measurementsfrom its inductive loop detectors. One loop detector isinstalled per lane and placed beneath the road surface at theintersection stop line. Loop detectors, while the light isgreen, measure the saturation of their lane. Specifically, lanesaturation is calculated as a function of the number ofvehicles that traveled over the corresponding loop detectorand the measured total gap time (i.e., amount of time thatthe loop detector is unoccupied). Lane saturations aremerged to calculate a phase’s saturation.

SCATS adjusts traffic signal settings in order to balancethe saturation across the different phases of the intersection.The higher the saturation of a phase (more vehicles), thegreater portion of the cycle length is allocated to the specificphase. Cycle length duration is adjusted depending on thesaturation of all the phases of the intersection and increaseswhen the maximum phase saturation increases. Longercycles allow intersections to operate more efficiently (higher

throughput), but increase the waiting times and frustrationof drivers. SCATS measures phase saturations and changesthe intersection traffic signal settings accordingly everycycle, i.e., every 1-3 minutes.

5 SIGNALGURU ARCHITECTURE

SignalGuru aims to detect and predict the schedule of trafficsignals using just software on commodity smartphones. It isa grassroots software service that leverages opportunisticsensing on mobile phones to detect the current color oftraffic signals, share with nearby mobile phones tocollectively derive traffic signal history, and predict thefuture status and timing of traffic signals.

Fig. 1 shows the modules in the SignalGuru service.First, phone cameras are used to capture video frames,and detect the color of the traffic signal (detectionmodule). Then, information from multiple frames is usedto filter away erroneous traffic signal transitions (transitionfiltering module). Third, nodes running the SignalGuruservice broadcast and merge their traffic signal transitionswith others in communications range (collaboration mod-ule). Finally, the merged transitions database is used topredict the future schedule of the traffic signals ahead(prediction module).

The prediction of the future schedule of traffic signals isbased on information about past time stamped R! G (redto green) transitions. The prediction is based on R! Gtransitions, as opposed to G! Y (green to yellow)


Fig. 1. SignalGuru service architecture.

transitions, because vehicle-mounted smartphones canwitness and detect R! G transitions much more fre-quently; when the traffic signal is red, vehicles have tostop and wait till the signal turns green. As a result, it isquite likely that a vehicle will be at the intersection at themoment that the R! G transition occurs and thus detect it.For a G! Y transition to be detected, the vehicle needs tobe driving toward the intersection and have good view(�50 meters away) of the signal when the signal colorchanges. As a result, it is much less likely1 for a vehicle to beclose enough to the intersection at the moment of the G! Ytransition. The same applies also for Y! R transitions.Section 5.4 discusses how time stamped R! G transitioninformation is used to predict the traffic signal schedule.

5.1 Detection Module

The detection module detects and reports the current colorof potential traffic signals in the captured video frames. Thedetection module is activated based on its GPS location2

and only when it is close (<50 m) to a signalizedintersection. The video frames are captured using thestandard iPhone camera. As Fig. 3 shows, when thesmartphone is mounted on the windshield, this camera isfacing outside and thus able to capture videos of the trafficsignals ahead. This is just as users would mount theirsmartphone when using a navigation or other travel-relatedapplication.

5.1.1 Detection Algorithm

SignalGuru’s traffic signal detection module must belightweight and fast so that the color of traffic signals canbe sensed as frequently as possible, and the time oftransitions is detected as precisely as possible. The timeaccuracy of color transition detections directly affects thetime accuracy of predictions, as Section 5.4 explains. OurSignalGuru detection module is able to process a freshframe every 2 seconds.

Fig. 2 shows our image processing algorithm used toprocess video frames for the purpose of detecting trafficsignals. The algorithm is based on the three mostcharacteristic features of a traffic signal, which are thebright red/yellow/green color of its bulbs, the shape of itsbulbs (e.g., circle, arrow) and its surrounding black box(traffic signal housing).

The first step of the detection algorithm is the colorfiltering process, as the most distinctive feature of trafficsignals is the bright color of their bulbs. The color filterinspects the color of all pixels of an image (video frame) andzeroes out the pixels that could not belong to a red, yellow,or green traffic signal bulb. Thus, the color-filtered imagecontains only objects that have the correct color to be atraffic signal bulb. The color filter was designed empiricallyby analyzing the color range of red, yellow, green bulbpixels from a set of 400 traffic signal pictures.3 This filter isfairly computationally lightweight when performed in thedevice’s native colorspace (i.e., RGB). It also manages tozero out most of an image, reducing computing needs insubsequent stages. For all these reasons, the color filteringstage comes first.

After color filtering, only objects that have the correctcolor are maintained in the image. The next stages examinewhich of them qualify to be a traffic signal based on theirshape (e.g., circle, arrow). This is achieved by firstapplying a Laplace edge detection filter that highlights


Fig. 2. Traffic signal detection algorithm. “NS” stands for “No Signal” andis the status returned by the detection module when no traffic signal canbe detected with a confidence higher than the threshold value.

Fig. 3. SignalGuru-enabled iPhone mounted on the windshield. The

OBD-LINK device used to measure fuel consumption is also shown.

1. In our Singapore deployment (Section 6.2), vehicles witnessed a totalof 37 R! G transitions but only two G! Y transitions.

2. We configure the iPhone’s GPS to return location stamps of themaximum possible accuracy and frequency.

3. We used a different color filter for Cambridge and Singapore as thetwo cities use traffic signals implemented with different technologies.

the boundaries of the color filtered objects and then aHough transform. The Hough transform uses a votingmechanism (accumulator) to decide which objects constitutethe best traffic signal bulb candidates based on their shape.

Once the Hough transform voting is completed, theaccumulator determines which object has the most votesand is thus the best candidate to be a traffic signal. Theaccumulator contains information about the location of thebest candidate in the image as well as its size (e.g., radius).

Then, the pixels of the candidate area are inspected todecide on the color of the bulb and count exactly whatpercentage of the pixels falls into the correct color range.This percentage is termed the Bulb Color Confidence (BCC).BCC helps to avoid confusing, for example, road signs witha circular red perimeter but a different color in the center(e.g., right turn prohibited sign) as a red signal.

According to the color and size of the bulb, a specificarea around the bulb is checked for the existence of ahorizontal or vertical black box, the traffic signal housing.For example, if the bulb is red, the area below or on the leftis searched for a vertical or horizontal traffic signal blackbox, respectively. A Black Box Confidence metric is alsoreported based on how many pixels of the searched area aredark enough to qualify as traffic signal black box pixels.

The product BCC �BBC constitutes the detection con-fidence for a specific object in the video frame. If thedetection confidence is higher than a threshold value, thenthe detection is considered valid and the traffic signal withthe detected color is reported. If not, the next best candidatefrom the Hough transform accumulator is examined. Wefound that a detection confidence threshold of 0.6 yieldedthe lowest detection false positive and false negative ratesfor our database (400 pictures). We also found that there islittle additional value in inspecting more than the 10 bestcandidates of the Hough voting mechanism. As a result, thelooping criterion in Fig. 2, N, is set to 10 for our work.

5.1.2 IMU-Based Detection Window

For visibility and other practical reasons, traffic signals areplaced high above the ground. As a result, traffic signalsoften appear only in the upper part of a captured videoframe. As shown in Fig. 4, the lower half of the imagecaptures the road and other low-lying objects, whereasthe traffic signals are located in the upper half. The part ofthe image where the traffic signal can be located dependsnot only on the orientation of the windshield-mountedsmartphone, but also on the distance from the traffic signal;the closer the phone to the traffic signal, the higher thesignal appears in the image.

SignalGuru leverages information from the smart-phones’ inertial sensors to narrow its detection window, i.e.,the part of the image where traffic signals are expected toappear. More specifically, SignalGuru uses informationfrom the accelerometer and gyro-based Inertial Measure-ment Unit of the smartphone to infer its orientation (rollangle) and information from its GPS device to calculatedistance from the signal.

With this information, the size of the detection windowcan be easily calculated analytically. The calculation is leftout in the interest of space. The IMU-based detectionwindow is shown with a red bounding box in Fig. 4.

The IMU-based detection window scheme enablesSignalGuru to ignore a large portion of a captured framethat can have nothing but noise, providing twofold benefits.First, the image processing time is almost halved. Second,the traffic-signal detection is significantly improved. Thebenefits of this scheme are evaluated in Section 7.2.

5.1.3 Variable Ambient Light Conditions

Ambient light conditions significantly affect the quality ofcaptured still images and video frames. The amount ofambient light depends on both the time of the day and the


Fig. 4. SignalGuru service screenshot. GLOSA advisory has also been included in the same iPhone application. Audio advisory can complement thevisual advisory to alleviate driver distraction.

prevailing weather conditions (sunny versus cloudy).Smartphone cameras automatically and continuously adjusttheir camera exposure setting to better capture the targetscene. Nevertheless, we found that traffic signals are oftennot captured well with their bulbs appearing either too dark(underexposed) or completely white (overexposed). As aresult, the detection module would perform very poorly insome cases.

Traffic signals, however, have a fixed4 luminous inten-sity. We leverage this by adjusting and locking the cameraexposure time to the fixed intensity of traffic signals. Thiseliminates the sensitivity of traffic signal detection to time ofday or weather. The camera exposure time is automaticallyadjusted by pressing the “Adjust Exposure” button andpointing the camera to a traffic signal. Then, by pressing the“Lock Exposure” button the setting is recorded and locked,obviating the need for further adjustments.

5.2 Transition Filtering Module

The raw detection of traffic signals and their color transi-tions (R! G) given by the detection module is fairly noisy.In our Singapore deployment, in 65 percent of the cases thata vehicle is waiting at a red traffic signal, it reports a falsepositive transition, i.e., a transition that did not actuallyoccur. Typically, the image detection module was detectingthe actual red light and then happened to misdetect somearbitrary object for a green light. Note that vehicles werewaiting at the intersection for 48 s, on average, capturingand processing perhaps dozens of video frames. If nothandled properly, a single false green light detection wouldbe enough to erroneously generate a transition report.Similarly, if a vehicle happens to misdetect an arbitraryobject for a red light in between detections of the actualgreen light, a false transition would be reported.

While ideally, we would like to be able to detect andreport all R! G transitions witnessed (no false negatives),it is even more critical to avoid false positives (reports oftransitions that never happened), because false positivespollute the prediction scheme. Therefore, we filter R! Gtransitions using a two-stage filter: a low-pass filter (LPF)followed by a colocation filter.

5.2.1 Low-Pass Filter

According to our findings from our Singapore deployment,in 88 percent of the cases, false positive detections occurover a single frame and do not spread over multipleconsecutive frames. As a result, most false transitions haveone of the following three patterns with the false detectionmarked in bold:

1. R! � � � ! R! G! R! � � � ! R.2. G! � � � ! G! R! G! � � � ! G.3. NS! � � � ! NS! R! G! NS! � � � ! NS.

The first (most common) pattern occurs when the vehicleis waiting at the red light, it correctly detects, then at aspecific instance it misdetects a passing object (e.g., designon a bus crossing the intersection) for a green traffic light.The second pattern occurs when the vehicle misdetects an

arbitrary object for a red light in between detections of theactual green light. Finally, the third pattern occurs when theview of the vehicle is obstructed and there is no trafficsignal in sight. However, at some point, it misdetects anarbitrary object for a red light and right after that a differentobject for a green light. This pattern is the least common.

The LPF filters out such “spikes” or anomalies acrossmultiple traffic signal transitions by adding some hyster-esis. The LPF classifies only transitions that have the R!R! G! G pattern as valid, i.e., at least two red statusreports followed by at least two green status reports. As ourresults in Section 7.3 show, the LPF filters the vast majorityof false positive transitions at the cost of creating only asmall number of false negatives (actual transitions removedby the filter).

5.2.2 Colocation Filter

A distinctive feature of traffic signals, as opposed to otherobjects with similar colors and shape, is that the red andthe green bulb are contained in the same black box; that is,they are colocated. SignalGuru’s filtering module leveragesthis by checking whether detected red and green bulbs arecolocated before accepting a transition as valid. Morespecifically, the colocation filter checks whether the greenbulb that was just detected is close to the red bulbdetected in the previous frame. Note that the accumulatorof the Hough transform pinpoints the location of thetraffic signal candidates.

Given that SignalGuru can capture and process videoframes every 2 s, the average delay between the lightturning green and SignalGuru capturing this event in itsnext video frame is 1 s. In 1 s or even 2 s that is themaximum possible green light capture delay, a vehicle willnot have accelerated and moved significantly. Hence, thereis no need to compensate for vehicle movement.

However, as exemplified in Fig. 3, many intersectionshave two or more traffic signals for the same phase ordirection of traffic. Therefore, the red and green bulbs maybe detected on different traffic signals across the twoframes. To tackle this, before the colocation filter rejects atransition as invalid, it invokes the detection module tocheck whether there exists, in the current frame, a greenbulb that is collocated with the red bulb of the previousframe. In this case, the detection window covers only a verysmall area around the red traffic signal of the previousframe, and thus incurs negligible computational overhead.

As shown in Section 7.3, the colocation filter effectivelyfilters out false positive transitions at the cost of a smallincrease in false negatives. Together, the LPF and thecolocation filter form a very robust two-stage filter.

5.3 Collaboration Module

SignalGuru depends on the grassroots collaboration amongthe participating nodes (smartphones). A node is limited byits field of vision, and does not have all the information itneeds in order to predict the schedule of the traffic signalsahead. Typically, a node needs information about a trafficsignal well before the signal comes into the node’s camerafield of view.

For the prediction of traffic-adaptive traffic signals,collaboration is even more critical. As we explain in


4. LED traffic signals have fixed luminous intensity. Older incandescenttraffic signals do not, but are quickly becoming obsolete. Both Cambridgeand Singapore use LED traffic signals.

Section 5.4.2, in order to be able to predict traffic-adaptivetraffic signals, information from all phases (intersectingroads) of an intersection is needed. Furthermore, Sec-tion 7.4.3 shows how more collaborating nodes and moretraffic signal history can improve the prediction accuracyfor the challenging traffic-adaptive traffic signals ofSingapore.

The collaboration module allows participating Signal-Guru nodes to opportunistically exchange their trafficsignal information (time stamped R! G transitions) byperiodically (every two seconds) broadcasting UDP pack-ets in 802.11 ad hoc mode. A SignalGuru node broadcastsnot only the data it has sensed on its own, but also thedata it has opportunistically collected so far. Only dataabout the traffic signal transitions of the last five cycles areexchanged. We found that using a longer history of datadoes not significantly improve the traffic signal predictionaccuracy.

In order to be able to predict the schedule of the trafficsignals ahead, nodes need either the database of the trafficsignal settings (for pretimed traffic signals) or the SupportVector Regression prediction models (for traffic-adaptivesignals). This information is passed to a node along withthe sensed transition data before the node approaches thecorresponding traffic signals. However, it is likely that thisnode will have also crossed the traffic signal ahead in therecent past (e.g., yesterday due to daily commute). In thiscase, the sizeable (62 KB) SVR prediction models do notneed to be resent as they are relatively static (Section 7.4.3).The settings for a pretimed traffic signal can be encoded injust a couple bytes and thus resending them incursnegligible overhead.

The amount of traffic signal information5 that Signal-Guru nodes gather and exchange can be constrained bytiling a geographic area into regions and having SignalGurunodes maintain and exchange data that belongs only totheir current region. Methods for tiling a region intosubregions for the purpose of ensuring data availabilityand load balancing are beyond the scope of this paper.Furthermore, the aggregate regional resources for theoperation and maintenance of the SignalGuru service canbe kept at bay by running SignalGuru atop resource-awaremiddleware like RegReS [16].

5.4 Prediction Module

Two main categories of traffic signals exist: pretimed andtraffic-adaptive traffic signals. Since their operation is verydifferent, SignalGuru uses different prediction schemes (PS)for each category.

5.4.1 Pretimed Traffic Signals

SignalGuru’s prediction module maintains a database ofthe traffic signal settings. As described in Section 4,pretimed traffic signals have fixed preprogrammed settingsfor their different modes (a.m./p.m. peak, off-peak, Satur-day peak). Traffic signal settings can be acquired from citytransportation authorities. In case they are not available, the

settings (phase lengths) can be measured as described inSection 5.4.2. This means that SignalGuru knows how longeach phase lasts. The challenge remains to accuratelysynchronize SignalGuru’s clock with the time of phasetransition of a traffic signal. Once this is achieved,SignalGuru can very easily predict when the traffic signalwill switch again to green, yellow, or red.

Clock synchronization is achieved by capturing a colortransition, e.g., R! G. Fig. 5 shows a timeline of events. Ifthe time stamps of the last red and first green colordetections for phase A are t0A;R and t0A;G, respectively, thenthe detected transition time is t0A;R!G ¼ ðt0A;R þ t0A;GÞ=2.

The time the traffic signal will switch to red forphase A (and green for phase B) can be predicted byadding the predicted6 length of phase A (PL0A) to t0A;R!Gas �B;R!G ¼ t0A;R!G þ PL0A. Since this intersection has onlytwo phases, phase A will follow after phase B, as phasesare scheduled in a predictable, round-robin way. Byadding (PL0B) to �B;R!G, we get the next R! G transitionfor phase A, and so on.

Clock synchronization needs to be reestablished onlyafter the traffic signal changes mode of operation or recoversfrom an operational failure. As a result, the necessaryparticipation requirements for the detection of pretimedtraffic signals is very low. Only a few vehicles are required,as traffic signal transitions need to be detected only onceevery a couple hours or potentially at even lower frequen-cies. Unless a cloud server is used, more vehicles may benecessary, however, for the maintenance of SignalGuru’sdata around the area of the corresponding traffic signals.

5.4.2 Traffic-Adaptive Traffic Signals

The Singapore GLIDE (SCATS) system is one of the world’smost sophisticated and dynamic traffic-adaptive trafficsignal control systems. As described in Section 4, SCATSmeasures the saturation of intersection phases and adjuststheir phase lengths at every cycle. Phase lengths changewhen SCATS changes the value of the cycle length or thefraction of the cycle length that gets allocated to them.SCATS may choose to change both settings at the sametime. Phases are still scheduled in a deterministic round-robin manner.

SignalGuru predicts future transitions (e.g., when thesignal ahead will turn green) by detecting past transitions


5. Sensed traffic signal transitions, database of traffic signal settings andSVR prediction models for pretimed and traffic-adaptive traffic signals,respectively.

6. For pretimed traffic signals, the predicted phase length is the valuelooked up in the traffic signal settings database.

Fig. 5. Timeline of traffic signals operation and SignalGuru’s detectionsand predictions for a simple intersection with two phases (A and B). Theletters on the timeline denote for which of the two phases the light isgreen. The time stamps of actual, detected, and predicted phasetransitions are also marked with t, t0 and � , respectively. PLA is theactual length of phase A and PL’A its predicted value. "d and "p are thecolor transition detection and prediction errors, respectively.

and predicting the length of the current or next phases. Thekey difference from the prediction of pretimed trafficsignals lies in the prediction of the phase length, as opposedto looking it up from a database.

SignalGuru predicts the length of a phase by measuringand collaboratively collecting the prior traffic signal transi-tion history, and feeding it to a Support Vector Regression[4] prediction model. In Section 7.4.3, we evaluate theprediction performance of different Prediction Schemes bytraining the SVR with different sets of features

. PS1: The past lengths of the specific phase. Forexample, the next length of phase A is predictedbased on history information such as the lengths ofthe five previous phases of A. We found that furtherincreasing the length of the history does not yieldany benefits. Similarly, SCATS uses only loopdetector measurements performed over the last fivecycles to determine the next traffic signal settings.

. PS2: Like PS1, but the length of the preceding phasesof the same cycle is also provided. This means thatwhen trying to predict the length of phase C, thelengths of preceding phases A and B are also fed tothe SVR model. As our results show, this informa-tion significantly improves the performance of theprediction module. The reason is that changes to agiven cycle’s phase lengths are correlated; whenSCATS changes the cycle length setting, all phaseschange in the same way.

. PS3: Like PS2, except that information for the past5 cycle lengths is also factored in.

. PS4: In addition to PS3’s features, this schemeassumes the predictor has access to loop detectorsaturation information, which is not currently fea-sible. Saturation values over the past 5 cycles are fedto the SVR model. Note that traffic (vehicle speed)estimation is not a good proxy for the unavailableloop detector measurements. Average vehicle speeddoes not always correlate well with the saturationmeasured by SCATS’s loop detectors; a specificphase, despite the fact that vehicles are moving fast,may be highly saturated (with dense flow).

In order for SignalGuru to be able to use any of the firstthree feasible prediction schemes, the lengths of the pastphases need to be measured. While it is easy forSignalGuru to detect the R! G transition for the begin-ning of a phase, as explained in Section 4, it is very hard todetect the G! Y transition for the end of the phase. Toremedy that, collaboration across nodes waiting at thedifferent traffic signals of the same intersection is lever-aged; the G! Y transition of a given phase is inferred bythe R! G transition of the successor phase that wasdetected by nodes waiting at the traffic signal of thesuccessor phase. For example, the fact that the light turnedgreen for phase B at time t means that it turned yellow forphase A at time t minus the clearance interval. The clearanceinterval is a fixed setting and is the amount of time a phaseis yellow plus the amount of time all phases are red beforethe next one turns green. As its name denotes, it gives theprevious phase enough time to clear before the nextconflicting phase starts.

A week of history data is enough to train the SVR model.Furthermore, as our results show, the SVR model does notneed to get continuously retrained. Retraining the modelevery four to eight months is frequent enough in order tokeep the prediction errors small.

On the other hand, real-time (on a minute-by-minutescale) traffic signal transition data are necessary in order toeffectively drive the prediction models. As we show inSection 7.4.3, the less complete and the older the availablehistoric information is, the lower the prediction accuracybecomes. Because of the highly dynamic nature of traffic-adaptive traffic signals, significantly higher participation(about two orders of magnitude) is required for them ascompared to pretimed traffic signals.

6 METHODOLOGY

6.1 Cambridge Deployment

As mapped in Fig. 6, our November 2010 deployment inCambridge targeted three consecutive intersections onMassachusetts Avenue. We used five vehicles with iPhonesmounted on their windshields and asked the drivers tofollow the route shown for �3 hours. Note that theopportunity for node encounters (within ad hoc wirelessrange) was small, as all the vehicles followed the same routeso they are rarely in range of each other. To rectify this, anextra iPhone device was held by a pedestrian participantlocated at the intersection of Massachusetts Avenue andLandsdowne Street. This SignalGuru device served as an adhoc data relay node facilitating data exchange between thewindshield-mounted iPhone nodes. Only the collaborationmodule was active on the relay node. The experiment tookplace between 1:20-4:30 pm. At 3:00 pm, the traffic signalschanged operation mode from off-peak to afternoon peak.

6.2 Singapore Deployment (Bugis Downtown Area)

Our other deployment was in Singapore in August 2010.Unlike Cambridge, the Singapore deployment tests Sig-nalGuru on traffic-adaptive traffic signals. To measurephase lengths and predict the schedule of traffic-adaptivetraffic signals, SignalGuru needs to monitor all phases ofan intersection, i.e., orthogonal directions of a traffic


Fig. 6. Route of vehicles in Cambridge deployment. The targetedintersections are marked with circles. P1 and P2 are the start and endpoints, respectively, for our GLOSA experiment trip.

intersection. Hence, in this deployment, we had two sets ofvehicles following the two distinct routes shown in Fig. 7.In this way, both phases of the intersection (Bras Basah andNorth Bridge Road in Singapore’s downtown) weresensed. Phase A corresponds to vehicles moving alongBras Basah Road and phase B to vehicles moving alongNorth Bridge Road.

We used eight iPhone devices in total and mounted themon the windshields of taxis. Five devices were moving onthe longer route of phase A and the other three on theshorter route of phase B. Similarly to our deployment inCambridge, an extra iPhone device was used as a relaynode. In this case, the relay node was also recording theground truth,7 i.e., when the traffic signals status transi-tioned. Ground truth information was only used for offlineevaluation of SignalGuru’s accuracy thereafter. It was notshared with other participating nodes. The experiment tookplace from 11:02-11:31 am (�30 min).

7 SIGNALGURU EVALUATION

Here, we evaluate the performance of each of SignalGuru’smodules before evaluating its overall performance in twodeployments in Cambridge and Singapore. We alsoperformed a large-scale analysis for SignalGuru’s predic-tion accuracy based on the data we collected fromSingapore’s Land Transport Authority (LTA).

7.1 Traffic Signal Detection

We evaluate the performance of SignalGuru’s detection

module for our two deployments. In Fig. 8, we show both

the percentage of false negatives (traffic signals that did not

get detected) and the percentage of false positives (arbitrary

objects confused for traffic signals of a specific color).

Results are averaged over 5,959 frames and 1,352 frames for

the Cambridge and Singapore deployments, respectively.

The average misdetection rate that includes both false

negatives and false positives was 7.8 percent for Cambridge

and 12.4 percent for Singapore deployment. In other words,SignalGuru’s detection module correctly detected theexistence (or the lack) of a traffic signal in 92.2 and87.6 percent of the cases in Cambridge and Singapore,respectively. Note that most (>70 percent) video frames arecaptured while vehicles are waiting at the red light. Hence,the average (mis)detection rate is strongly biased by theresults for “R,” i.e., frames with a red traffic signal.

As Fig. 8 shows, the detection module is particularlymore likely to report a false positive when there is no trafficsignal in sight. When a traffic signal is captured in the videoframe, the actual traffic signal will normally get the mostvotes in the Hough transform’s accumulator and a validdetection will be recorded. If there is no traffic signal insight, the detection module will try to find the best possiblecandidate object that most resembles a traffic signal in termsof its color, shape, and enclosing black box, which cantrigger more false positives.

Furthermore, the ratio of false positives of differentcolors differs significantly across the two deployments. Forexample, in Cambridge, yellow light false positives aremore common than in Singapore, where there are moregreen light false positives. This is because of the prevailingambient light conditions and the object composition of theenvironment at the targeted intersections. In Singapore,there were many more trees and also a black electronicmessage board with green letters, whereas in Cambridge,the sun was setting, giving a strong yellow glare to severalobjects (e.g., road signs, vehicles, buildings, etc.).

Another interesting observation is that the number offalse negatives (missed traffic signal detections) is almostdouble in the Singapore deployment, as compared to theCambridge deployment. The reason lies in the traffic signalbulbs used in each city. Singapore’s LED bulbs are exposed,whereas Cambridge’s are covered by a refraction lens. TheLED traffic signal bulbs consist of an array of smaller LEDsthat is refreshed in columns at a relatively low frequency.The refresh frequency is high enough to be invisible to thehuman eye but low enough to be detectable by a camerawhen there is no refraction lens covering the bulb. InSingapore, the camera would thus sometimes capture thebulbs with dark stripes (columns) of unrefreshed LEDs,


7. In our Cambridge deployment, since the schedule of the signals isfixed, it can be easily inferred from the images logged by the windshield-mount iPhones. Hence, there was no need to record the ground truth withan extra iPhone device.

Fig. 7. The two distinct routes of taxis in Singapore deployment in theBugis downtown area. Routes A and B correspond to phases A and B ofthe targeted intersection, respectively. The targeted intersection ismarked with a circle.

Fig. 8. Traffic signal detection module evaluation. R/Y/G/NO stands forvideo frames where the traffic signal is actually Red/Yellow/Green ornonexistent. A false negative is when the module fails to detect theexisting traffic signal. A false positive is when the module confuses anarbitrary object for a traffic signal of a specific R/Y/G status. We omitted“Y” results as there were very few such frames and hence the detectionresults are not statistically important.

reducing the probability of a successful traffic signaldetection.

7.2 IMU-Based Detection Window

In this section, we evaluate the benefits that the IMU-baseddetection window offers. The iPhones were orientedhorizontally, as shown in Fig. 3. The lower line of thedetection window will thus be horizontal and across thecenter of the image when the vehicle is at a distance of�50 m from the intersection. Using online/offline trafficsignal detection, we collected results for when the IMU-based detection window was activated/deactivated. Theoffline detection was based on the same video frames thatwere logged and processed by the iPhone devices online.

Fig. 9 shows that the IMU-based detection windowalmost halves the average misdetection rate, reducing itfrom 15.4 to 7.8 percent. Above all, the IMU-based detectionwindow significantly reduces the number of red falsepositives; when the detection window scheme is not usedand the whole video frame is processed, the detectionmodule often confuses vehicles’ rear stop lights for redtraffic signal bulbs.

On the other hand, the IMU-based detection windowscheme increases the number of false negatives when thetraffic signal is red. When a vehicle is decelerating abruptlyto stop at the red light, the IMU miscalculates the device’sorientation. As a result, the detection window is alsomiscalculated, becoming so small that the traffic signal isexcluded. Nevertheless, the effects of abrupt decelerationsare only transient and a car is soon able to detect the trafficsignal ahead.

Finally, since only a fraction of the video frame isprocessed, the IMU-based detection window scheme re-duces the average processing time by 41 percent (from 1.73to 1.02 s).

7.3 Transition Filtering

The performance of the transition filtering module isevaluated in terms of the number of false positives (invalidtransitions) it manages to remove and the number of falsenegatives it creates (valid transitions erroneously removed).

As shown in Fig. 10, the probability of (unfiltered) falsepositives in the Cambridge deployment is significantlysmaller when compared to the Singapore deployment. Thisoccurs for two reasons: First, the rate of false positive traffic

signal detections is smaller in Cambridge. Second, theaverage waiting time at red traffic signals is only 19.7 s forCambridge versus 47.6 s for Singapore. As a result, theprobability of a false positive transition detection duringthat waiting time is significantly lower.

While the LPF and colocation filters each significantlyreduce the number of false positives, it is when both filtersare applied in series that all false positives are removed inboth deployments, with only a small increase in the numberof false negatives. More specifically, the probability of falsenegatives increased by 6.8 percent for Cambridge and8.1 percent for Singapore. Thus, the transition filteringmodule effectively compensates for our lightweight butnoisy traffic signal detection module.

7.4 Schedule Prediction

7.4.1 Cambridge Deployment

We evaluate the overall accuracy of SignalGuru’s trafficsignal schedule predictions for Cambridge’s pretimedtraffic signals. As evaluation metric, we use the predictionmean absolute error; the absolute error between thepredicted and the actual traffic signal phase transition time,averaged across the 211 predictions performed by theparticipating iPhone devices.

As shown in Fig. 11, SignalGuru can predict the scheduleof pretimed traffic signals with an average error of only0.66 s. Since SignalGuru uses a database for the settings of


Fig. 9. IMU-based detection window scheme evaluation for Cambridgedeployment. The IMU-based detection window scheme almost halvesthe rate of misdetections.

Fig. 10. Transition filtering module evaluation. The transition filteringmodule removes false positive reports without significantly increasingthe number of false negatives. The iPhone devices witnessed 219 and37 traffic signal transitions in our Cambridge and Singapore deploy-ments, respectively.

Fig. 11. Mean absolute error of SignalGuru’s traffic signal schedulepredictions for the three targeted intersections in Cambridge. The errorbars show the standard deviation of the mean absolute error. Theground truth on the status of traffic signals was inferred by the imageslogged by the windshield-mounted iPhones with sub-300 ms accuracy.

pretimed traffic signals, the prediction error is solely causedby the error with which SignalGuru detects color (phase)transitions. When SignalGuru captures and processes videoframes every T ¼ 2 s, the transitions are theoreticallydetected with an error that has a maximum value of "max ¼T=2 ¼ 1 s and an expected value of ½"� ¼ T=4 ¼ 0:5 s. This isvery close to the measured prediction error value of 0.66 s.With this very small prediction error, SignalGuru caneffectively support the accuracy requirements of allapplications described in Section 3.

7.4.2 Singapore Deployment

We evaluate the accuracy of SignalGuru’s traffic signalschedule predictions for Singapore’s traffic-adaptive traffic

signals, using the prediction mean absolute error as the

evaluation metric. The prediction module was configured touse the prediction scheme PS3, and was trained offline

using a week’s worth of data (1-7 June 2010) that weobtained from Singapore’s Land Transport Authority.

As our results in Fig. 12 show, SignalGuru can predictthe time of the next color transition with an average error of2.45 s. The next color transition prediction error is brokendown into an average absolute error of 0.60 s in detectingthe current phase’s start time (detection module error) andan average absolute error of 1.85 s in predicting the lengthof the current phase (prediction module error). Theprediction error is due to both the inaccurate phaseduration measurements that are fed into the SVR modeland the prediction error of the SVR model, with the latterbeing the main contributor. The phase duration measure-ment error has a triangular probability density function8

and the expected value for the phase duration measurementabsolute error is only ["duration ¼ T=3 ¼ 0:66 s]. Results areaveraged over 26 predictions. The schedule predictionaccuracy for the two phases is comparable.

Without collaboration and high enough participation,

SignalGuru would not be able to measure the past length ofthe phases for the purpose of feeding them into the SVR-

based prediction scheme and predicting their futurelengths. SignalGuru would have to predict the future phase

length for a traffic-adaptive traffic signal using the samescheme that it uses for pretimed signals, i.e., by using a

typical fixed value for it. Such a value could be, forexample, the average length of the phase during the samehour of the previous day. In this case, the prediction errorfor our Singapore deployment would have been 11.03 sinstead of 2.45 s (3.5� higher). In the next section, weevaluate the performance of SignalGuru for differentdegrees of participation.

7.4.3 Singapore Large-Scale Prediction Analysis

In order to perform a large-scale evaluation of theperformance of SignalGuru’s prediction module acrossdifferent traffic signals and intersections with differenttraffic patterns, we collected traffic signal operation logsfrom Singapore’s Land Transport Authority. More specifi-cally, we collected logs for 32 traffic signals (phases) in theDover (suburban) area and for 20 traffic signals (phases) inthe Bugis (downtown) area. The logs spanned over the twoweeks of 1-14 June 2010 and contained more than 200,000phase lengths for both Bugis and Dover traffic signals. Weused the logs of the first week to train the different SVR-based prediction schemes, and the logs of the second weekto test their performance. The training and testing sets weretherefore not overlapping.

Prediction schemes evaluation. In Fig. 13, we evaluatethe performance of the different phase length predictionschemes for the traffic signals of Dover and Bugis. We alsoinclude the performance of a baseline scheme “PS0” thatuses the last measurement of a phase’s length as theprediction for its future length. PS3 outperforms PS1 andPS2 and reduces the phase length prediction meanabsolute error by 37 percent (from 3.06 s to 1.92 s) forBugis and by 26 percent (from 1.60 s to 1.19 s) for Doverwhen compared to PS0.

As shown in Fig. 13, the prediction mean absolute errorfor Dover traffic signals is half when compared to the errorfor Bugis traffic signals. However, note that the averagephase length for Bugis is 47 s whereas for Dover it is only28 s. As a result, the relative errors are more comparable:4.1 percent for Bugis and 4.3 percent for Dover.

Surprisingly, we found that the theoretical predictionscheme PS4, which assumes knowledge of loop detectorinformation, does not outperform PS3. We believe that thisis because the effects of loop detector measurements arealready captured by SCATS in the history of the phase andcycle length settings that it chooses. SignalGuru measuresthem and uses them as prediction features for PS3.


Fig. 12. Traffic signal schedule prediction evaluation for Singaporedeployment. The ground truth was recorded every 2 seconds and theactual (ground truth) transition time for a phase, e.g., A, was calculatedas t0A;R!G ¼ ðt0A;R þ t0A;GÞ=2. The measurement error was thus 1 s (shownwith error bars).

Fig. 13. Evaluation of the different prediction schemes for Bugis andDover traffic signals.

8. Assuming errors for the detection of phase start and stop times areindependent and uniformly distributed in [0, T/2].

Increasing available lead-up time. In order to increasethe available lead-up time beyond the length of a singlephase,9 SignalGuru needs to predict multiple phases ahead.For traffic-adaptive traffic signals, the prediction errorincreases as SignalGuru tries to predict multiple phaselengths ahead. For pre-timed traffic signals, for which thephase lengths are fixed and known, the prediction erroronly depends on the ability of SignalGuru to synchronizeaccurately with the traffic signal and thus lead-up time isarbitrarily long so long as it is within the same traffic mode.

Fig. 14 shows the error of the prediction module, when itpredicts the lengths of multiple phases ahead. The predictionerror increases sublinearly as the number of predictedphases increases. However, even when predicting fourphases ahead, the total prediction error for all phase lengthsis only 4.1 s (8.7 percent) and 2.4 s (5.2 percent) for Bugis andDover traffic signals, respectively. Given that wireless802.11g can broadcast a kilobyte of data over several hopsin <1 s, the average available lead-up times for Bugis andDover are 187 s and 114 s, respectively. The percentage ofavailable data (percent transitions detected) in our Singaporedeployment was 81 percent.

As this analysis shows, SignalGuru can predict accu-rately the schedule of traffic-adaptive traffic signals regard-less of their location, e.g., suburban or downtown.Furthermore, their schedule can be predicted multiplephases in advance with small errors, enabling all the novelapplications mentioned in Section 3 for traffic-adaptivetraffic signals.

Collaboration benefits. Fig. 15 shows how the accuracyof phase length predictions depends on the data avail-ability. Namely, accuracy depends on the percentage oftraffic signal transitions that are detected and madeavailable (through collaborative sensing and sharing).Where the phase length cannot be determined (because noSignalGuru node detected its start or end), we used thepreviously predicted phase length. The more the transitiondata available (higher degree of collaboration), the betterthe SignalGuru’s prediction accuracy. When data avail-ability drops below 25 percent for Bugis and 28 percent forDover, relative prediction errors degrade to >10 percent. Asa result, SignalGuru can no longer meet the requirements ofthe described applications. Collaboration is thus critical toensure high-quality predictions.

SVR retrain frequency. We evaluate how well the SVRmodel that was trained using the data of 1-7 June 2010 canpredict the schedule of the traffic signals after one week(8-14 June 2010), one month (1-7 July 2010), four months(1-7 October 2010) and eight months (1-7 February 2011).As shown in Fig. 16, the SVR model can make accuratepredictions even after eight months. More specifically, theerror for Dover traffic signals does not significantlyincrease over time. In contrast, for Bugis traffic signals,the prediction error increases by 33 percent (from 1.9 s to2.6 s) after eight months. LTA engineers manually performchanges to the traffic signal settings (e.g., phase programs)over time in an attempt to better optimize the traffic signalsoperation in the busy Singapore downtown area. As a result,SingalGuru’s prediction ability degrades over time forBugis, and the SVR model needs to get retrained everycouple months in order to keep prediction errors low.

7.5 SignalGuru Service Overhead

In this section, we present the computational (CPU, memory)and communication resources that SignalGuru consumes.We profiled SignalGuru across one hour using Xcode’s CPUSampler performance tool. During the profiling, the iPhone3GS device was facing the first intersection of Fig. 6 at adistance of �30 m from the traffic signal. SignalGuru wasconfigured to process a new frame every 2 seconds using theIMU-based detection window scheme. The GPS and IMUmodules were thus activated.

In Table 1, we show the computation time for the differentcomponents of SignalGuru. About 67 percent of the


Fig. 14. Evaluation of SignalGuru’s prediction scheme PS3 whenpredicting multiple phases ahead for Bugis and Dover traffic signals.

Fig. 15. Phase length prediction accuracy for Bugis and Dover trafficsignals as the percentage of the available traffic signal transitiondata varies.

Fig. 16. Prediction model performance over time. The predictionperformance of the SVR model that was trained with the data of 1-7June 2010 is evaluated for the weeks of 8-14 June 2010, 1-7 July 2010,1-7 October 2010, and 1-7 February 2011.

9. Predicting a single phase in advance suffices for all proposedapplications except TSAN.

application CPU time is spent for the traffic signal detection.This corresponds to 51 percent of system CPU time. Thelogging of images takes up 22 percent of the applicationCPU time.10 For pretimed traffic signals, the traffic signalschedule prediction takes less than 10 ms. For traffic-adaptive traffic signals, the prediction is based on the SVRmodels and takes 21 ms.

Although SignalGuru is using only 77 percent of thesystem CPU time in this configuration, we could notfurther increase the video frame capture and traffic signaldetection frequency. We found that when increasing thisfrequency by 20 percent, the GPS location updates wouldbecome very infrequent ð<0:1 HzÞ. This had detrimentaleffects as SignalGuru’s traffic signal detection was notactivated/deactivated promptly on approaching/leaving asignalized intersection.

The average memory footprint of SignalGuru was120.0 MB. However, only 20.1 MB, on average, were kept inactual RAM. The remaining 99.9 MB were assigned by theiOS to virtual memory. The iPhone 3GS devices have 256 MBof eDRAM. SignalGuru thus takes up only �8 percent of thedevice’s actual RAM resources.

The communication resources required, per smartphone,to collaboratively support SignalGuru are limited. Less than1 KB/s and 22 KB/s are exchanged for pretimed and traffic-adaptive traffic signals, respectively. The difference lies inthe sizeable SVR models that are exchanged in the case oftraffic-adaptive traffic signals.

7.6 GLOSA Fuel Efficiency

For evaluating GLOSA, we used a 2.4L Chrysler PT Cruiser2001 city vehicle. We measured its fuel efficiency byconnecting to its Controller Area Network (CAN) with aScan Tool OBD-LINK device (Fig. 3). The fuel efficiency wascalculated based on the Intake Manifold Absolute Pressure(IMAP) approach with the help of the OBDwiz software.The trip starts at P1 and ends at P2 on Fig. 6, including thethree intersections in our Cambridge deployment.

The driver completed 20 trips, following GLOSA’saccurate advisory (<1 s mean absolute prediction error11)at odd-numbered trips, and driving normally (without

GLOSA’s advisory) at even numbered trips. When follow-ing GLOSA’s advisory, the driver was able to avoid moststops (the driver sometimes had to brake because ofpedestrians or cars in front). When not, the driver had tostop from zero to three times during each of the trips. Asshown in Fig. 17, GLOSA can offer significant savingsreducing fuel consumption, on average, by 20.3 percent(from 71.1 to 56.6 ml). In other words, GLOSA improves thevehicle’s mileage, on average, by 24.5 percent (from 16.1 to20.1 mpg).

8 COMPLEX INTERSECTIONS

In this section, we discuss practical issues regarding theoperation of SignalGuru in complex intersections, as well ashow SignalGuru can overcome them. In a complex intersec-tion with many traffic signals, SignalGuru must be able todetect the correct traffic signal and also identify to whichvehicular movement the detected traffic signal corresponds.

8.1 Traffic Signal Detection

In a complex intersection with many traffic signals,SignalGuru will normally still detect the correct trafficsignal, i.e., the one that corresponds to the road segmentthat the vehicle is currently on. Normally, a vehicle that isapproaching an intersection on a given road segment willbe able to view only the corresponding traffic signal at azero-degree angle. The traffic signals of the other roadsegments may be still within the camera’s field of view, butwill be seen at some angle. At angles >90 degree the trafficsignal bulbs will not be visible. At smaller angles, the bulbswill be visible but will recorded on the video frame as ovalsinstead of circles. Furthermore, these ovals will be partiallyoccluded by the traffic signal housing visors. WhileSignalGuru can still detect partially deformed and occludedtraffic signals, its Hough transform voting algorithm willfavor the most round and least occluded traffic signal, i.e.,


TABLE 1Computation Resources Requiredby SignalGuru’s Different Modules

The computation resources for the traffic signal detection module isfurther broken down in Table 2.

10. Image logging was necessary in our experiments so that we can testwhether the traffic signal detection was successful or not. In a real system,image logging would be disabled.

11. For small distances from traffic signals, we found that it is morebeneficial to provide the driver with the transition time instead of therecommended speed. First, for small distances ð<50 mÞ, the GPS error issignificant and second, the driver can better account for vehicles stopped atthe intersection and time their acceleration appropriately.

TABLE 2Computation Resources for the Different Steps of

SignalGuru’s Traffic Signal Detection Algorithm

Fig. 17. GLOSA fuel efficiency evaluation.

the one that corresponds to the road segment that thevehicle is currently on.

Moreover, information about the exact location of trafficsignals at an intersection can be leveraged to further narrowdown the size of the IMU-based detection window. In thisway, both the accuracy and the speed of the traffic signaldetection will get improved. The locations of the trafficsignals can be detected and recorded by the SignalGurudevices themselves.

8.2 Traffic Signal Identification

In a complex intersection with more than one traffic signal,SignalGuru needs to identify which specific traffic signal itis detecting, i.e., to which direction of movement thedetected traffic signal corresponds. While GPS localizationcan be used to identify the intersection, it is often notaccurate enough to distinguish between the different roadsegments of an intersection. The identification of the trafficsignal being detected is necessary in order to appropriatelymerge the data detected across different vehicles.

The traffic signal is identified based on the GPS heading(direction of movement) of the vehicle that is detecting it, aswell as the shape of the traffic signal (round, right/left turnarrow, etc.). The heading of the vehicle is used to identifythe road segment on which the vehicle is located bymatching its reported GPS heading (d � þ � �, where �degree is the measurement error) to road segment that hasthe closest orientation (d degree). The number and orienta-tion of the intersecting road segments at any givenintersection can either be acquired by mapping information[23] or learned by clustering movement traces of Signal-Guru-enabled vehicles. Then, for example, a vehicle can tellthat the signal it is detecting is for vehicles that want to turnleft and are approaching the intersection on the roadsegment that is attached to the intersection at d degreecompared to geographic north.

9 COLLABORATIVE SERVICES

Besides SignalGuru, windshield-mounted smartphones cansupport a rich set of novel collaborative services with theircameras. We briefly describe here four additional services:

9.1 Parking Space Availability Service

Windshield-mounted smartphone cameras can processcaptured images to discover available parking spots andsubsequently disseminate information about their locationto drivers that are looking for a free spot. Free parking spotscan be discovered by detecting features like the wheels ofparked cars and the lines that segment parking spots.

9.2 Bus Localization and Arrival Time Service

Windshield-mounted smartphones could be used to sup-port a grassroots bus localization and arrival time service.Windshield-mounted smartphone cameras can detect andidentify buses by detecting their license plates and IDs. BusIDs are often displayed with bright LED signs, making theirdetection and identification task significantly easier. Onencountering and identifying a bus, smartphones canestimate and disseminate the bus arrival time based onthe their location and the prevailing traffic conditions [29].

9.3 Taxi Discovery Service

In some cities (e.g., Singapore), taxis have LED signs ontheir roof that show whether the taxi is free (“TAXI” shownin green) or busy (“BUSY” shown in red). Windshield-mounted smartphones could detect the color-coded textdisplays to discover free taxis and inform prospectivepassengers about where they can find one.

9.4 Cheap Gas Advisory Service

Windshield-mounted smartphone cameras could detect thelarge signs that typically gas stations have and read off thegas prices. The gas prices would then be disseminated andshared with other vehicles to collaboratively support aservice that helps drivers find the cheapest gas around them.

While detecting available parking spots or reading offgas prices may be harder computationally than detecting atraffic signal, the time constraints are not as tight. Trafficsignal detection needs to be fast so that new frames can beprocessed as frequently as possible and the traffic signaltransition times are detected as accurately as possible.Particularly, for the cheap gas advisory service, the timeconstraints are very loose. A windshield-mounted smart-phone could capture an image and take several seconds oreven minutes to process it and detect the prices. To improvethe detection accuracy, still images could be capturedinstead of the video frames that we used to increasedetection speed for SignalGuru.

10 RELATED WORK

Several collaborative systems have been proposed thatcrowdsource information from GPS, accelerometer andproximity sensors in order to estimate traffic conditions[11], [21], [29], detect road abnormalities [7], collectinformation for available parking spots [20] and computefuel efficient routes [8]. In [18], Lee et al. propose anapplication that lets police track the movement of suspi-cious vehicles based on information sensed by camera-equipped vehicles. Other works have also proposed toequip vehicles with specialized cameras and detect trafficsignals with the ultimate goal of enabling autonomousdriving [9], assisting the driver [22], or detecting thelocation of intersections and overlaying navigation informa-tion [28]. In [5], [31], the authors enforce traffic laws (e.g.,detection of red light runners) by detecting traffic signalsand their current status with stationary cameras affixed toinfrastructure. Furthermore, as we discussed in the intro-duction, approaches aiming to enable GLOSA have beenbased on costly infrastructure and hence failed to grow inscale. To the best of our knowledge, no other work hasproposed to leverage commodity windshield-mount smart-phone cameras, or above all, to predict the future schedule oftraffic signals for the purpose of providing it to users andenabling the proposed set of novel applications.

Our camera-based traffic signal detection algorithm isdrawn from several schemes mentioned above [9], [22], [28].However, in contrast to these approaches that detect asingle target, SignalGuru uses an iterative threshold-basedapproach for identifying valid traffic signal candidates. Wealso propose the IMU-based detection window scheme thatleverages information from smartphones’ accelerometer


and gyro devices to narrow down the detection areaoffering significant performance improvements. In orderto be able to detect ill-captured traffic signals under poorambient light conditions, previous approaches either usenormalized RGB images [22] or estimate ambient illumina-tion [5]. In contrast to these approaches, we leverage theobservation that LED traffic signals are a light source of afixed luminous intensity, and provide mechanisms toperform a one-time automatic adjustment of the smart-phone camera’s exposure setting. In this way, the camerahardware is configured to capture traffic signal bulbscorrectly regardless of the prevailing ambient light condi-tions, obviating the need for additional image processingsteps. Last and most important, all these prior works focussolely on reporting the current status of traffic signals. Theyare not concerned with phase transitions and thus do notpropose schemes to filter them, or collate the past trafficsignal schedule for prediction of the future.

Services like SignalGuru that are based on collaborativesensing naturally have trust, privacy, security implications.SignalGuru can use DLT certificates [19] or a TPM [26] inorder to improve trust in the exchange of traffic signal data.Furthermore, the SignalGuru-enabled devices and theirusers can be safeguarded by spatiotemporal cloaking [10]and other proposed approaches for grassroots participatorysensing [12].

11 CONCLUSIONS

In this paper, we presented a collaborative sensing platformthat is based on the cameras of windshield-mountedsmartphones. We discussed several novel services that thisplatform enables and focused on SignalGuru. SignalGuru isa novel service that leverages collaborative sensing onwindshield-mount smartphones, in order to predict trafficsignals’ future schedule and support a set of novelapplications in a fully distributed and grassroots approach.Our proposed schemes improve traffic signal detection,filter noisy traffic signal data, and predict traffic signalschedule. Our results, from two real-world deployments inCambridge (MA, USA) and Singapore, show that Signal-Guru can effectively predict the schedule for not onlypretimed but also state-of-the-art traffic-adaptive trafficsignals. Furthermore, fuel efficiency measurements, on anactual city vehicle, highlight the significant fuel savings(20.3 percent) that our SignalGuru-based GLOSA applica-tion can offer. We hope that this work will motivate furtherresearch in our proposed collaborative sensing platformand the services that it can enable.

ACKNOWLEDGMENTS

The authors acknowledge the support of US NationalScience Foundation (NSF) grant CSR-EHS-0615175 and theSingapore-MIT Alliance for Research and TechnologyFuture Urban Mobility center. They would like to thankChia-Hsin Owen Chen for his help in analyzing the trafficsignal color distributions and Jason Gao for his help inadjusting the camera exposure time. They would also liketo thank the volunteers at their two deployments (Prof.

Ananda and Prof. Chan’s groups at NUS and our groupat MIT). Special thanks also to Singapore’s Land Trans-port Authority ITS Centre and Cambridge’s trafficengineer Jeff Parenti for their help in obtaining the trafficsignal data and settings. Last but not least, their sincerethanks to the anonymous reviewers, their editor MarcoGruteser, and their MobiSys shepherd Nigel Davies fortheir insightful comments.

REFERENCES

[1] B. Asadi and A. Vahidi, “Predictive Cruise Control: UtilizingUpcoming Traffic Signal Information for Improving Fuel Econo-my and Reducing Trip Time,” IEEE Trans. Control SystemsTechnology, vol. 19, no. 3, pp. 707-714, May 2011.

[2] Audi Travolution Project, http://www.audi.com/com/brand/en/tools/news/pool/2010/06/audi_travoluti on_.html, 2012.

[3] R. Baldessari et al., “Car 2 Car Communication ConsortiumManifesto,” Proc. IEEE Vehicular Technology Conf., 2007.

[4] C.-C. Chang and C.-J. Lin, “LIBSVM: A Library for Support VectorMachines,” Science, vol. 2, pp. 1-39, http://www.csie.ntu.edu.tw/cjlin/libsvm, 2001.

[5] Y.C. Chung, J.M. Wang, and S.W. Chen, “Vision-Based TrafficLight Detection System at Intersections,” J. Taiwan Normal Univ.:Math., Science and Technology, vol. 47, pp. 67-86, 2002.

[6] G. Comert and M. Cetin, “Queue Length Estimation from ProbeVehicle Location and the Impacts of Sample Size,” EuropeanJ. Operational Research, vol. 197, pp. 196-202, 2009.

[7] J. Eriksson, L. Girod, B. Hull, R. Newton, S. Madden, and H.Balakrishnan, “The Pothole Patrol: Using a Mobile SensorNetwork for Road Surface Monitoring,” Proc. Sixth Int’l Conf.Mobile Systems, Applications, and Services (MobiSys), 2008.

[8] R.K. Ganti, N. Pham, H. Ahmadi, S. Nangia, and T.F. Abdelzaher,“GreenGPS: A Participatory Sensing Fuel-Efficient Maps Applica-tion,” Proc. Int’l Conf. Mobile Systems, Applications, and Services(MobiSys), 2010.

[9] J. Gong, Y. Jiang, G. Xiong, C. Guan, G. Tao, and H. Chen, “TheRecognition and Tracking of Traffic Lights Based on ColorSegmentation and Camshift for Intelligent Vehicles,” Proc. IEEEIntelligent Vehicles Symp. (IV), 2010.

[10] M. Gruteser and D. Grunwald, “Anonymous Usage of Location-Based Services through Spatial and Temporal Cloaking,” Proc.Int’l Conf. Mobile Systems, Applications, and Services (MobiSys), 2003.

[11] B. Hoh, M. Gruteser, R. Herring, J. Ban, D. Work, J.-C. Herrera,A.M. Bayen, M. Annavaram, and Q. Jacobson, “Virtual Trip Linesfor Distributed Privacy-Preserving Traffic Monitoring,” Proc. Int’lConf. Mobile Systems, Applications, and Services (MobiSys), 2008.

[12] B. Hoh, M. Gruteser, H. Xiong, and A. Alrabady, “EnhancingSecurity and Privacy in Traffic-Monitoring Systems,” IEEEPervasive Computing, vol. 5, no. 4, pp. 38-46, Oct.-Dec. 2006.

[13] G.S. Kasbekar, Y. Bejerano, and S. Sarkar, “Lifetime and CoverageGuarantees through Distributed Coordinate-Free Sensor Activa-tion,” Proc. MobiCom, 2009.

[14] P. Koonce, L. Rodegerdts, L. Kevin, S. Quayle, S. Beaird, C. Braud,J. Bonneson, P. Tarnoff, and T. Urbanik, Traffic Signal TimingManual. US Dept. of Transportation, 2008.

[15] E. Koukoumidis, D. Lymberopoulos, K. Strauss, J. Liu, and D.Burger, “Pocket Cloudlets,” Proc. Int’l Conf. Architectural Supportfor Programming Languages and Operating Systems (ASPLOS), 2011.

[16] E. Koukoumidis, L.-S. Peh, and M. Martonosi, “RegReS: Adap-tively Maintaining a Target Density of Regional Services inOpportunistic Vehicular Networks,” Proc. IEEE Int’l Conf. Perva-sive Computing and Comm. (PerCom), 2011.

[17] E. Koukoumidis, L.-S. Peh, and M. Martonosi, “SignalGuru:Leveraging Mobile Phones for Collaborative Traffic SignalSchedule Advisory,” Proc. Int’l Conf. Mobile Systems, Applications,and Services (MobiSys), 2011.

[18] U. Lee, E. Magistretti, M. Gerla, P. Bellavista, and A. Corradi,“Dissemination and Harvesting of Urban Data Using VehicularSensor Platforms,” IEEE Trans. Vehicular Technology, vol. 58, no. 2,pp. 882-901, Feb. 2009.

[19] V. Lenders, E. Koukoumidis, P. Zhang, and M. Martonosi,“Location-Based Trust for Mobile User-Generated Content:Applications Challenges and Implementations,” Proc. WorkshopMobile Computing Systems and Applications (HotMobile), 2008.


[20] S. Mathur, T. Jin, N. Kasturirangan, J. Chandrasekaran, W. Xue,M. Gruteser, and W. Trappe, “Parknet: Drive-by Sensing of Road-Side Parking Statistics,” Proc. Int’l Conf. Mobile Systems, Applica-tions, and Services (MobiSys), 2010.

[21] P. Mohan, V.N. Padmanabhan, and R. Ramjee, “Nericell: UsingMobile Smartphones for Rich Monitoring of Road and TrafficConditions,” Proc. ACM Conf. Embedded Network Sensor Systems(SenSys), 2008.

[22] M. Omachi and S. Omachi, “Traffic Light Detection with Colorand Edge Information,” Proc. IEEE Int’l Conf. Computer Science andInformation Technology (ICCSIT), 2009.

[23] Openstreetmap, http://www.openstreetmap.org/, 2012.[24] S. Reddy, D. Estrin, and M. Srivastava, “Recruitment Framework

for Participatory Sensing Data Collections,” Proc. Eighth Int’l Conf.Pervasive Computing, 2010.

[25] RITA ITS Deployment Statistics Database, http://www.itsdeployment.its.dot.gov/Results.asp?rpt=M&filter=1&ID=320,2012.

[26] S. Saroiu and A. Wolman, “I am a Sensor and I Approve ThisMessage,” Proc. Workshop Mobile Computing Systems and Applica-tions (HotMobile), 2010.

[27] SCATS, http://www.scats.com.au/, 2012.[28] H. Tae-Hyun, J. In-Hak, and C. Seong-Ik, “Detection of Traffic

Lights for Vision-Based Car Navigation System,” Proc. Advances inImage and Video Technology: First Pacific Rim Symp., 2006.

[29] A. Thiagarajan, L. Ravindranath, K. LaCurts, S. Madden, H.Balakrishnan, S. Toledo, and J. Eriksson, “VTrack: AccurateEnergy-Aware Road Traffic Delay Estimation Using MobilePhones,” Proc. Int’l Conf. Embedded Networked Sensor Systems(SenSys), 2009.

[30] J. van Leersum, “Implementation of an Advisory Speed Algorithmin TRANSYT,” Transportation Research Part A: General, vol. 19,pp. 207-217, 1985.

[31] Y. Wang, Y. Zou, H. Shi, and H. Zhao, “Video Image VehicleDetection System for Signaled Traffic Intersection,” Proc. Int’lConf. Hybrid Intelligent Systems (HIS), 2009.

[32] P. Zhang and M. Martonosi, “CA-TSL: Energy Adaptation forTargeted System Lifetime in Sparse Mobile Ad-Hoc Networks,”IEEE Trans. Mobile Computing, vol. 9, no. 12, pp. 1794-1808, Dec.2010.

Emmanouil Koukoumidis received the Diplo-ma degree in electrical and computer engineer-ing from the National Technical University ofAthens and the master’s degree in electricalengineering from Princeton University, where heis currently working toward the PhD degree. Inthe last two years, he has been a researchscholar in MIT’s Computer Science and ArtificialIntelligence Laboratory and Singapore’s SMARTCentre focusing on Intelligent Transportation

Systems applications. His research interests include mobile computing,distributed systems and networking in general. He is a student memberof the IEEE and the ACM.

Margaret Martonosi received the bachelor’sdegree from Cornell University and the master’sand PhD degrees from Stanford University, all inelectrical engineering. She is currently a profes-sor of computer science at Princeton University,where she has been on the faculty since 1994.She also holds an affiliated faculty appointmentin the Electrical Engineering Department atPrinceton University. Her research interestsinclude computer architecture and the hard-

ware/software interface, with particular focus on power-efficient systemsand mobile computing. She is a fellow of the IEEE and the ACM.

Li-Shiuan Peh received the BS degree incomputer science from the National Universityof Singapore in 1995 and the PhD degree incomputer science from Stanford University in2001. She is an associate professor of electricalengineering and computer science at MIT since2009. Previously, she was on the faculty ofPrinceton University from 2002. Her researchfocuses on low-power on-chip networks, parallelcomputer architectures and mobile computing.

She was awarded the CRA Anita Borg Early Career Award in 2007,Sloan Research Fellowship in 2006, and the US National ScienceFoundation (NSF) CAREER award in 2003. She is a member of theIEEE and the ACM.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


Leveraging smartphone cameras

Education

Transcript of Leveraging smartphone cameras