Go Down

Topic: Sensor types (ultrasound, infrared, etc) for proximity awareness system? (Read 1 time) previous topic - next topic

bkellish

Our high school design team is designing a proximity awareness system (a belt that takes distance measurements from several sensors, and activates vibration motors in the direction of the object). The vibe motors should increase/decrease intensity as the obstacle gets nearer/farther. The main application would be to help blind people navigate in unfamiliar rooms.

What type of sensors should we be using? Infrared, ultrasonic, etc or a combination? There will be 3-5 sensors mounted on a belt, for 360 degree coverage. We're worried about possible interference from having multiple sensors of the same type (ie. 2 ultrasonic sensors using the same frequency).

Any advice, insight, tips?

PaulS

Quote
We're worried about possible interference from having multiple sensors of the same type (ie. 2 ultrasonic sensors using the same frequency).

If the ultrasonic sensors are driven using NewPing, which uses interrupts to get the echo, that shouldn't be a problem. Turn one on, sending a pulse. Get the echo. Turn the sensor off. Repeat for the other one(s). You could poll a dozen of them, that way.

Quote
There will be 3-5 sensors mounted on a belt, for 360 degree coverage.

So the blind person can back into the room, instead of walking in?

PeterH

I wouldn't have thought that interference between the sensors was much of a problem (the duration of each ping would be very small and you can ensure that only one sensors operates at a time) but I'd be more concerned about picking up obstructions at knee/ankle level from sensors at waist level. Perhaps you aren't trying to do that - what sort of obstacles do you envisage this device picking up?
I only provide help via the forum - please do not contact me for private consultancy.

holmes4

3 or 5 sensors way be to far to few. Get hold of different types of sensors and set them up. Then move something from side to side in front of the sensor. Note when the sensor starts/stops registering.

Repeat at different ranges and plot the results.

Mark

AWOL

Quote
I wouldn't have thought that interference between the sensors was much of a problem (the duration of each ping would be very small and you can ensure that only one sensors operates at a time)

It's a very common problem, particularly with inexpensive sensors.
With US sensors, there's a trade-off between high update rate vs. the chance of getting echoes from distant objects.
The simple way of avoiding this is to wait longer between pings, but this reduces the update rate.
You may be lucky to get an aggregate update rate of only ten or fifteen updates per second.
One other way is limiting the sensitivity of the receiver.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

PeterH


It's a very common problem, particularly with inexpensive sensors.


I'm surprised to learn that. Doesn't the speed of sound mean that each ping is over within a few ms? (Or in other words - if you haven't received the echo by then, surely it's too faint to detect?)
I only provide help via the forum - please do not contact me for private consultancy.

AWOL

Pings are usually over in a couple of hundred microseconds - typical hobbyist sonars drive a burst of around eight cycles of 40kHz/25us. Transducer ringing may stretch this a few cycles.
However, for a range of say, 3 metres, the pulse has a round-trip time of getting on for 20 milliseconds (6 ÷ 340 = 17.6ms)
3 metres is quite a reasonable range for one of these cheap units, but what if you have a closer object, say 50cm?
A return is detected, and timing stops, after around 3ms (1 ÷ 340 = 2.9ms)
So, you might think it OK to start another timing, so transmit a new pulse.
However, that first pulse is still in flight, and may encounter an object beyond the first object.
The sonar has no way of knowing that the return it now detects is from the pulse it just sent, or is from the previous pulse.
The only reliable way is to wait long enough to ensure any pulses in flight are too weak to trigger the sonar, or controlling the gain of the receiver.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.



It's a very common problem, particularly with inexpensive sensors.


I'm surprised to learn that. Doesn't the speed of sound mean that each ping is over within a few ms? (Or in other words - if you haven't received the echo by then, surely it's too faint to detect?)


From my experience, you should wait about 29-35ms between pings to be sure you don't get a cross-sensor echo.  While you can ping faster, and it can work, it won't be as reliable in all situations.  The reason it's 29-35ms is due to the sensor distance and the speed of sound.  Most sensors put out a signal that can detect an echo up to about 500 cm.  500 * 57 = 28,500uS or about 29ms.  I like to give it a few more ms to make sure the echos are gone, so 35 is fairly safe.

If you do choose to do it with ultrasonic, I'd suggest using the NewPing library as you'll have problems doing several things at once with other ultrasonic libraries.

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Go Up