Binaural Spike

I’ve had a lot of fun with Spike throughout the year and thought it would be neat to give Spike the ability to not only respond to loud noises, but also move (and if necessary, turn) towards the loudest noise.
I’m pretty fond of using pairs of sensors to give robots more sophisticated behaviour. For example, a soccer robot with two light sensors can keep track of where a ball is (and to which side it has been lost) much more effectively than a soccer robot with one light sensor.
The Roman philosopher Epictetus is usually credited for the saying, 'we have two ears and one mouth so that we can listen twice as much as we speak.' Maybe in the case of a Spike with two sound sensors this should be, 'we have two sound sensors and one stinger so that we can listen twice as much as we strike!'

Admittedly, the program is far more complicated than it needs to be, and doesn’t quite work 100% of the time. (By comparison, with a just a little help, my 5-year old son made a pretty decent program for Binaural Spike using NXT-G in about 10 minutes that works fine.)

Rob
PS: If you’re expecting to program Spike using the USB cable, I’ve found that it’s a lot easier to get to the USB port if you reverse the direction of the NXT compared to the direction indicated in LEGO’s building plans.
Comments
If you want your version of Spike to react on sound coming from different directions, you'll need to place the sound sensors in different directions as well. Try placing one sensor on the far front of Spike, and the other one on Spike's back. Make sure the sound sensors are facing away from each other.
Then, you can make a simple program that compares the sound levels of Sound Sensor 01 to the sound levels of Sound Sensor 02 and depending on which sensor is receiving highest volume of sound, Spike will either do a 180 degree turn or stay in place.
This can be even more fun if you'd have 4 sound sensors so you could place one at each angle to give your robot even better directional hearing.
Also, try setting low motor RPM speeds to avoid faulty readings from your sound system.
Good luck!
-Max
But from what I've seen of Spike, the motors - even without a high RPm - are situated in the back and would always tell spike to turn around. The end product would be a robot that spins in circles.
I would suggest giveing individual time to each party.
T
he sound sensors take a reading. The NXT compares the values (just like Max said) and turns the motors on accordingly.
Now, when the motors are on, the NXT is going to ignor the readings from the sound sensors. When they are off, it can take another reading.
The Ultrasonic sensor is always on, but its loop is set to false. When it sees something in front of it, it will be set to true and interupt any loops going on at that time.
Max, I think having the sensors pointing forward and back would make it easier to discriminate between them, but I'd much rather have a behaviour that would allow Spike to zero in on a sound source... so that he can attack it! As a teacher, I can think of many occasions where that would've been handy... (-:
It would be fun to work with more sound sensors, but I've only got access to two at present.
Maniac, I like the idea of simply having Spike disregard the sound sensors while he's moving. I was so obsessed with having Spike move smoothly towards the target, that I completly overlooked this possibility... d'oh!
Incidentally, my RobotC program for Binaural Spike is now available from...
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=217058
You could use Styro or something to isolate the motors but i like the ON/OFF change in behavior.
A little more complexity could allow the mics to CHANGE threshold when the motors are on or off. Thus it could still track a little bit when motors are running. You could even make the threshold a mathematical relation to the strength of the 2 motors (a low power motor has a lesser threshold and better accuracy while a higher motor power would blind it self more but only as much as needed)
That would of course only be needed if motor speeds varried. You could use trial and error to perfect a program which turns MORE or faster when the difference between the sensors are the larger.