Subject:
|
Re: Ultrasonic sensor interactions
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 21 May 2006 12:30:19 GMT
|
Original-From:
|
steve <SJBAKER1@AIRMAIL.saynotospamNET>
|
Viewed:
|
2598 times
|
| |
|
|
Arthur Clarke wrote:
> When an Ethernet interface wishes to transmit a packet, it first listens to see
> if the “Ether” is in use. If it is, it continues to listen until the “Ether” is
> quiet. If the “Ether” is not in use it transmits the packet but listens to see
> if the packet is corrupted by a “collision” with a another packet from a
> different interface that has started to transmit at the same time. If there is a
> collision, it waits for a randomly selected interval and then repeats the whole
> procedure until the packet is transmitted successfully. All packets are
> transmitted in full weather or not a collision occurs to ensure that all senders
> detect collisions. In this environment “collisions” are a normal part of
> network operation. This is called “carrier sense multiple access with collision
> detection” (CSMA/CD).
The 'Aloha' protocol was the predecessor of this.
> I wonder is the characteristics of the ultrasonic sensor might permit something
> similar. It must be able to listen to see if the “Ether” (the air) is quiet, but
> could it detect “collisions”?
Someone earlier told us that the thing runs all the time and can't even
be shut off.
That being the case, I think we're pretty much doomed.
> If this is possible, the next problem concerns the
> relatively low bandwidth of the ultrasonic channel compared to even the slowest
> Ethernet.
Yes - but the relatively low frequency at which you need data from it
compensates for that.
Robots don't move very fast - and they can (in principle) deliberately
slow down when they detect too much ultrasound 'traffic' to get frequent
readings.
> It might be that, in order to avoid deadlock, the collision back-off
> times would need to be quite long, e.g. several seconds. If this is the case,
> the rate at which an individual robot could sample its ultrasonic sensor data
> might be too low to be useful for navigation purposes.
Except that you only have this problem when you detect a corrupted
transmission. Most of the time, you can just use the detector
continually - only turning on this additional complexity when a
corrupted transmission is detected.
That would mean that when two robots get close, your detection
rate would get worse - so you'd maybe have to slow your movement
rate down to compensate. That's not so terrible.
However, it's beginning to look like we may lack the low level
control of the ultrasound unit - so this entire discussion may
be moot. If the ultrasound hardware simply does it's own thing
and returns a simple range number - then we're screwed.
If software can control when it emits a ping and gets some kind
of a signal when it detects incoming ultrasound - then we can use
the Aloha protocol (or some simple variation of it) to solve the
problem without scheduling.
Ultrasound travels at about 350 meters per second. If it's
detectable range is (say) 3.5 meters then we only need (theoretically)
1/50th of a second to emit a ping and get the echo back at
maximum range. The actual duration of the ultrasound ping should
be very short - the sound frequency should be up in the 100kHz to
MHz range so a very brief pulse is enough.
If the sensors were to 'ping' once a second and ignore ultrasound that
comes in later then 1/50th of a second then the chances of
two robots confusing each other would be around 1 in 50. That's
enough to be a major problem. If the sensor actually pings 10
times a second - then the odds go up to 1 in 5 and if the sensor
emits a new ping as soon as the last one arrives - then two robots
will be 100% guaranteed to confuse each other if they are in range.
Also, once they get confused - because any low level mechanism to
determine the ping interval is the same in both robots - they'll
tend to stay confused until one of them moves a significant
distance.
Without some kind of scheduling - this could be a major problem.
So - the big question is: "Can we shut the darned thing off
or not?"
Without a positive answer to that one, I don't see how we can
use ultrasound in a multi-robot setting.
|
|
Message has 2 Replies:
 | | Re: Ultrasonic sensor interactions
|
| (...) The device operates at 40kHz, the transmit and receive piezo devices are only resonant at that frequency. Even though the measurement period is short (time from transmit to time to receive) it is necessary to wait quite a while for the sound (...) (18 years ago, 21-May-06, to lugnet.robotics)
| | | Re: Ultrasonic sensor interactions
|
| (...) I was the one that mentioned that I couldn't find a way from the SW I have to turn the US sensor off. That said, I don't think it's time yet to worry about intractable problems: A hundred of us or so have been playing with this stuff for a (...) (18 years ago, 21-May-06, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Ultrasonic sensor interactions
|
| The problem here is the management of a single shared resource, i.e. the air through which the ultrasonic signals travel. The lack of a Bluetooth broadcast mechanism makes the implementation of a conventional resource locking system difficult, but (...) (18 years ago, 21-May-06, to lugnet.robotics, FTX)
|
27 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
