DPRG List  

Fw: Fw: DPRG: Re: Audio

Subject: Fw: Fw: DPRG: Re: Audio
From: Ron Blue rcb5 at msn.com
Date: Sat Jan 3 02:42:03 CST 1998

- -----Original Message-----
>From: Gabe Velez <gvelez at richmond.infi.net>
To: Ron Blue <rcb5 at msn.com>
Date: Saturday, January 03, 1998 1:37 AM
Subject: Re: Fw: DPRG: Re: Audio

>> >Here are some ideas about how to home in on sound.
>> >It appears that you are on the right track.
>> >
>> >1. The microphones should be of cardioid pattern (narrow beam) and
>> >should be aimed up (on a short robot) and forwards.
Why? Our ears arent. Neither are any animals'. I don't think anyway. A
cardioid mic uses phased info to make it directional. It requres sound
info to be introduced from behind the mic. Our ears have only one main
entrance for sound. The others are for resonance (the tubes connecting
the sinuses and ear, and eyes and sinuses, et al.)
>> >2. Cause the "head" to scan back and forth "pseudo-randomly".
>> >2a.  Or don't scan just wait for a sound.
    The head might be controlled by the sound as you seem to imply, but
it shouldn't need to scan. Unless the purpose is to seek some sonic
>> >3. When a mic picks up a sound immediately cause the head to turn in
>> >that direction.
>> >4. When the other mic picks up a sound then cause the head to reverse
>> to
>> >turn in that direction.
>> >5. Eventually the head will search less and less until the target is
>> >homed.
    This is indicative of digital sampling. For example, My car has a
digital computer to control emissions, rpm, and cruise control. When I
select the cruise control at the desired frequency and remove my foot
>from the accelerator, the car slows down, then speeds up, then slows down
less, then speeds up less, until it reaches the desired speed (on level
ground). I also had an older car which had an *analog* computer. When I
turned on the cruise control, it stayed rock steady on the desire speed!
What gives??? I though digital was more accurate??
    Point is, in an analog world, analog devices don't need to scan to
be accurate. Our eyes don't scan like a tv, or digitize an image. Our
ears don't sample like a CD. Therefore, if it hears a sound from one
direction, it will turn its head in that direction. It will move toward
the general area until the sound happens again and correct its motion
accordingly, since now its "ears" are basically pointing the same
direction. Forward. The *intensity* of the sound is what will make the
unit find exactly which direction the source is. Adding D/A circuitry,
while impressive, isn't really necessary, when a comparator will do.
>> >6. The mic signals are fed into schmidt triggers or comparators with
>> >rectification and low passed.  Set the comparators for a particular
>> >threshold.
    I think the motion circuit should be set for the threshold.
>> >6a. A cool way to establish a quick form of "pseudo-fuzzy-logic"
>> >performance is to feed the signals into the LM3914 Bar-Dot display
>> >driver chip in dot mode to give an amplitude output.  Use each output
>> to
>> >provide a different speed form the head motor. (I can provide more
>> >simple details on this method.)  A PIC chip would make this easier.
    Although an analog buffer could do.
>> >7. After a certain time of interrupted scanning (sound detection) or
>> a
>> >certain number or frequency of mic aquisitions or a certain minimum
>> time
>> >interval of scan reversals, you then cause the robot to turn to the
>> >aquired direction.  You might have the neck tied to a pot or other
>> >encoder to indicate head to body position, then work the robot toward
>> >the zero position by the shortest route.
    Good idea.
>> >I have a robot that follows in this manner.  It just uses the mic
>> >signals to momentarily stop the motor on the same side as the mic
>> until
>> >both mics balance.
>> >
>> >> >       I am using a BASIC compiler to program the PIC 16F84-4P as
>> the
>> >> basis
>> >> >for my robotics stuff. I am working on a project in which I want
>> to
>> >> have
>> >> >the robot head turn in the direction of a sound. (Or two eyes with
>> a
>> >> >connecting rod... just one axis)
>> >> >
>> >> >       My thinking is to have two microphones, one per side of the
>> >> head. If no
>> >> >noise is detected, the head will follow a pre-programmed
>> >> "psudo-random"
>> >> >look around mode. If on the other hand one microphone detects more
>> >> noise
>> >> >than the other, the head will tend to turn in that direction until
>> >> the
>> >> >noise is equal from both "ears".
>> >> >
>> >> >       It would be nice if... the robot could tell the difference
>> >> between a
>> >> >soft and a loud noise. I.E. Someone says, "Hello." the robot sorta
>> >> looks
>> >> >in their direction... but if someone yells, the robot looks that
>> way
>> >> >with max speed.
>> >> >
>> >> >       I can take the microphones and run them to an OP-AMP, no
>> >> problem. I can
>> >> >then run the signal to a schmidt triger or other device to turn it
>> >> into
>> >> >an ON/OFF, or use A/D sensors to read the two signals.
>> >> >
>> >> >       Any suggestions on how to go about this project???
Well, I would be giving Little Ricci 2 away if I did.



More information about the DPRG mailing list