Using Bluetooth to estimate distance
There are a number of ways to estimate distance between two devices using Bluetooth. What seems to be the most robust, successful technique includes using a mesh of stationary devices, called ‘gateways’, and having a mobile device within the mesh utilize a combination of readings from multiple gateways to determine position inside the mesh network. This was popularized during the rise of COVID, and was used to great effect to maximize social distancing and implement contact tracing measures between people inside buildings.
Locating a mobile device via measuring distance between Bluetooth beacons inside a mesh network.
However, I knew I wanted Arbo to function outdoors as well as indoors, and I did not want to depend on a mesh of wireless devices to be able to determine distance between Arbo and the user. For this reason, I begun researching distance estimation techniques that utilize only two devices.
I’ve found a very interesting research paper about using Time of Flight to estimate distance over BLE. The ESP32 I'm using for Bluetooth operates with a clock speed peaking at 240Mhz, so it looks like the best we'll get is ~1.2m of accuracy. I could stick a cell phone in the chassis to act as a BT receiver which could probably give more accurate distance readings from a faster clock, but one of the main goals of the project is getting more familiar and comfortable with embedded programming, so I'll continue to use the ESP32.
ToF is much less affected by losing line of sight, which is important to consider because we're using the user's cell phone as one of the Bluetooth points
Sparknotes; accuracy depends on the clock speed of your chip, and the minimum accuracy is half the distance that a radio signal will travel in one tick, if both devices are keeping track of time. Minimum signal interval is 7.5ms as a Bluetooth spec, the paper found diminishing returns of accuracy when averaging > 100 readings, so that's about ~750ms to get an accurate reading. My chip's clock peaks at about 240Mhz, speed of light 300000km/s, so we're looking at accuracy within ~625cm, and ~.75s to get there.
Concerns were raised whether or not .75s would be too much latency for maintaining good control.
It's not a deal breaker. I think we'll have to do a little dance to calibrate every time the phone is paired to establish a base level of triangulation. As far as locating after that, I think as distance increases, we can increase the speed, and the need for accuracy decreases along with that.
We know we're limiting max speed to 1.7m/s (~4mph), so if we maintain a distance of, say, 3.4m (10ft) we can cut the time required to average 50 packets, .375s, around the duration of a blink. Distance covered in the time to take that reading is 0.67m, but since we're in control of the speed and have onboard gyroscope for acceleration vectors, I'm confident I can implement something to account for Arbo's movement while taking readings. If the distance is shrinking over time, we can slow down and get more accurate. Anyway, table below is squared error depending on number of packets averaged, orange is ToF, blue is Signal Strength, 50packets highlighted in red. It looks like even 50 packets is enough to you in the neighborhood of peak accuracy.
In the next chapter we’ll begin work implementing Time of Flight calculations on the ESP32, before taking what amounts to a 9 month break while I finished my senior year of college. Priorities, priorities.
Thanks for reading!
