Pretty cool. You can achieve similar localization accuracy with WiFi, BLE, ZigBee, or long-range RFID. Common techniques are time of flight (ToF, or time of arrival), FMCW ranging, fingerprinting, or signal strength modeling.
Depending on the method used, the limitations arise from (a) needing to know ground truth location of beacons; (b) any necessary training steps; (c) multipath issues; (d) synchronization; or (e) other non-ideal RF artifacts.
You can also combine multiple sensor measurements over time (eg. a person's path) using bayesian inference techniques (ie. particle filters) to further improve location accuracy.
(This topic is related to my PhD thesis: mobile robots finding and interacting with long-range RFID tags in homes. Many of the techniques are akin to radar: http://www.travisdeyle.com/research.html)
Jakub again here. This is great; thanks for your comments. We try to have a very pragmatic approach and believe that room beaconifying procedure should be extremely simple, so mobile developers can concentrate on domain specific challenges regarding their use-cases.
Thus, ref (a) it is as simple deploying few beacons in the room (see this video: https://www.youtube.com/watch?v=wtBERi7Lf3c)
The floor plan and location of beacons is calculated automatically and once you save the room in the cloud you or other people can access calibration and build location-aware apps. There is also no specific training requirement.
The advantage of using BLE beacons over WiFi or ZigBee is the fact they are natively integrated with mobile operating system s (e.g. via iBeacon protocol for Apple), so a smartphone can perform calculations in the background without any user intervention - frictionless applications are possible.
I had a fiddle with some Estimotes for a research project last year. Managed to get some fairly inaccurate indoor location tracking going on Android using 4 beacons and some fudged trilateration functions, then did some cool location-based things with Philips Hue bulbs. Was a blast!
Keep up the good work, can't wait for the Android Indoor SDK! (I appreciate that it's more effort due to differences in device hardware, etc)
How big is "large spaces" (should I start pitching this internally for a client with a ~30x60m room)?
How does it perform with many people at once (think of a trade show booth hall - if there were 300+ people running an app would it be practical to use this to direct users to a 3x4m booth amongst a hundred or two such booths)?
Technically there is no limitation in the size of the space; it can be an airport or shopping mall - you just need to use more beacons if you want better results in a huge space.
See this GIF: http://i58.tinypic.com/33nyrgo.gif It's a 30m x 15m space (half of your space) and we used 12 beacons. You can use less if you want "corner / room" level accuracy.
Because beacons broadcast signals all around any number of devices can access their signals and there is no limit in number of people with mobile app that uses our SDK. If you put beacons high enough the signal absorption should be minimal, but we haven't tested with high density crowd yet.
Do you use time of arrival techniques? What strategy do you use to overcome indoor multi-path conditions? Are there more detailed implementation notes somewhere?
Reading the documentation, I agree that you're abstracting away the "nitty-gritty" of location-finding, but I think it'd be really helpful to see where measurement errors might be hiding via an open description of the computational model used, even if (or especially if) it's very simple. It would give me more confidence as a user and allow me to be more forgiving if there were reasonable discrepancies in measurements.
Looks really cool! I think I'd like to try this and write about my experiences.
We use combination of many different techniques incorporated into our SDK, so there is no one specific formula - think more about it as a "driver" for the physical-location and communication device (e.g. iPhone).
For the average iPhone-toting person whose location is the one being plotted, what does their phone have to be set to in order for this to work? Do they have to have a specific app installed? Does Bluetooth merely have to be turned on? What about "Bluetooth turned on, but not visible to unpaired devices"? Might anyone be able to point out the direction to information of the sort?
I see some information here [0], but I am not sure how this relates to common settings like "Bluetooth off", "Bluetooth on and visible", and "Bluetooth on but invisible to unknown devices."
Im guessing (based on recently using Estimote beacons in a project) that this relies on inexpensive beacons and most of what happens is in the app. The beacons don't talk to the cloud service - the app does. I think the app listens for the beacons which are sending sending RSSI (received signal strength indication) information as well as heir unique id, and the cloud service is estimating your distances from 3 or 4 beacons and solving to get a position then sending that back to the app. (It's probable the app could do that itself, but Estimote might have some "secret sauce" that makes their cloud-reliant solution better - perhaps by aggregating data about the Bluetooth reception quality on a per model or device basis and updating their position estimate algorithms in real time. If I wanted to implement something like this without leaking user location data to Estimote/The NSA, I'd probably try using rough models in-app (without sending the beacon data anywhere) and using accelerometer/gyro data to provide additional dead reckoning input.
Note though - much of the same tricks can be pulled with 2.4gHz capable SDRs passively listening for wifi/bluetooth (and even cellular) transmission from your phone. This is almost certainly being used to track you in shopping malls already, and I'd be quite surprised to head it's not also deployed in airports, military contractor campuses, and large privacy invasive corporations - as well as wherever various three letter agencies of overreaching law enforcement want it.
Thanks for the insight. Might you be able to guess how the Bluetooth on/off/on and visible settings work for visibility for passive listening? If my phone is linked/paired with my Bluetooth headset but not visible to other devices, is it still noticeable by the passive listening devices?
From what I understand with WiFi and Google Location Services, if you have WiFi "on but not connected", your phone is regularly sending out messages to any router that will listen saying "Are you SSID x, y, z, a...etc.?" Android phones record this information, i.e., SSIDs pinged and your coarse location, and report this back to the mothership so as to improve the estimated position of all of these SSIDs/router MAC addresses. Theoretically, if I understand what you're saying, is that there could be hardware devices that require no input from the user: the routers themselves would be noting who (i.e. which phones/MAC addresses) ping them asking for which SSIDs and record those as they progress through a space. Put enough routers in a space and you can triangulate based on RSSI....is that the basic idea?
Wifi is easy - any wifi module that can be put into "monitor mode" will let you listen in for SSID probes. Apple have started randomising the MAC address the device uses for those probes in iOS8, which is a start, but there's often a close-to-unique fingerprint that you still get from the set of SSID's that are probed for (how many people do you suppose probe for "Company $A Staff Wifi, Shopping Mall $B free wifi, Cafe's $C $D and $E free wifi, and person $F home wifi") - there's also a trick that I think I heard WifiPineapple uses of listening for common SSID probed (McDonald Free Wifi, Netgear, etc), then responding as that base station - then getting the real MAC address during the negotiation phase).
BlueTooth is only a little more difficult - you only need a hundred or so dollars to start playing there though: http://ubertooth.sourceforge.net/ or https://github.com/mossmann/hackrf/wiki/HackRF-One will both let you see BlueTooth radio traffic - it's somewhat harder to dig into their encrypted traffic, but seeing and measuring the signal strength is easy.
It's bluetooth on and you need to give permission to the app to have access to your location. The app can ask for access "all the time" or "only when open", to which you also need to confirm.
Would the result be easily distorted by e.g. (human) bodies standing in-between, or certain materials (e.g. installing it in an art exhibition, but certain art installations use certain materials that can distort the beacon measurement)?
As I understand it, Estimote's main technical selling point is that it uses Bluetooth LE. So the "beacons" can be made cheap and low-power, plus you get out-of-the-box compatibility with modern smartphones.
This intensity-based approach is probably suitable for deciding what ad to display as someone moves around a store. It's not going to make VR headsets work indoors.
At 1M, this would become much more useful. Then they could tell which aisle of a store you're in, and approximately what shelf section. At 4M, it's more like knowing what department in a department store. At 1M, for a museum system, they could tell what object you're looking at and give you the audio for it.
These are very cool, but unfortunately the last time I tried using BLE (specifically Estimote beacons with their sdk) in an Android app the interference with wifi made the experience unbearable. Presumably not all chipsets have the problem, but every single one I tested had trouble.
Depending on the method used, the limitations arise from (a) needing to know ground truth location of beacons; (b) any necessary training steps; (c) multipath issues; (d) synchronization; or (e) other non-ideal RF artifacts.
You can also combine multiple sensor measurements over time (eg. a person's path) using bayesian inference techniques (ie. particle filters) to further improve location accuracy.
(This topic is related to my PhD thesis: mobile robots finding and interacting with long-range RFID tags in homes. Many of the techniques are akin to radar: http://www.travisdeyle.com/research.html)