I just want to share with you all my project. This is a pic of my spaghetti bowl breadboard prototype circuit. In the picture, it is only a one mic setup for simplicity and trouble shooting. I am in the process of working on the code to take atvantage of this device.
Circuit pasta:
http://img210.imageshack.us/img210/9858/stampaudio3fb.jpg
The final Schematic:
http://img434.imageshack.us/img434/1992/stampaudiosch5qf.gif
[size=150]Project Update:[/size]
I have been experimenting with the code to try to obtain the best results. I have come very close to my goal. Today I tested new code that has a setting for sensitivity. This code allows me to adjust at what level (loudness) to respond to, and it was very successful! I can set the software to ignore sounds below a certain level which will be very useful to keep it from constantly trying to respond to every little pin drop.
I still need to get a larger resistor to increase the gain and a smaller cap to improve the speed at which it responds to sound. Larger value caps slow the performance to much. I also need to lower the op amp voltage ref input. With these three things, I expect results beyond my expectations. Right now the circuit, “as is”, will do the job I originally had in mind, but I feel there is room for improvement so I will continue the tweaking stage.
As I’ve said before, Mike, this all looks rather interesting.
Keep us up to date, and let us know if we can help!
Oh, btw, what are the values of the resistor and capacitor that you need?
I have an array of them that I’m not using, and I can send you the ones you need, if you’d like.
Just a quick update:
I tried a new version of the program I am developing to drive a servo when the mic hears a sound above a certain loudness level to see what would happen.
The Results?
I consider it a success since the servo did move in response to the mic’s output level. In fact, I programmed it to hold the servo as long as the sound remains above a certain loudness level, and center the servo when the loudness falls below the threshold set in the program. After watching it respond to my tapping an empty coke can on the desk, it was neat to see it look in the direction of the sound, as if I called its attention, only to look away after I stopped making my racket.
Anyway, I know I have been slow with the progress but I am in tight times right now with my kids being in daycare. I hope to have more accomplished this summer.
Lol!
You haven’t been slow, Mike.
You’ve been working on this for – what, a month?
And, you already have a successful prototype…
That’s fast, Mike.
Just a thought…
If you’d like to make it a bit more realistic, you might want to try having the servo hold the sound-targeted position for a couple of seconds.
That way, it’ll look like your bot is staring at it and thinking about it.
You could even throw something in like…
If he recieves a sound in the same position twice, have him go back to center after looking at the sound for a few seconds, and then having him quickly turn back to the previous position.
That way, it’d look like he was trying to “catch” whatever was making the sound, in doing it again.
Damn, I envy you, Mike…
I need a cool project to work on, too!
Thanks for the kind words Nick!
As my code is now, when the servo moves to the sound source, it does “stare” at the source for a few seconds. I did not intentionally program this delay in, it is just how the code works with moving the servo. Because the servo requires 20ms to move, that is time the ADC is not taking any readings of the audio input. After the servo moves, it takes a few seconds for the ADC values to settle back down allowing the servo to go back to center. I felt that this effect was cool, so I left it as is.
I am reading how FSM (Finite State Machine) works so that I can have multiple sensors read at the same time. With FSM, the servo does not need the 20ms pause command relieving the bottleneck. With out using FSM, programs run in a linear fashion, meaning the code runs one after the other and can not proceed until a particular sequence is complete. With FSM, you are able to run multiple sequences at virtually the same time (multitasking).
Hey Robo gurus!
I broke down and payed to have my audio sensor board made. I went a head and used my allocated gas money to pay for it! 
Just kidding, I will manage.
It will probably take 19 days before I get it. As soon as I get it, I will post pictures.
Aww…
Well, at least you’ll get it before the Humanoid’s waist rotation kit comes out.
Just kidding.
I ordered 25 copies of my board design, and today they are in the process of being plated. They should be shipped tomorrow the 9th. The boards have 2 day shipping, so I don’t know if they will get to my house Friday, Sat, or Monday?
Originally the sales rep said I could get 200 copies of my board using their first time customer special deal, but there was some misunderstanding on my part. I had to re-submit my design but this allowed me to make some quick changes to the design. I fixed the silk screen for a few components that had the wrong value, and I also added connectors for all the input/output wires. This way I have the option of soldering the wires directly to the pads, or solder a connector to the board and then wire a female connector to the mic elements as well as the stamp input/output lines.
I am excited about this first PCB project and I will post images of the board when they come in.
Here is the Gerber image of the board I submitted:
http://img140.imageshack.us/img140/8963/audioboardrevab1mt.png
Boards are being shipped today. I will expect them to come in this Monday.
the boards are completed and are on the UPS truck. YeeeHaaawww!
SN96 -
I noticed you wanted the bot to speak. Have you approached that perplexing concept yet? I can tell you that some time ago I made a program in Visual Basic that will speak any thing you type into it. It was able to serf the internet for your horoscope or current temperature and speaks it to me. I also programmed a speech to command type interface. You can speak into the microphone and it would execute different codes like internet explorer, or I would say “play mp3†and it would play music. I am curious as to how and what you’re going to use for the skull to speak. Can you feel us in
Good job so far and I heard that about the kid daycare! Stuff gets spendy!
Nice work, Mike.
I think we’re almost as excited as you are.
Hello Flood,
I was going to mount a 36mm Mylar speaker to the bottom of the Skull chassis. I was then going to use an off the shelf electronic text-to-speech module that would wire up to the microcontroller and speaker. I experimented with adding a connector to the audio board to allow for a simple plug-in solution, but I was not happy with the design. Speach is something I will do later on down the road. My primary focus was the audio sensor.
Voice reconition was an idea that crossed my mind, but I want to take things in steps.
Sn96
If you like I can make a simple speech program and send it to you. This would work if you used your pc microphone output into a speaker/ amp circuit in the skull. You would have to be using Windows however because I am using Visual Basic. Or if you like I can teach you how to make it in Visual Basic; although I do understand if you want to tackle it on your own. I kind of figure it is great to learn things on your own and get the ole hands dirty.
For any one else that needs help in Visual Basic I am fairly experienced and don’t mind at all helping. It is very simple to use VB to control a bot through any port
Sounds interesting Flood. I might take you up on that offer since I really don’t want to mess with VB.
As for a VB speech program, I want to make my bot teather free, but then again, I might decide to do something new later on. Could one use wirless serial communication with no problems?
It’s nice to know we have members on this forum with many different skills. We can all help each other out with virtually any area of interest.
I forgot to post this image in the first reply. This image shows the mylar speaker that the skull was designed to use:
Wireless communication is no problem with most .NET languages.
You’ll need to decide exactly which module you’ll use (if you’re just using it for speech, I’d say bluetooth, but if you want a broader range of control options, I’d say the WiPort.)
Andy has already written C# code for the WiPort, and many other wireless devices, and it worked well, as far as I know.
I’ll be writing in Visual Basic Express for the WiPort, when I finally get my biped (cough, hurry up, Jim, cough).
I know that network streams, serial communication, etc. was all blocked from the nice and simple MS-DOS QBasic by Windows XP.
But, Visual Basic 2005 has the .NET framework, which allows for such communications.
Hey Nick,
You can develop the wireless communication technology and then when you’re done, I can use it for my bot.
This does sound like a good idea! One can harness the computing power of the PC and make their bot more advanced. One idea I had spinning in my head was to mount 2 color micro cameras in each eye socket of the sensor skull, and have stereo vision. Problem is, I don’t know anything about how to utilize the image data of two cameras, or if the video signal can be transmitted via wireless devices.
Hmmm…
I can’t be sure, either.
But, anything that can transmitted via DB9 serial cable should also be able to be transmitted via the WiPort.
As to using the code that I generate, your welcome to it, as is anyone else who would like it.
But, don’t expect anything any time soon, as I’m learning as I go.
Plus, there’s the whole issue of not having a bot, yet.
I believe that I’ll be using the WiPort as a supliment to the Botboard + Basic Stamp 2px.
The problem with (I can’t think of the word… tele-something) remote brains is the latency of the wireless module.
So, I’m going to have the positions stored on the Stamp and have the Stamp control the balance feedback from the pressure sensors.
I’ll be using the WiPort to tell the Stamp where to move the bot to, as well as to keep an eye on the overall sensor status.
That way, the info going back and forth over the WiPort is minimized.
I’m not sure how slow streaming two color vids over that connection would be, but it might end up being a problem.
I think that it would be better to use a setup like the Robosapien V2 has.
It looks like he’s got 3 seperate red, blue, and green cameras.
If the Robosapien’s microcontrollers are able to handle processing those images, then they should be small enough to stream easily.
If you’re going for stereo vision to judge depth, I’d say go with one color camera of some sort, and one rangefinder.
The rangefinder could be entirely handled by an onboard microcontroller, and then only one color camera would need to be streamed.
[size=150]The boards ARE IN![/size]
<>
I replaced all the images and made them smaller. This will help keep the forum from being so wide.
Topside: (Hi Res Camera Image)
http://img457.imageshack.us/img457/2664/abtop5fg.jpg
Bottomside: (Hi Res Digital Camera Image)
http://img149.imageshack.us/img149/116/abbottom7yn.jpg
Full Deck: (Hi Res Camera Image)
http://img149.imageshack.us/img149/1426/7boards505at.jpg
