Updates on
Indoor Localization System
Kaifei Chen, Siyuan Jack He, Randy Katz, David Culler
Old System Design
Problems
•
•
•
In old system, application collects data from sensors and
sends requests to localization server
• It becomes throughput bottleneck
• It becomes functionality bottleneck (deal with
different sensors and algorithms)
A sensor/algorithm can be used by several components
(multicast)
System breaks if any components doesn’t conform to
data structure
New System Design
System Dataflow
Acoustic Ranging Using De-convolution
WiFi Fingerprinting
WiFi Signal Strengths Are Not Stable
WiFi Appearance Possibility Are Stable
• Use Message Queue as Overlay Network
• Mobility, caching, multicast, security
• Separate Sensor, Algorithm, and Users
• Sensors are deployed by their owner. They publish to
their own topics.
• Algorithms are instantiated by and talk to our Golang
wrapper via Cap’n Proto. They define their input and
output data schema.
• Users instantiate algorithm by publishing input and
output topics to an algorithm wrapper.
• Broker verifies data schema on each topic
Signal Strengths Result, 69% Accuracy
Appearance Possibility Result, 88% Accuracy
• Send Sine Sweep Wave f(t), and
denote its time reversal as f’(t)
• Record acoustic response g(t)
• Get impulse response
y(t) = g(t) * f’(t)
• Find peaks in y(t) and calculate
distance