Re: Ultrasonic sensor interactions

I've heard of one possible answer, though don't know if it is feasible on
the NXT. If the robot software sends timed pings, regardless of time of
flight, they will be returned with the same delay between them. So if
you send two pings 73 msecs apart, but recieve three you only want
to listen to the two that are 73 msecs apart. That is not a perfect way,
and is susceptible to error, but averaging multiple readings will help
to overcome this. So a pattern of pings, say two that are 73 msecs apart
then two that are 100 mseconds apart, repeat... should be able to 
delineate the desired signal from trash. It does slow down the speed
at which accurate readings can be taken, but if this is a back up 
strategy for when interference is detected, it seems a workable method.
It also works better if you are able to senses the signal levels of the
return echoes. 

Accurate wheel encoders to account for movement might also help
to mitigate time of flight differences in the timed pings while moving
quickly in one direction.

Just a thought

----- Original Message ----
From: Brian Davis <[email protected]>
To: [email protected]
Sent: Sunday, May 21, 2006 9:42:49 AM
Subject: Re: Ultrasonic sensor interactions

In lugnet.robotics, steve <[email protected]> wrote:

> 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.

   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 number of months. That's *nothing* compared to what's going to happen
later this year.
   Specificly, I can not find a way to turn off the US sensor from the
LEGO-provided SW environment. There may very well be some functionality at a
lower level I don't have access to (at the moment), or LEGO themselves may do
something about this (after all, for FLL it will be an issue).

> 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.

   I don't think this is a solution for all (or even many) situations. If you
are working in a "toy" world (one where the environment is very well controled),
you may have a point. But I've used IR pinging ("lidar") in LEGO sumo where
speed was of the essence: if my robot couldn't locate and track a rapidly-moving
robot, it was worthless. Likewise for tracking "normal" objects (people moving
around the robot) speed is going to be important.

> 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.

   I suspect detecting a "corrupted" signal is going to be tricky at best. As
John mentioned, the US pings are not coded, so you don't know if you are
listening to the echo of your pulse or the echo of another robots pulse. Theonly
headway I've made on this is with two NXT US sensors operating in the
environment, you can almost always say the object is not *closer* than the
return (in other words, you can (& do!) have lots of "false positives" due to
recieving somebody elses ping - but you *almost* never have a "false negative"
where your sensor doesn't see an object that really is there). I'm sure you can
get farther with some analysis if the objects in the environment aren't moving,
but I've been trying (playing) with other things.

> If the sensor actually pings 10 times a second...

   I've not been able to exactly measure how fast the US sensor pings, but from
simply (trying!) to count the barely audiable pings it seems around 10/second.
But another interesting fact comes up when I do that - I can hear variation in
the ping rate. So *something* within the sensor or firmware (not the SW) can
alter the ping rate - I just don't have control over it from a SW level (yet).
Note BTW that you can sample the US sensor every 0.4 ms or so, but what you get
is the same range repeatedly, until (presumably) the US sensor updates that
value with a new valid reading. In other words it seems you can poll the sensor
far faster than the sensor can currently generate new ranges.

> Without a positive answer to that one, I don't see how we can
> use ultrasound in a multi-robot setting.

   See the false positive vs. false negative description above. And let's wait
until we can access stuff at a lower level. AND I can't wait to see what the
community as a whole can do with this.

-- 
Brian Davis