|
From: brian g. <bg...@us...> - 2003-03-11 18:15:43
|
hi everybody,
The message below is part of a conversation between myself, Chris Reardon=
at
UTK, and Esben Ostergaard at the University of Southern Denmark, who wrot=
e the
original audio device (now called the 'fixedtones' driver).
I'm posting this message to the list, because Esben relates some of his
experience using sound as a medium to do environment-embedded detection o=
f
interesting phenomena, which others might find useful.
brian.
---------- Forwarded message ----------
Date: Tue, 11 Mar 2003 10:05:23 +0100
From: "[ISO-8859-1] Esben =D8stergaard" <es...@mi...>
I did the work on fitting the Pioneer robots with sound hardware and
interfacing to it through Player around two years ago. I wrote the two pa=
pers
"Multi-robot Task Allocation in the Light of Uncertainty"
"Distributed Multi-Robot Task Allocation for Emergency Handling"
These papers are not directly about the sound stuff, but are using the so=
und
setup to do experiments. However, the point of the papers was exactly tha=
t
robots sensing of the environements is often very unreliable, so for my p=
urpose
it didn't matter that the sound was very unreliable.
Having said that, I really do think that sound has potential for being us=
ed for
all sorts of things. You should just notice a few things about sound:
Sound bounces of a lot on large flat surfaces (floor, wall, desk, etc.) T=
here
is always background noise The recieved amplitude of a transmitted freque=
ncy
from a speakers to a microphones (especially cheap ones) varies with resp=
ect to
frequencies and relative positions and orientations. At 5000 Hz (example=
) the
wavelength should be about 6 cm, which causes for all sorts of interefere=
nce
fenomena.
In big open environments, the recieved amplitude should drop as 1/r^2. In
hallways it's more like 1/r.
I found that using frequencies that were not in the background noise spec=
trum,
I could use amplitudes that were so low that they weren't really annoying=
, and
still have robots detecting it from 10-15 meters distance.
On Mon, 10 Mar 2003, Chris Reardon wrote:
>> The tone detection kinda works. It detects the right freqency fine
>> (although I've noticed that the freq detected seems to be exactly 4x t=
he
>> frequency the outputting ipaq is given in PlayTones, but no bother) wi=
thin
>> about =B1 100.
My fault.
>>
>> The amplitude detected, however, doesn't seem to be consistent at all.=
I was
>> hoping that if I could increse the length of the sound, it'd balance o=
ut.
>> Even taking an average on the correct frequency fluctuates wildly.
>
You should probably increase the length of the sound (as Brian also write=
s).
The FFT algorithm transforms a small sample window (probably around 1 sec=
or
1/10 sec). If the sound turns on or off during that period, the reported
amplitude will be lower.
> It
>> puts me in a real quandry because I've been working under the assumpti=
on
>> that the volume of the sound that the ipaq detects will equate with th=
e
>> (relative) range of the sound.
>
That depends a lot on interference in the enviornment. If the robot is at=
the
end of a corridor, the percieved amplitude might be higher because of sou=
nd
bouncing off the wall at the end, and possible making positive interefenc=
e.
>If I can't get that volume (amplitude) data > to even out, it's not goin=
g to be very useful to me.
>
If the sample window is made longer, the amplitude data should get smooth=
er.
>>
>> I'm looking at fixedtones.cc, but I'm not a good driver person - is th=
ere
>> anything in there that I can easily change that will make the sound pl=
ay
>> longer? (say for 5 secs maybe?)
>
When I did my experiments, the sound played much longer than that, so it
should be possible.
>Would I need to do anything after > editing fixedtones to make the chang=
es take effect?
>>
>
>
> hi Chris,
>
>I suspect that making the tone play longer will solve the amplitude prob=
lem,
>because the driver was originally used, quite successfully, to detect,
>localize, and estimate distance to multiple sound sources for the purpos=
es of
>task allocation.
>
>I'm copying this mail to the author of the fixedtones driver, Esben
>Ostergaard. Maybe he has some advice on how the tone-generating code
>works and/or how best to modify it. hi Esben; any ideas?
I really cant remember the code very well. I wrote it during a few days, =
over two years ago. It has probably been changed a few times sice, due to=
the evolution of Player and Stage.
>
>In the meantime, I recommend that you test with desktop PC hardware, to =
see if
>you get different/better results. That might help us figure out what ch=
anges
>are necessary to get you going on the iPAQ.
>
> brian.
brian gerkey wrote:
>On Mon, 10 Mar 2003, Chris Reardon wrote:
>
>
>
>>Do you mind if I ask who did the localization etc. with this driver, wh=
at
>>hardware that was on (ipaq?) and if they wrote a paper on it?
>>
>>
>>
>
>sure. it was Esben, and he used a Pioneer 2-DX, which contains an Ampro
>Littleboard embedded computer outfitted with a PC104 sound card. he's w=
ritten
>at least two papers using that audio device:
>
> "Multi-robot Task Allocation in the Light of Uncertainty"
> "Distributed Multi-Robot Task Allocation for Emergency Handling"
>
>you can find them on his publications page:
>
> http://www.mip.sdu.dk/~esben/publications/
>
>
> brian.
>
>
>
|