[Playerstage-users] information regarding 'fixedtones' driver

[brian g. <bg...@us...>]

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