My first project as a software apprentice with Mutually Human is just wrapping up. The other two apprentices and I explored the idea of using Bluetooth low energy beacons to help locate your position. We created an app that connects to nearby beacons, estimates your phone’s location in relation to those beacons, and shows the location on a small simple map. We tested this app in our office. Below is an animation of our current app’s performance. I collected these screencaps while walking slowly across the 30’ by 48’ room, which we have gridded with beacons (represented by the blue dots). The red circle indicates the app’s estimate of where I was located, and the black dot is roughly where I was actually standing. Note: we actually never set up and tested the bottom three beacons in this image, so the inaccurate behavior near the end of the gif is actually sensible without the data from those three bottom beacons.
Although the final app we ended up with isn’t incredibly accurate, I believe that relatively high-accuracy location estimation can definitely be done with these beacons. Our results are promising and I think by using BLE data as well as some compass or accelerometer data, we could make a very accurate location-tracking app. This blog post is mainly intended to explain some of the main challenges we encountered, the solutions or workarounds we came up with, and some ideas for future work that we believe would improve our accuracy significantly.
First of all, though, I want to explain the background of this project and why we think that using bluetooth beacons for estimating location is an idea worth pursuing. Bluetooth low energy (BLE) is a technology intended to provide the same communication range as traditional bluetooth, but with much lower energy consumption–and thus a longer battery life. For a location tracking application, long battery life is a huge plus. Ideally, once these beacons are placed in a room, they would be able to stay in place for a very long time with little to no maintenance necessary. If we needed to replace batteries in each beacon every few months, this would be annoying and impractical. In addition to their long battery life, BLE beacons are also quite cheap. This means that we had essentially unlimited resources–even if we found that you need a dense “net” of beacons in your space to make this location-tracking work well, price would not be prohibitive. Lastly, using BLE is nice because it is a fairly established, common technology and is already supported by most computers and mobile devices. There was a lot of well-written documentation and existing infrastructure that we were able to learn from and use.
BLE is already used for proximity sensing in consumer applications. For example, you could go to Target right now and buy a small device to attach to your keys, your smartphone, your wallet, whatever–and it will help you find them if you misplace them in your house. Unfortunately for us, the best/only way to calculate a distance between the BLE device and your smartphone is by using the signal strength in decibels and then creating a function to map these signal strengths to real-life distances. In addition to this method depending on your function being accurate, this is inconsistent in a few other ways.
Most annoyingly, the signal strengths that we read from two “identical” beacons at the same location are likely to be different. For example, if you stand 10 feet from two beacons, you will likely read different numbers from each beacon. Initially we suspected that this might be affected by the battery level, so beacons with older batteries would be broadcasting weaker, but replacing them all with fresh batteries made little difference. We are still not really sure why this happens. Our current solution is to individually calibrate each device–the first time you use the app with new beacons, you need to stand a fixed-distance away from each beacon for a few seconds while the app takes a few measurements. These measurements allow us to equalize the beacons so they all give us similar readings at the same distance. Calibrating the devices like this is a bit of a pain, especially if you have a LOT of beacons, but at least it should only have to be done once.
We additionally found that there was a lot of noise in actual data readings. While standing in an empty room, fairly close to a beacon with no obstacles or sources of significant interference, the decibel readings from the beacon fluctuate within a 10 decibel range. This causes our distance estimates to vary pretty wildly and unpredictably. We are trying to get around this in two ways: by simply adding more beacons, and also by averaging the readings. Adding more beacons to the environment should help because even with this level of noise, we hope that simply having more data to analyze will help us see through the noise. As for averaging, our initial method was to collect 5 seconds of readings, remove the highest 10% and lowest 20% of our data as potential outliers, and average the rest of the readings. This worked okay when standing still, but the 5-second delay was a bit of a bummer when moving around. Our current algorithm uses some data from the accelerometer to determine if the user is moving or not. If we detect movement, we weigh recent (within one second) readings more importantly than previous readings. If we are standing still, we remove the potential outliers as before but then we take the mode of the data instead of the mean.
In the future, we hope to work with the accelerometer data more. Currently we only use this data to determine if the user is moving or standing still. We suspect that it would be reasonable to additionally figure out which direction the user is moving and use that in our estimate for moving locations. Additionally, since we noticed that having your body blocking the beacons behind you actually affects their readings a lot, we think that it would be interesting to use the compass data to determine which beacons you may be blocking, and either artificially boosting their signals, or entirely removing them from the calculation.
It would also be interesting to change the layout of the app a bit. Instead of plotting your location exactly on a map, it may be more accurate and usable to grid the map into “zones”, and report which zone you are in. We think this might help reduce the problem we are having with noise, since we wouldn’t have to be quite as precise with the coordinates. In the example below, I divided the area into 24 smaller zones. At each step, I darkened the zone that our estimate was closest to. In this example, our results aren’t much better with zoning rather than just plotting the point, but I see potential in using this method in a larger room or possibly use it when our data is particularly noisy and is jumping around a lot.
Currently, the red circle that estimates your position doesn't vary in size at all. It would be worthwhile to add functionality to have the circle change radius to reflect some sort of computational confidence, or possibly for the radius to be one standard deviation.
Overall, I think this experiment and exploration has been successful. I am thoroughly convinced that with more time and a bit more research, we could create a functional and accurate BLE location app.