You do realize that in 60 seconds sound will travel over 20 km and would be undetectable at that range? What we’re saying is that unless you have much more than a hobbyist budget you will not be able to measure how far sound/light/radio travels over short distances. Probably no amount of budget would make it possible using NETMF managed code.
@ ianlee74 -
Thank you for your response. I will have to come up with a clever approach to measuring the relative proximity of one device to another. What is that old saying, necessity is the mother of invention? Many thanks for everyones patience, help and insight.
Yes, you can do that. But the actual flight time of the radio message would be immeasurably stort. To get any useful timing you would need bluetooth modules 100000km apart, that would give you a ping time of 0.3 seconds. You can do 10000 pings and the time would still be immeasurably short. Take then into account that the bluetooth stack also adds it’s own time delay, which would be a factor of 10000 more than the flight time of the message.
Except, it’s not. At all. Not even close. What you’re talking about is NASA-budget-level stuff, or large-university-research-grant-level stuff, at least. You could get a doctorate in physics if you made it work and wrote up a paper.
If you sent and received enough pings that the whole exercise took you, say, an hour, then the actual travel time for the radio signals would still be in the millionths of a second. Your signal-to-noise ratio is astronomically low. Comically low. You’re trying to count grains of sand on the moon using a pair of binoculars. Turned backwards.
Let’s examine:
[ul]You’d need a high-precision and high-accuracy time base. You don’t have one. No hobby-level RTC or other time base (such as the clock in your microcontroller) is anywhere near accurate enough. We’re talking atomic-clock level accuracy here. Do you have a cesium fountain handy?
You’d need an accurate way to tell when a signal was sent. You don’t have one. Even assuming that the bluetooth module’s internal latency was known, the over-the-air latency is NOT. Bluetooth uses CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) and a random backoff, that is to say, if the module tries to transmit and the “channel” (airwaves) is busy, it waits for a random amount of time before attempting to send again.
You’d need an accurate way to tell when a signal was received. You don’t have one. Even assuming native code, an interrupt can only be raised (even theoretically) as soon as the next clock tick, which isn’t soon enough to be accurate. Furthermore, the message may have been transmitted multiple times, due to interference (this is separate from the aforementioned backoff), and you have no way to know whether it has, or how many times, or how much time passed between attempts.
You’d need a real-time response from the remote unit. You don’t have one. The Gadgeteer system that will be sending replies could wait up to 20 milliseconds before even notifying your software that a message arrived. That’s enough time for your radio signal to go from Pittsburgh to London. Then, it must turn around and send a reply. This could take anywhere between “not very long” to “quite a while”, and it almost certainly wouldn’t take the same amount of time each time it replied. You can’t control the delay, and you can’t know the delay.[/ul]
I wish I could offer some hope here, but there really is none. This is why things like differential GPS were invented, because there are no other good options.
In fact, I’d probably look into differential GPS. You might be able to get something like what you want from that, and it definitely IS implementable with Gadgeteer and a hobby-level amount of dedication.
1 Like
For my application, that’s exactly why I’m resorting to 5 methods to get an acceptable level of positioning. By starting with GPS to get me within 3m or so of the current position, combining ultrasonic sensors for bots to range themselves from objects, ledges and one another (and the lack of needing it in real time based on the low speeds they will be moving), IR for live objects nearby/approaching for safety measures and using wheel encoders to measure distance traveled and “known” points (really edges of a polygon that are a certain distance from a starting point) via an RFID tag position, my application’s positioning logic should be just enough for consumer/hobbyist grade accuracy. If I were doing anything that involved higher speeds, flight or close work of multiple bots in a confined space, there is no way those would be sufficient.
I’m actually at the point that I’m considering RLPLite for some of the functions and running 2 or 3 different mainboards per bot to get enough processing power to keep all sensors straight (plus Gyro/Compass and Temp/humidity and Light) and have the sensor boards report “status flags” to one another and the motor control board to take certain actions (like to drive the motors) instead of keeping track of the full set of data parameters on one board and hope it can do it all.
As I said, would be glad to help anyone trying to get this more accurate as it will definitely benefit my project, but without a huge influx of cash and brainpower (namely in the form of multi-variable calculus that I barely remember from 15 years ago) or a significant drop in price or open-sourcing of NASA/DOD code, I don’t see us getting too much in the next year or two that would be able to use most of the more complicated methods discussed.
That being said, I think this is a very healthy discussion for the lot of us involved and although it’s definitely not the solution you had in mind @ Bob, hopefully we can get you closer to something that will work for your project and some of ours as well.
Silly question, does the Bluetooth have a signal strength meter? I remember working on a project where we would read the dB of the wireless signal strength and we could see at x distance, we would see x dB signal strength.
Signal does not equal distance. What if you are behind a wall or by large metal objects?
Then your distance will be further away since you would have to walk around that wall so signal= distance 
Just kidding you guys…
True, but if this was not going behind walls and near large metal objects, could you still use it?
In ideal conditions, yes. That is impossible or very difficult.
Assuming there were no other radio sources nearby, no solar flares, no microwave ovens, i.e. if you were inside a Faraday cage with the other device, and you needed accuracy on the order of a scale of 1-3 (1 being “quite close”, 2 being “somewhere in the middle”, and 3 being “almost too far to hear”), then you could probably make it work.
Don’t expect a Nobel for this one, however 
@ stevepresley -
Steve, the entire dialog has been worth it, even if it does not solve my problem. Everyone has shared an enormous amount of knowledge and know how. It was a very interesting and insightful discussion. Thank you, and eveyone that participated. Who knew that wanting to know the distance between two objects in a room would be so challenging.
I still think the ultrasonic idea has merit. You’d need native code, to be sure, but it could be done, I think. If you were inside a room, you’d have issues with echos, but maybe they could be worked out?
I should have code for the ultrasonic sensors I’m using polished up, and possibly using RLP in the next few weeks. My rovers are intended for use outdoors, but I can do some indoor testing (although the GPS won’t be able to assist with position in those trials)
Normal ultrasonic rangefinders won’t work in this application, because they only tell you how close SOMETHING is, they don’t tell you what it is. In this application, you would need to send a “ping” and wait for a recognizable, identifiable response. You’d need to be able to modulate something into the “ping” and be able to demodulate it out upon receiving the response.
Has anyone considired a camera on every bot, pointing up, looking at markers on the ceiling? Then each bot can get it’s own location, and share it with it’s borthers via bluetooth?
Right, unless you were using multiple methods… like…
That’s sort of what I am doing with RFID tags in a fixed position (to define a corner of a polygon) and wheel encoders to measure distance from that point with compass in a direction to determine distance from the point (along with GPS).
For an indoor scenario, that would work, or QR codes or something on the walls.
Someone else mentioned cameras on each bot looking at the other bots for identification - this would work too, but wouldn’t give you the distance alone. You could however have a camera mounted above/below a rangefinder, both on a servo that can be positioned and/or move along with the target object. The camera would identify what it is looking at - a QR code (for instance) to identify a particular side of a bot, a particular boundary marker, etc, range it by having the sonic pulse bounce off of that surface where the marker is mounted and then transmit that distance to the other bots in the pack via bluetooth, wifi, etc.
This reminded me of this paper:
http://maple.cs.umbc.edu/~don/projects/swarmrobotics.pdf
There should be more interesting material on “Swarm robotics”
2 Likes
@ Architect - Very interesting paper - thanks for the link
Indeed! BTW, not sure if you can disclose, but can you tell us if your “swarm” will be terrestrial, airborne or surface/sub-marine?