Vehicle’Tracking’with’the’’ Viterbi’Algorithm · Vehicle’Tracking’with’the’’...
69
Vehicle Tracking with the Viterbi Algorithm Kyle Jamieson UCL Computer Science COMPM038/COMPGZ06 2 nd March 2012
Transcript of Vehicle’Tracking’with’the’’ Viterbi’Algorithm · Vehicle’Tracking’with’the’’...
Vehicle Tracking with the Viterbi Algorithm
Kyle Jamieson UCL Computer Science
COMPM038/COMPGZ06 2nd March 2012
Today
1. The Viterbi Algorithm – Hidden Markov model – ConvoluGonal codes – The Viterbi decoder
2. VTrack (Thiagarajan et al.)
2
Applica9ons of the Viterbi algorithm
• CommunicaGons systems – Convolu9onal codes – 802.11a/b/g, Zigbee, CDMA, GSM (TDMA) – DSL, telephone modem, satellite
• OpGcal character recogniGon • Speech recogniGon • MagneGc storage (tape, disk) • ComputaGonal biology (locaGng genes in DNA sequences)
• Today’s paper, VTrack • Many others!
3
Communica9ons system model
signal r(t)
Modulate
signal s(t)
Encode
source bits u channel bits y
Demodulate Decode channel bit
observa1ons z
decoded source bits û
r(t) = hs(t) + n(t)
Model: discrete 9me Markov process
State at Gme k xk is one of a finite number M of states 1, 2, …, M
Markov condi9on: P(xk+1|x0, x1, …, xk) = P(xk+1|xk)
x1 x2
x5
x4 x3
Example, M=5:
5
Model: hidden state Markov We make K indirect observaGons z = {z1, …, zk} of the Markov process
x1 x2
x5
x4 x3
Example, K=4:
z1 z2 z3 z4
6
What the Viterbi algorithm does EsGmate x = {x1, …, xk} just from observing z = {z1, …, zk}
x1 x2
x5
x4 x3
Example, K=4:
z1 z2 z3 z4
Maximum a posteriori probability (MAP): x such that P(x|z) is maximized
7
Today
1. The Viterbi Algorithm – Hidden Markov model – Convolu9onal codes – The Viterbi decoder
2. VTrack (Thiagarajan et al.)
8
Convolu9onal encoder Source bits u = {u1, …, uK}
Channel bits y = {y11, y12, y21, …, yK2}
uk D D
✚
✚
delay
y1k = uk +uk−2
y2k = uk+uk−1+uk−2
uk−1 uk−2
State: xk = (uk−1, uk−2) Code rate: ½, binary code (bits in and out) Constraint length: two
ConvoluGonal encoder
9
802.11: adapt code rate, modula9on
10
Bit- 802.11 DSSS Modulation Bits Coding Mega-rate Stan- or per Rate Symbols
dards OFDM Symbol persecond
1 b DSSS BPSK 1 1/11 112 b DSSS QPSK 2 1/11 11
5.5 b DSSS CCK 1 4/8 1111 b DSSS CCK 2 4/8 116 a/g OFDM BPSK 1 1/2 129 a/g OFDM BPSK 1 3/4 12
12 a/g OFDM QPSK 2 1/2 1218 a/g OFDM QPSK 2 3/4 1224 a/g OFDM QAM-16 4 1/2 1236 a/g OFDM QAM-16 4 3/4 1248 a/g OFDM QAM-64 6 2/3 1254 a/g OFDM QAM-64 6 3/4 12
Figure 2-1: A summary of the 802.11 bit-rates. Each bit-rate uses a specific combinationof modulation and channel coding. OFDM bit-rates send 48 symbols in parallel.
a channel. In the presence of fading, multi-path interference, or other interference that is
not additive white Gaussian noise, predicting the combinations of modulation and channel
coding that will be most e!ective at masking bit errors is di"cult.
All 802.11 packets contain a small preamble before the data payload which is sent at
a low bit-rate. The preamble contains the length of the packet, the bit-rate for the data
payload, and some parity information calculated over the contents of the preamble. The
preamble is sent at 1 megabit in 802.11b and 6 megabits in 802.11g and 802.11a. This results
in the unicast packet overhead being di!erent for 802.11b and 802.11g bit-rates; a perfect
link can send approximately 710 1500-byte unicast packets per second at 12 megabits (an
802.11g bit-rate) and 535 packets per second at 1 megabit (an 802.11b bit-rate). This means
that 12 megabits can sustain nearly 20% loss before a lossless 11 megabits provides better
throughput, even though the bit-rate is less than 10% di!erent.
2.2 Medium-Access Control (MAC) Layer
For the purposes of this thesis, the most important properties of the 802.11 MAC layer are
the medium access mechanisms and the unicast retry policy.
To prevent nodes from sending at the same time, 802.11 uses carrier sense multiple access
14
From encoder to Markov model
(0,0)
(1,0)
(1,1)
(0,1)
00
111100
0110
01
10
Conven9on 0 input 1 input
uk uk−1 uk−2
y1k
y2k
y1k = uk +uk−2 y2k = uk+uk−1+uk−2
state xk = (uk−1, uk−2)
11
Matching reality with the model
signal r(t)
Modulate
signal s(t)
Encode
channel bits y
Demodulate Decode
channel bit observaGons z
decoded source bits û
Source bits u = {u1, …, uK}
Viterbi: esGmate x = {x1, …, xk} just from observing z = {z1, …, zk}
(0,0)
(1,0)
(1,1)
(0,1)
00
111100
0110
01
10
12
Today
1. The Viterbi Algorithm – Hidden Markov model – ConvoluGonal codes – The Viterbi decoder
2. VTrack (Thiagarajan et al.)
13
The Trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
01
11
00
01
10
11
0000
11
00
01
11
10
1011
10
1100
01
1001
state (uk−1, uk−2)
(0,0)
(1,0)
(1,1)
(0,1)
00
111100
0110
01
10Conven9on 0 input 1 input
Example: input u = 10100, output y = 11 01 00 01 11
14
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
2
110
receive: 11
2
0
• Branch metric is Hamming distance between received and sent • Path metric sums branch metrics
15
Path metric
Branch
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0112
00
2
011
101
110
receive: 11 00
2
1
4
1
16
• Path metric sums branch metrics • What if we stopped decoding here? input u = 10100
Survivor path
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0112
00
2
011
101
110
00
0
112
receive: 11 00 00
2 or 3
17
• Paths merge: only keep one • Prune just the incident branch for now input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0112
00
2
011
101
110
00
0
receive: 11 00 00
2
18
• Other survivor paths may go through remainder of losing path input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0112
00
2
011
101
110
00
0
receive: 11 00 00
5 or 2
2
10
1
011
19
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0112
00
2
011
101
110
00
0
receive: 11 00 00
2
2
10
1
20
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0112
00
2
011
101
110
00
0
receive: 11 00 00
2
2
10
1
000
112
4 or 1
21
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0112
00
2
011
101
110
00
0
receive: 11 00 00
2
2
10
1
000
1
22
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0112
00
2
011
101
110
00
0
receive: 11 00 00
2
2
10
1
000
110101
15 or 2
23
• Prune incident branch (Viterbi dynamic programming step) input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0112
00
2
011
101
110
00
0
receive: 11 00 00
2
2
10
1
000
1
01
12
24
• Correct path is one of four survivors • Some older branches are not part of any survivor • What if we stopped decoding here?
Viterbi decoding: receiver-‐side trellis
25
(0,0)
(0,1)
(1,1)
(1,0)
00
0
00
2
011
101
110
00
0
receive: 11 00 00
2
2
10
1
000
1
01
12
• Prune older branches not part of any survivor input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0
00
2
011
101
110
00
0
receive: 11 00 00
3
10
1
000
01
1
01
111
26
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0
00
2
011
101
110
00
0
receive: 11 00 00
1
3
10
1
000
01
1
01
111
010
27
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0
00
2
011
101
110
00
0
receive: 11 00 00
1
3
10
1
000
01
1
01
111
010
111
3
28
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0
00
2
011
101
110
00
0
receive: 11 00 00
1
3
10
1
000
01
111
010
111
3
3
101
29
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0
00
2
011
101
110
00
0
receive: 11 00 00
5/2
10
1
000
01
111
010
111
101
1100
2
011
30
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0
00
2
011
101
110
00
0
receive: 11 00 00
2
10
1
000
01
111
010
111
101
11
011
10
1
3
31
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0
00
2
011
101
110
00
0
receive: 11 00 00
2
10
1
000
01
111
010
111
101
11
011
10
1
3002
3
32
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
00
0
00
2
011
101
110
00
0
receive: 11 00 00
2
10
1
000
01
111
010
111
101
11
011
10
1
3002
3
01
13
33
• Complete path from beginning is a non-‐survivor input u = 10100
(0,0)
(0,1)
(1,1)
(1,0)
011
110
receive: 11 00 00
2
000
01
010101
11
011
10
1
3002
3
01
13
decode: 1 0 1
Viterbi decoding: receiver-‐side trellis
34
Conven9on 0 input 1 input
input u = 10100
Viterbi decoding: receiver-‐side trellis
35
(0,0)
(0,1)
(1,1)
(1,0)
011
110
receive: 11 00 00
2
000
01
010101
11
011
10
1
3002
3
01
13
decode: 1 0 1Conven9on 0 input 1 input
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
receive: 11 00 00
2
01
010101
11
011
10
1
3002
3
01
13
decode: 1 0 1
36
Conven9on 0 input 1 input
Discard state once decoded
input u = 10100
Viterbi decoding: receiver-‐side trellis
(0,0)
(0,1)
(1,1)
(1,0)
receive: 11 00 00
2
01
010101
11
011
10
1
3002
3
01
13
decode: 1 0 1
37
Can make remaining decisions corresponding to min-‐metric survivor
0 0 input u = 10100
Today
1. The Viterbi Algorithm – Hidden Markov model – ConvoluGonal codes – The Viterbi decoder
2. VTrack (Thiagarajan et al.)
39
Coping with traffic conges9on
• Traffic congesGon is a serious problem: Genng worse, and projected to conGnue to do so
• Possible help from real-‐Gme traffic informaGon: 1. Tell drivers about hotspots on the road 2. Help them plan a route to their desGnaGon
• To do this, we need to be able to esGmate travel Gmes on segments of a road network
• Idea: Use vehicles as probes to collect travel Gme data – Vehicles can cover large areas more efficiently than sensors embedded in the road surface
– Users’ mobile smartphones have GPS, WiFi
40
VTrack: Traffic Delays From Phones
VTrack Server Raw Loca9ons (e.g., lat-‐long, AP idenGfier)
Trajectories + Travel Times
“Map Matching” (every 15 min)
Data CollecGon
Real-‐Gme traffic updates (every 15 min)
Website with Apps (e.g., Route Planning)
Other Phones (Data Consumers)
VTrack server Figure 1: Architecture
Figure 2: VTrack Server
2 Overview and ChallengesFigure 1 shows the architecture of VTrack. Users with mo-
bile smartphones run an application that reports position datato the server periodically while driving. VTrack currently usesGPS and WiFi position sensors. The server runs a travel-timeestimation algorithm that uses these noisy position samplesto identify the road segments on which a user is driving andestimate the travel time on these segments. The estimatesare then used to identify hotspots and provide real-time routeplanning updates.
Figure 2 shows the VTrack server in detail. In cases whereGPS is not present, not working, or too power-hungry, VTrackuses WiFi for position estimation; access point observationsfrom WiFi in smartphones are converted into position esti-mates using a localization algorithm, which uses a “wardriv-
ing” database of GPS coordinates indicating where WiFi APshave been observed from in previous drives. Positions fromthese sensors are fed in real-time to our estimation algorithm,which consists of two components: a map-matcher, whichdetermines which roads are being driven on, and a travel-time
estimator, which determines travel times for road segmentsfrom the map-matched trajectory.2.1 Applications
We want to support two key applications using real-timetravel times:
Detecting and visualizing hotspots: We define a “hotspot”to be a road segment on which the observed travel time ex-ceeds the time that would be predicted by the speed limit bysome threshold. Hotspots are not outliers in traffic data; theyoccur every day during rush hour, for example, when driversare stuck in traffic. Our goal is to detect and display all thehotspots within a given geographic area which the user is view-ing on a browser. This application can be used directly byusers, who can see hotspots on their route and alter it to avoidthem, or can be used by route avoidance algorithms, to avoidsegments that are frequently congested at a particular time.
For hotspot detection, we want travel time estimates tobe accurate enough to keep two metrics low: the miss rate,defined to be the fraction of hotspot segments that we fail toreport, and the false positive rate, the fraction of segments wereport as hotspots that actually aren’t.
Real-time route planning: With the exception of hotspots,users are generally more concerned about their total travel time,rather than the time they spend on a particular road. Routeplanning that minimizes the expected time is one way for usersto find a good route to a particular destination. Real-time routeplanning is especially useful because it allows users to bere-routed mid-drive.
Our goal is to provide users with routes that minimize traveltimes. Ultimately, the routing scheme will have to take traveltime prediction into account. In this paper we only focuson estimation, a necessary step for any prediction scheme.To analyze our travel time estimates in the context of routeplanning, we study how much worse the shortest paths we findare compared to the true shortest paths (shortest in terms oftravel time).
Our goal is to run these applications both on websites andon users’ phones. We envision a user with an app running onhis or her phone showing position, nearby traffic, and offer-ing a navigation service, while continuously sending positionestimates back to our servers. We have built a prototype ofsuch an application for the iPhone. We also have a websitewhere users can view current traffic delays and receive routeplanning updates. Figure 3 shows a screenshot of our website(the iPhone app is very similar).
Figure 3: Web application showing traffic delays.
2.2 Requirements and ChallengesIn the context of the above applications, our goal is to
devise map-matching and time-estimation algorithms that are:1. Accurate, such that time estimates are close enough to re-
ality to be usable for route planning and hotspot detection.For route planning, we believe that errors in the 10-15%
42
Real Time Delay Map (Zoomed in)
Figure 1: Architecture
Figure 2: VTrack Server
2 Overview and ChallengesFigure 1 shows the architecture of VTrack. Users with mo-
bile smartphones run an application that reports position datato the server periodically while driving. VTrack currently usesGPS and WiFi position sensors. The server runs a travel-timeestimation algorithm that uses these noisy position samplesto identify the road segments on which a user is driving andestimate the travel time on these segments. The estimatesare then used to identify hotspots and provide real-time routeplanning updates.
Figure 2 shows the VTrack server in detail. In cases whereGPS is not present, not working, or too power-hungry, VTrackuses WiFi for position estimation; access point observationsfrom WiFi in smartphones are converted into position esti-mates using a localization algorithm, which uses a “wardriv-
ing” database of GPS coordinates indicating where WiFi APshave been observed from in previous drives. Positions fromthese sensors are fed in real-time to our estimation algorithm,which consists of two components: a map-matcher, whichdetermines which roads are being driven on, and a travel-time
estimator, which determines travel times for road segmentsfrom the map-matched trajectory.2.1 Applications
We want to support two key applications using real-timetravel times:
Detecting and visualizing hotspots: We define a “hotspot”to be a road segment on which the observed travel time ex-ceeds the time that would be predicted by the speed limit bysome threshold. Hotspots are not outliers in traffic data; theyoccur every day during rush hour, for example, when driversare stuck in traffic. Our goal is to detect and display all thehotspots within a given geographic area which the user is view-ing on a browser. This application can be used directly byusers, who can see hotspots on their route and alter it to avoidthem, or can be used by route avoidance algorithms, to avoidsegments that are frequently congested at a particular time.
For hotspot detection, we want travel time estimates tobe accurate enough to keep two metrics low: the miss rate,defined to be the fraction of hotspot segments that we fail toreport, and the false positive rate, the fraction of segments wereport as hotspots that actually aren’t.
Real-time route planning: With the exception of hotspots,users are generally more concerned about their total travel time,rather than the time they spend on a particular road. Routeplanning that minimizes the expected time is one way for usersto find a good route to a particular destination. Real-time routeplanning is especially useful because it allows users to bere-routed mid-drive.
Our goal is to provide users with routes that minimize traveltimes. Ultimately, the routing scheme will have to take traveltime prediction into account. In this paper we only focuson estimation, a necessary step for any prediction scheme.To analyze our travel time estimates in the context of routeplanning, we study how much worse the shortest paths we findare compared to the true shortest paths (shortest in terms oftravel time).
Our goal is to run these applications both on websites andon users’ phones. We envision a user with an app running onhis or her phone showing position, nearby traffic, and offer-ing a navigation service, while continuously sending positionestimates back to our servers. We have built a prototype ofsuch an application for the iPhone. We also have a websitewhere users can view current traffic delays and receive routeplanning updates. Figure 3 shows a screenshot of our website(the iPhone app is very similar).
Figure 3: Web application showing traffic delays.
2.2 Requirements and ChallengesIn the context of the above applications, our goal is to
devise map-matching and time-estimation algorithms that are:1. Accurate, such that time estimates are close enough to re-
ality to be usable for route planning and hotspot detection.For route planning, we believe that errors in the 10-15%
Challenges • Energy consumpGon on the smartphone
– GPS, WiFi both consume significant energy – Ideally, keep the GPS on throughout, but:
• Noisy, inaccurate posiGon samples – Outages from GPS – Inherent inaccuracy of WiFi-‐, GPS-‐based localizaGon
45
Phone Basery Life without GPS
Basery Life with GPS
iPhone 7 hrs 2 hrs 30 min
Android G1 18 hrs 5 hrs 45 min
Energy-‐saving strategies Down-‐sampled GPS
One-‐minute sampling interval WiFi Localiza9on:
Noisy, but lower energy
Either way, must handle infrequent and/or inaccurate posiGon samples from the localizaGon technology.
Contribu9ons • Map-‐matching: Viterbi/Hidden Markov Model (HMM)
– Finding “best fit” trajectory on road map and travel Gmes from noisy, sparse raw locaGons
• EvaluaGon on over 800 drive hours of actual trips made by taxicabs driving in the Boston area – Are Gmes accurate enough for apps like rouGng?
• Maximizing basery life while meeGng accuracy goals – A model for choosing best sensor(s) to use (GPS or WiFi) and sampling frequency, on different phones
Nearest Road Matching doesn’t work
The map matching problem
Given: Sequence of posiGon observaGons <pi> Set of road segments {Sj} Output: Sequence of road segments <si> for each posiGon observaGon
VTrack map matching
1. Outlier removal 2. InterpolaGon to cope with outages 3. Viterbi/HMM map segment matching 4. “Bad zone” removal
49
RAW TRACE OUTLIER REMOVAL VITERBI MATCHING BAD ZONE REMOVAL& INTERPOLATION
Figure 6: The Map Matching process. A raw location trace is gradually refined to produce a final, high quality streetroute. In this example, due to noise and outages, only the first three segments produced quality estimates.
map matching context, the hidden states are road segmentsand the observables are position samples. Here, the emissionprobability for a given ⇥segment, position⇤ pair represents theprobability of seeing that position conditioned on the vehi-cle being on that segment. The transition probability is theprobability of transitioning (driving) from one segment to thenext. Our challenge, then, is: given a sequence of positions,determine the most likely sequence of road segments—theroute—that corresponds to these positions.
Viterbi decoding [24] is a dynamic programming techniqueto find the maximum likelihood sequence of hidden statesgiven a set of observables and the emission probability dis-tribution and transition probabilities. In our case, the hiddenstates corresponds to the route, and the observables are theposition samples.
Figure 5 shows an example where S1, S2, and S3 are roadsegments and p1, p2, p3, and p4 are position samples. There isan equal probability of transitioning from S1 to S1, S2, or S3.Because the emission probability density function is a decreas-ing function of distance, assuming the transition constraints asshown in the state diagram, the maximum likelihood sequenceof segments for the given sequence of position samples is S1,S3, S3, and S3. Although p2 is closer to S2, the most probablehidden state of the point is S3 given the transition constraints.
It is clear from this example why an HMM makes sense formap matching: it is robust to position samples that lie closer toone road segment than the one from which they were observed,and is able to capture the idea of a continuous route instead ofa sequence of segments.3.2 Map Matching
Figure 6 illustrates our map matching approach. Prior tousing an HMM, we pre-process the data to eliminate outliersand cope with outages. We say a sample p is an outlier if itviolates a speed constraint; that is, for some threshold speedSoutlier, the car would have had to travel faster than Soutlier mphto travel from the previous sample to p in the observed timebetween p and the previous sample. We chose Soutlier = 200mph, about twice the maximum expected speed on a freeway.This threshold is intentionally conservative and accommodatesfor the speed between subsequent noisy GPS or WiFi samples.
After outlier removal, we use a simple but novel schemeto deal with outages. Previous work either does not consideroutages [17], or deals with them by doing multiple computa-tionally expensive shortest path calculations, or by invokinga route planner [20] to find the transitions in the HMM. Ouralgorithm uses a simple and efficient scheme which inserts
interpolated points in regions where the location data experi-ences an outage. The algorithm generates interpolated samplesat 1 second intervals along the line segment connecting thelast observed point before the outage and the first followingthe outage, assuming a constant speed along this line. Theseinterpolated points are then fed to the HMM along with thesampled points. Empirically, we have found that the HMMmatches a straight-line interpolation to an approximate short-est path quite well, and achieves good map-matching accuracy(see Section 5.5). The outlier removal and interpolation stepsare shown in the second panel of Figure 6; the interpolatedpoints are shown in green.
Once outliers have been removed and interpolation applied,the Viterbi algorithm is used to predict the most likely se-quence of road segments corresponding to the observed andinterpolated points (third panel of Figure 6). The hidden statesin the Markov model that we use are directed road segments,and observations are position samples. The algorithm com-putes the most likely sequence of road segments given theobservations and outputs a road segment for each positionsample. These road segments specify the route that was taken.
Finally, bad zone removal (fourth panel of Figure 6) isapplied to remove low-confidence Viterbi matches (e.g., fromvery noisy data). This is described in more detail later.
We now explain the transition probabilities which governthe possible sequences of roads, and the emission probability,which governs the most likely road segments for a particularpoint to be observed from.
Transition Probabilities. Our transition probabilities re-flect the following three notions: 1) For a given road segment,there is a probability that at the next point, the car will still beon that road segment. 2) A car can only travel from the endof one road segment to the start of the next if it uses the sameintersection (we also take into account one-way streets); thisensures that the output road segments are continuous. 3) A carcannot travel unreasonably fast on any segment.
The transition probability p from a segment i at samplet�1 to a segment j at sample t is as follows:
1. If i = j, p = � (defined below).2. If j does not start where i ends, p = 0.3. If j does start where i ends, p = � or 0 (this reflects the
third notion, and is explained below).We keep all of the non-zero transition probabilities constant inorder to avoid preference for routes with low-degree segments(routes with intersections without too many outgoing roads).The alternative, which is used by several other map matching
Outlier removal
• Point p is an outlier if car speed would exceed Soutlier between p’s predecessor and p
• Choose Soutlier = 200 mph – Twice expected speed on a motorway
– IntenGonally conservaGve RAW TRACE OUTLIER REMOVAL VITERBI MATCHING BAD ZONE REMOVAL
& INTERPOLATION
Figure 6: The Map Matching process. A raw location trace is gradually refined to produce a final, high quality streetroute. In this example, due to noise and outages, only the first three segments produced quality estimates.
map matching context, the hidden states are road segmentsand the observables are position samples. Here, the emissionprobability for a given hsegment, positioni pair represents theprobability of seeing that position conditioned on the vehi-cle being on that segment. The transition probability is theprobability of transitioning (driving) from one segment to thenext. Our challenge, then, is: given a sequence of positions,determine the most likely sequence of road segments—theroute—that corresponds to these positions.
Viterbi decoding [24] is a dynamic programming techniqueto find the maximum likelihood sequence of hidden statesgiven a set of observables and the emission probability dis-tribution and transition probabilities. In our case, the hidden
states corresponds to the route, and the observables are theposition samples.
Figure 5 shows an example where S1, S2, and S3 are roadsegments and p1, p2, p3, and p4 are position samples. There isan equal probability of transitioning from S1 to S1, S2, or S3.Because the emission probability density function is a decreas-ing function of distance, assuming the transition constraints asshown in the state diagram, the maximum likelihood sequenceof segments for the given sequence of position samples is S1,S3, S3, and S3. Although p2 is closer to S2, the most probablehidden state of the point is S3 given the transition constraints.
It is clear from this example why an HMM makes sense formap matching: it is robust to position samples that lie closer toone road segment than the one from which they were observed,and is able to capture the idea of a continuous route instead ofa sequence of segments.3.2 Map Matching
Figure 6 illustrates our map matching approach. Prior tousing an HMM, we pre-process the data to eliminate outliersand cope with outages. We say a sample p is an outlier if itviolates a speed constraint; that is, for some threshold speedSoutlier, the car would have had to travel faster than Soutlier mphto travel from the previous sample to p in the observed timebetween p and the previous sample. We chose Soutlier = 200mph, about twice the maximum expected speed on a freeway.This threshold is intentionally conservative and accommodatesfor the speed between subsequent noisy GPS or WiFi samples.
After outlier removal, we use a simple but novel schemeto deal with outages. Previous work either does not consideroutages [17], or deals with them by doing multiple computa-tionally expensive shortest path calculations, or by invokinga route planner [20] to find the transitions in the HMM. Ouralgorithm uses a simple and efficient scheme which inserts
interpolated points in regions where the location data experi-ences an outage. The algorithm generates interpolated samplesat 1 second intervals along the line segment connecting thelast observed point before the outage and the first followingthe outage, assuming a constant speed along this line. These
interpolated points are then fed to the HMM along with thesampled points. Empirically, we have found that the HMMmatches a straight-line interpolation to an approximate short-est path quite well, and achieves good map-matching accuracy(see Section 5.5). The outlier removal and interpolation stepsare shown in the second panel of Figure 6; the interpolatedpoints are shown in green.
Once outliers have been removed and interpolation applied,the Viterbi algorithm is used to predict the most likely se-quence of road segments corresponding to the observed andinterpolated points (third panel of Figure 6). The hidden statesin the Markov model that we use are directed road segments,and observations are position samples. The algorithm com-putes the most likely sequence of road segments given theobservations and outputs a road segment for each positionsample. These road segments specify the route that was taken.
Finally, bad zone removal (fourth panel of Figure 6) isapplied to remove low-confidence Viterbi matches (e.g., fromvery noisy data). This is described in more detail later.
We now explain the transition probabilities which govern
the possible sequences of roads, and the emission probability,which governs the most likely road segments for a particularpoint to be observed from.
Transition Probabilities. Our transition probabilities re-flect the following three notions: 1) For a given road segment,there is a probability that at the next point, the car will still beon that road segment. 2) A car can only travel from the endof one road segment to the start of the next if it uses the sameintersection (we also take into account one-way streets); thisensures that the output road segments are continuous. 3) A carcannot travel unreasonably fast on any segment.
The transition probability p from a segment i at samplet�1 to a segment j at sample t is as follows:
1. If i = j, p = e (defined below).2. If j does not start where i ends, p = 0.3. If j does start where i ends, p = e or 0 (this reflects the
third notion, and is explained below).We keep all of the non-zero transition probabilities constant inorder to avoid preference for routes with low-degree segments(routes with intersections without too many outgoing roads).The alternative, which is used by several other map matching
50
Interpola9on to cope with outages • Viterbi/HMM doesn’t handle outages, need to interpolate
– Between two points that span a large amount of Gme – Generate interpolated samples at one second intervals
S1
S2
S3
p1 p2
p3 p4
p1 p2 p3 p4
S1 S2 S3 S3
Too lisle Gme spent on S2: not enough for a U-‐Turn!
Nearest segment gets it wrong
• ProbabilisGc model mapping observaGons (raw locaGons) to hidden states (underlying segments)
Si
pi Raw Point from GPS or WiFi
Road Segment (Hidden State)
Si+1
pi+1
Emission Score E(pi| Si)
TransiGon Score T(Si, Si+1)
High-‐level idea: Find sequence of hidden states (segments) maximizing product of emission and transiGon scores
Hidden Markov model (VTrack context)
• Emission Score: ES(Point pi | Segment si) = d2(pi , si) / σ2
sensor (GPS or WiFi)
• Points closer to a segment si more likely to be from si • Less confidence in points from a high-‐variance source • TransiGon Score: TS(Segment si , Segment si+1) = 0: if segments are not adjacent = 1: if segments are the same = 1: if segments are adjacent and enough Gme has been spent on Segment si to saGsfy speed limit constraint (200 mph)
Vtrack’s Hidden Markov Model
S1
S2
S3
S1
S2
S3
S1
S2
S3
S1
S2
S3
p1 p2 p3 p4
S1 S1 S3 S3
S1 S2 S3 S3 has score 0, isn’t permised (speed constraint)
S1 S1 S3 S3 is most likely match
S1 S2
S3
p1 p2
p3 p4
Viterbi gets it right
“Bad zone” detec9on • Ayer running the Viterbi algorithm, evidently found zones of incorrect map matching
• Remove posiGon samples matched to road segments more than 100 meters away
• “We also tag the subsequent points in the forward and backward direcGon unGl distance between posiGon samples begins to increase [decrease] again.”
56
Travel 9me extrac9on
• Map matching produces the “most likely” segment Sj for each raw point pi in the input
• All raw points pi are separated by one second
– Because we do interpolaGon in advance
• So travel Gme on segment X is approximately the number of points matched to segment X
• Dataset: Cartel Taxicab Data
• Taxi cabs in the Greater Boston Metropolitan area equipped with both GPS and WiFi) – 2145 drives – 25 cars – 800 drive hours
Experimental evalua9on
Ground truth determina9on • Hard problem, because of pracGcaliGes
– Their approach: “clean” GPS data
• Ground truth consists of filtered GPS data – Sampled at high frequency (once a second) – Less than 15 m (road width) from nearest road match – Forms an unbroken drive of closest segment matches
• Evaluate other algorithms on drives where there is connected ground truth road segment Gmes
Evalua9on: Overall methodology Measure accuracy of travel Gmes from: 1. GPS k (one GPS sample every k seconds)
– To avoid unfairness in evaluaGng GPS methods, perturb each sub-‐sampled GPS point with 7 m radius noise
2. WiFi (only WiFi AP sighGngs) 3. GPS k + WiFi (a combinaGon of the above two) 4. Scaled speed limits (baseline for comparison)
– Speed limits from NAVTEQ road database – Choose scaling factor for no average difference between Gme esGmates and ground truth
Evalua9on: Route planning
• How much worse are paths found using strategy X, compared to paths from ground truth Cmes?
Origin DesGnaGon
Shortest path using ground truth (G) takes 25 minutes
Shortest path using X (GPS k, WiFi, …) takes 30 minutes
OpCmality Gap(X) = (30 − 25) / 25 = 0.2
CDF of Optimality Gap: WiFi and GPS k (<60) are usable for route planning
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0
0.04
0.08
0.12
0.16
0.2
0.24
0.28
0.32
0.36
0.4
0.44
0.48
Optimality Gap
Pro
bab
ilit
y
WiFi
GPS 60
GPS 60 + WiFi
Acceptable (<15% error) Borderline
CDF of Optimality Gap: WiFi and GPS k (<60) are usable for route planning
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
00.04
0.08
0.12
0.16 0.
20.24
0.28
0.32
0.36 0.
40.44
0.48
Optimality Gap
Pro
bab
ilit
y
WiFi
GPS 60
GPS 60 + WiFi
Scaled Speed Limits
Speed limits incur high tail errors
WiFi es9ma9on is noisy but accurate WiFi road segment es9ma9on error (Figure 9 in paper) • WiFi has a high error rate for
predicGng Gme to traverse individual road segments
• Average error: 50%
Viterbi algorithm es9ma9on error (Figure 10 in paper) • Point error rate (PER): How oyen
match point to correct segment? • Segment error rate (SER): How
oyen choose correct segment?
65
0
0.2
0.4
0.6
0.8
1
0 0.2 0.4 0.6 0.8 1
Prob
abilit
y
Segment Error = (Estimated Time - Actual Time)/Actual Time
WiFi
Figure 9: CDF of errors in time estimation for individualsegments with WiFi localization.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 0.2 0.4 0.6 0.8 1
Pro
babili
ty
Error Rate
WiFi Point Error Rate and Segment Error Rate
Point Error RateSegment Error Rate
Figure 10: Map matching errors for WiFi localization.
5.3 Hotspot DetectionWe also evaluate VTrack’s time estimates in the context
of hotspot detection, i.e., detecting which road segments arehighly congested so that drivers can avoid them. We say aroad segment has “high delay” if the observed travel timeon that segment differs from the travel time estimated withscaled speed limits by at least threshold seconds. The hotspotsfor a particular threshold value are the set of road segmentswhich have high delay based on the ground truth data, andwe are interested in examining how many of those hotspotswe can detect using traces of WiFi data, GPS+WiFi data, orsubsampled GPS data.
Note that an alternative definition of a hotspot is a road seg-ment in which the observed travel time is more than thresholdtimes the travel time estimated with scaled speed limits. Wefound that this definition was unfair due to its dependence onthe length of the segment: small segments, which have a lowestimated travel time, would be more likely to be flagged ashotspots than large segments, which have a high estimatedtravel time. Thus, we chose to use the first metric, as itmore accurately reflects the road segments that drivers viewas hotspots.
To detect hotspots using a trace of WiFi, GPS+WiFi, or
subsampled GPS data, we first find the segments that havehigh delay. We classify each of these segments as a hotspot, aswell as their two adjacent segments if these segments appearin the trace. Effectively, this results in us flagging “groups” ofsegments as hotspots. This method reflects the fact that ourtravel time estimation algorithm is not always certain as towhich segment a high delay should be attributed to, but tendsto only be off by one segment (in a sequence).
To measure our performance, we use two metrics: successrate and false positive rate. The success rate represents howmany hotspots we successfully found, and is defined as thefraction of ground truth hotspots that our algorithm detected.The false positive rate is the fraction of hotspots we “detected”that were not actually hotspots. In the real-world, this is equiv-alent to suggesting that a driver avoid a segment that is notactually congested. We record a false positive if we flaggeda group of segments as a hotspot, but that group was not ahotspot (we can define a group as a hotspot analogously to asegment: the group is a hotspot if the total travel time on thegroup is more than threshold�number segments in group sec-onds above the travel time estimated by scaled speed limits).
0
0.2
0.4
0.6
0.8
1
0 20 40 60 80 100
Fra
ction o
f H
ots
pots
Corr
ectly D
ete
cte
d(S
uccess R
ate
)
Threshold
GPS every 20s + WIFIGPS every 30s + WIFI
WIFIGPS every 20sGPS every 30s
Figure 11: Success Rate of Hotspot Detection
0
0.2
0.4
0.6
0.8
1
0 20 40 60 80 100
Fra
ction o
f H
ots
pots
Incorr
ectly D
ete
cte
d(F
als
e P
ositiv
e R
ate
)
Threshold
GPS every 20s + WIFIGPS every 30s + WIFI
WIFIGPS every 20sGPS every 30s
Figure 12: False Positive Rate of Hotspot Detection
Figure 11 shows the success rates for each strategy, and Fig-ure 12 shows the false positive rates for each strategy. There
0
0.2
0.4
0.6
0.8
1
0 0.2 0.4 0.6 0.8 1
Prob
abilit
y
Segment Error = (Estimated Time - Actual Time)/Actual Time
WiFi
Figure 9: CDF of errors in time estimation for individualsegments with WiFi localization.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 0.2 0.4 0.6 0.8 1
Pro
babili
ty
Error Rate
WiFi Point Error Rate and Segment Error Rate
Point Error RateSegment Error Rate
Figure 10: Map matching errors for WiFi localization.
5.3 Hotspot DetectionWe also evaluate VTrack’s time estimates in the context
of hotspot detection, i.e., detecting which road segments arehighly congested so that drivers can avoid them. We say aroad segment has “high delay” if the observed travel timeon that segment differs from the travel time estimated withscaled speed limits by at least threshold seconds. The hotspotsfor a particular threshold value are the set of road segmentswhich have high delay based on the ground truth data, andwe are interested in examining how many of those hotspotswe can detect using traces of WiFi data, GPS+WiFi data, orsubsampled GPS data.
Note that an alternative definition of a hotspot is a road seg-ment in which the observed travel time is more than thresholdtimes the travel time estimated with scaled speed limits. Wefound that this definition was unfair due to its dependence onthe length of the segment: small segments, which have a lowestimated travel time, would be more likely to be flagged ashotspots than large segments, which have a high estimatedtravel time. Thus, we chose to use the first metric, as itmore accurately reflects the road segments that drivers viewas hotspots.
To detect hotspots using a trace of WiFi, GPS+WiFi, or
subsampled GPS data, we first find the segments that havehigh delay. We classify each of these segments as a hotspot, aswell as their two adjacent segments if these segments appearin the trace. Effectively, this results in us flagging “groups” ofsegments as hotspots. This method reflects the fact that ourtravel time estimation algorithm is not always certain as towhich segment a high delay should be attributed to, but tendsto only be off by one segment (in a sequence).
To measure our performance, we use two metrics: successrate and false positive rate. The success rate represents howmany hotspots we successfully found, and is defined as thefraction of ground truth hotspots that our algorithm detected.The false positive rate is the fraction of hotspots we “detected”that were not actually hotspots. In the real-world, this is equiv-alent to suggesting that a driver avoid a segment that is notactually congested. We record a false positive if we flaggeda group of segments as a hotspot, but that group was not ahotspot (we can define a group as a hotspot analogously to asegment: the group is a hotspot if the total travel time on thegroup is more than threshold�number segments in group sec-onds above the travel time estimated by scaled speed limits).
0
0.2
0.4
0.6
0.8
1
0 20 40 60 80 100
Fra
ctio
n o
f H
ots
po
ts C
orr
ectly D
ete
cte
d(S
ucce
ss R
ate
)
Threshold
GPS every 20s + WIFIGPS every 30s + WIFI
WIFIGPS every 20sGPS every 30s
Figure 11: Success Rate of Hotspot Detection
0
0.2
0.4
0.6
0.8
1
0 20 40 60 80 100
Fra
ctio
n o
f H
ots
po
ts I
nco
rre
ctly D
ete
cte
d(F
als
e P
ositiv
e R
ate
)
Threshold
GPS every 20s + WIFIGPS every 30s + WIFI
WIFIGPS every 20sGPS every 30s
Figure 12: False Positive Rate of Hotspot Detection
Figure 11 shows the success rates for each strategy, and Fig-ure 12 shows the false positive rates for each strategy. There
SER
PER
CDF CDF
Why is WiFi good for rou1ng in spite of high individual segment errors?
Segment A
Segment B
• WiFi Gmes: 10 seconds on A, 20 seconds on B
• Ground truth: 20s on A, 10s on B
• This error doesn’t maser if A and B appear together in routes
Evalua9on: Road hotspots
• Road hotspot definiGon: Calculated segment Delay > Scaled speed limit delay + Threshold
• Success Rate(X) = FracGon of hotspots found by ground truth that are found using strategy X
• Spurious Rate(X) = FracGon of hotspots reported by X that aren’t ground truth hotspots
Success Rates For Hotspot Detection (One Minute
Absolute Threshold)
0
10
20
30
40
50
60
70
80
90
100
GPS 30 GPS 30 + WiFi GPS 20 WiFi
Su
ccess R
ate
(%
) WiFi has too many outages
GPS sub-‐sampling detects most hotspots
• All spurious rates were < 1% • Average segment travel Gme approx. 15 seconds
Energy-‐accuracy tradeoff
• What are the relaCve energy costs of WiFi and GPS? • Ran a basery lifeGme microbenchmark on the iPhone:
69
are a few interesting points to make from these graphs.First, for the strategies involving GPS, the success rate
is consistently above .8, and many times around .9. Thismeans that these strategies can consistently detect between80% and 90% of hotspots. The success rate for WiFi data ismuch worse, frequently around .65. This reflects the fact thatthere are significant WiFi outages, and our hotspot detectionalgorithm cannot find a hotspot for which it has no data. Incontrast, our GPS data has complete coverage. We do notethat if we restrict our statistics to road segments where thereis WiFi data, WiFi has a success rate comparable to all of theGPS schemes.
In all schemes, the false positive rate remains low. Thisindicates that our hotspot detection algorithm is not too ag-gressive, in that it does not flag segments that are not hotspotsas such. This is a desirable property as we do not want usersto avoid road segments that are not actually congested.
It is interesting to note that, with the exception of GPSevery 30 seconds, our success rate in every strategy remainsrelatively consistent across all threshold values, indicating thatour algorithm is robust to applications which have specificrequirements for what constitutes a hotspot. Our false positiverate also remains low for most threshold values, and for themost part only increases for small thresholds. This is due tothe fact that, with a small threshold, we are likely to flag manygroups of segments as hotspots, and these groups may includesome segments that do not have high delay (but were includedbecause they were adjacent to a segment with high delay).
We note that there is a dip in all of the strategies at around40 seconds. At small thresholds, we flag many segments ashotspots, and thus have a high success rate (as well as morefalse positives). As the threshold begins to increase, we startto miss some hotspots, but our false positive rate decreasesdramatically. This explains the portion of the graph before athreshold of 40.
The second portion of the graph can be explained by exam-ining the total number of hotspots. As the threshold increases,the number of hotspots naturally decreases. At about 40 sec-onds, the rate of decrease slows, and from 60 seconds on, thenumber of hotspots remains fairly constant. This means thatmany of the road segments that are hotspots with a thresholdof 60 are also hotspots with a threshold of 100; their observedtime differs from their estimated time by over 100s. As aresult, we do very well flagging hotspots at larger thresholds,since they are “obvious” hotspots, in some sense.
Discussion of WiFi Outages. In our data, we found thatWiFi data has an outage rate of 42% (i.e., 42% of the timewhich we are trying to use WiFi data, we do not get a WiFiobservation). This raises the question: how can a sensor thatis so unreliable still perform well in some applications? Inparticular, we saw that although WiFi sensors did not workparticularly well for hotspot detection, they did work well forroute planning. The reason for this is that in route planning,using the scaled speed limit estimates on segments where thereis no WiFi data is generally sufficient. Outages in WiFi tend tocause missed data points on small segments; these are exactlythe segments where NAVTEQ estimates are reasonable. Eventhough using NAVTEQ estimates on the entire path does notperform well (e.g., they cannot account for congestion), using
these estimates as a back-up for segments missing WiFi datacan work well in certain cases. In hotspot detection, on theother hand, we could never use the scaled speed limit estimatesin place of WiFi data. After all, we define a hotspot as a roadsegment where the observed time estimate differs from thescaled speed limit estimates.5.4 Energy vs Accuracy
In this section, we combine the results presented above withan empirically determined model of energy costs for WiFi andGPS, to study the tradeoff between energy and accuracy forthree different strategies: GPS subsampled periodically, WiFi,and a hybrid strategy that combines the two. As before, allour results involving GPS assume GPS is available at all timesand free of outliers.5.4.1 Energy Measurements
To get a better understanding of energy costs of location-estimation on a smartphone, we measured the power con-sumption of GPS and WiFi on the iPhone using battery lifeas an indicator. We wrote a simple iPhone application thatrepeatedly requests location estimates at either GPS or WiFiaccuracy, with a user-specifiable periodicity, until the batterydrains to a fixed level from a full charge (in our experimentswe drain the battery to 20%). Because of the way iPhoneapplications work currently, we had to run this application inthe foreground with the phone’s screen turned on, so we ran athird control experiment and measured the total lifetime withthe screen on, but without requesting location estimates. Ourresults are summarized in the following table:
Location Mechanism Sampling Period LifetimeNone - 7 hGPS continuous ( 1/sec) 2 h 24 mGPS 30 sec 2 h 27 mGPS 2 min 2 h 44 mWiFi continuous ( 1/sec) 6 h 30 m
These results show that on the iPhone, GPS is extremelypower hungry and reducing the sampling period does not im-prove the performance greatly. The reason appears to be thatthe iPhone OS leaves the GPS on for about a minute evenwhen an application de-registers for position estimates; hence,sampling GPS every 30 seconds is as expensive as continu-ous sampling, and sampling once every two minutes doesn’tsave a significant amount of power. In contrast, the iPhoneseems to do a much better job of aggressively managing WiFipower consumption when no data is being sent and the radiois being used only for localization. Previous work [10] cor-roborates these numbers on a different device, showing thatWiFi localization can provide 2-3 times the battery life of GPSlocalization on Nokia N95 phones.
Since poor GPS power management appears to be aniPhone artifact, it is instructive to estimate sensor energy costson a hypothetical device with better GPS power managementand the ability to run a localization program in the background(with the screen turned off). There is every reason to believethat future platforms will provide both of these features.
Estimating WiFi Cost. We can use the numbers in thetable to solve for the WiFi energy cost as a fraction of thecontinuous GPS sampling cost. Suppose the battery has ca-pacity c Joules. The baseline lifetime, without any location
• iPhone (at Gme of publicaGon) leaves GPS on 1 min. ayer use • ConGnue evaluaGon with GPS that turns off (Android G1) • Analysis, comparing the above figures:
– Cost per sample of GPS is 24× cost per sample of WiFi – WiFi sampling power consumpGon about 8% of the phone’s baseline
VTrack: Conclusions
• Vtrack contribuGons – “Crowdsourcing” travel Gme esGmaGon – Road hot spot detecGon to warn users – Tradeoff between energy efficiency and accuracy
• Impact on commercial traffic monitoring • Viterbi/HMM map matching now de facto
71
NEXT MEETING
6th March in MPEB 1.13 Rateless Codes: Spinal Codes
72
