The stepper driver you have needs the Stepper library. You have to combine the calls to the library with the code for the sound detection. So, instead of the two pins, you will need to make that two functions like step_direction() and step_move() that use the library calls to do what the program thinks the pins do.

It's really not too hard, but it may be daunting for a beginner. I will try to get a chance to make it work, ASAP.

Hi Ya’akov, I have managed to buy exactly the same sound detector modules used in the project, however, I could not find the stepper motor driver. So I am stuck with the one I have

 

Hi Ya’akov, I have managed to buy exactly the same sound detector modules used in the project, however, I could not find the stepper motor driver. So I am stuck with the one I have

Hey, I am still trying to find, literally, space to set up your circuit. I am in the process of moving my studio from one room to another, but let me explain something.

There are two types of these audio sensors often called 3-pin and 4-pin. The difference is the function of the extra pin. On the 3-pin you have \(\mathsf{V}_\mathsf{CC} \), GND, and DO. The DO is digital out. This goes high when the threshold set by the pot on the board is exceeded.

This doesn't help to localize the sound source since there is no relative strength. The fourth is AO, analog out. This is a relative output based on the strength of the sound detected. By comparing the two signals it is possible to tell when the microphones are equidistant to the source, effectively "facing" it (or directly away, but that's for another time).

So the way I hope, ultimately, to work this out is to use both. First, there will be a threshold detection that will use interrupts to signal that there is a sound sufficient to be reacted to but then use the analog output to find the actual sound.

I hope this is clear. The actual solution is really very simple. I'm sorry I haven't been able to make progress but I am working on it. Please don't hesitate to ping me here if you don't see anything. I might need reminding.

In the meantime maybe you can play with the Arduino and learn more. Particularly the Stepper library examples that use your driver board and stepper.

 

Hey, I am still trying to find, literally, space to set up your circuit. I am in the process of moving my studio from one room to another, but let me explain something.

There are two types of these audio sensors often called 3-pin and 4-pin. The difference is the function of the extra pin. On the 3-pin you have \(\mathsf{V}_\mathsf{CC} \), GND, and DO. The DO is digital out. This goes high when the threshold set by the pot on the board is exceeded.

This doesn't help to localize the sound source since there is no relative strength. The fourth is AO, analog out. This is a relative output based on the strength of the sound detected. By comparing the two signals it is possible to tell when the microphones are equidistant to the source, effectively "facing" it (or directly away, but that's for another time).

So the way I hope, ultimately, to work this out is to use both. First, there will be a threshold detection that will use interrupts to signal that there is a sound sufficient to be reacted to but then use the analog output to find the actual sound.

I hope this is clear. The actual solution is really very simple. I'm sorry I haven't been able to make progress but I am working on it. Please don't hesitate to ping me here if you don't see anything. I might need reminding.

In the meantime maybe you can play with the Arduino and learn more. Particularly the Stepper library examples that use your driver board and stepper.

I am working through the tutorial, really enjoying the little board

 

This might be too complex for your needs but it will give you some insight as to what is required.

ST Microelectronics had a demo application using one of its STM32 development boards. It pin-pointed the direction of the source of sound. The board had two MEMS microphones and it determined phase differences between the two mic signals. In order to accomplish this the signal from each microphone was digitized at high sampling rates.

The processing speed required to accomplish this is probably beyond the capabilities of an Arduino.

 

This might be too complex for your needs but it will give you some insight as to what is required.

ST Microelectronics had a demo application using one of its STM32 development boards. It pin-pointed the direction of the source of sound. The board had two MEM microphones and it determined phase differences between the two mic signals. In order to accomplish this the signal from each microphone was digitized at high sampling rates.

The processing speed required to accomplish this is probably beyond the capabilities of an Arduino.

It's idea because the method I plan to use will require considerably more integration time. But not to overstate it, for this application that won't be a problem to work around by doing some approximations.

 

It's idea because the method I plan to use will require considerably more integration time. But not to overstate it, for this application that won't be a problem to work around by doing some approximations.

I will be very happy if Damian the Dalek turns in the aprox direction of someone shouting at it!. The bigger question.. can the Arduino fire the Dalek's gun if the shout is abusive
Seriously, according to the Dalek builders forums, no one has ever made their "eye" follow noise! so Damian will be (could be) a world first

 

I will be very happy if Damian the Dalek turns in the aprox direction of someone shouting at it!. The bigger question.. can the Arduino fire the Dalek's gun if the shout is abusive
Seriously, according to the Dalek builders forums, no one has ever made their "eye" follow noise! so Damian will be (could be) a world first

Given he intrinsic hostile nature of the Dalek , any shout would be presumed to be hostile. Issue resolved!

 

Given he intrinsic hostile nature of the Dalek , any shout would be presumed to be hostile. Issue resolved!

having spent the day sanding and preparing its body for paint, i agree! !

 

It's idea because the method I plan to use will require considerably more integration time. But not to overstate it, for this application that won't be a problem to work around by doing some approximations.

Hi Ya’akov
Have you had any luck? Damian is wanting his ears

 

Hi Ya’akov
Have you had any luck? Damian is wanting his ears

Hey, looking good–really making progress.

I have been very tied up with family (it‘s the Chanuka holiday) but most of the activity is done so there is a good chance I will have some time tomorrow. I did collect the servo and controller and the sound modules together.

Check in tomorrow, I hope to have news.

 

Hey, looking good–really making progress.

I have been very tied up with family (it‘s the Chanuka holiday) but most of the activity is done so there is a good chance I will have some time tomorrow. I did collect the servo and controller and the sound modules together.

Check in tomorrow, I hope to have news.

Hi Ya’akov
Checking in to see if you had any luck with the Dalek project?
I’ve

 

Hey, Nick. Small progress. I hate to keep you hanging but here in the US Midwest we are suddenly dealing with…

​

It is currently -7℉ (-22℃) with 12MPH winds and guests of 25mph. I’m inside and safe, but it required us to prepare for at least the next 3 days (food, etc.) over the last two. We have our son and his family with us and we are well snowed in.

Things should settle out over the next day or so and I can concentrate on this. I feel badly about taking so long—but I do have a Seeed Studio XIAO (an really great little board, by the way) along with the stepper controller and a couple of sound sensors on a breadboard and the stepper library is operating. So I have done something however weak. The challenge is concentrating on writing some clean code with the current situation. Please don‘t give up, though.

The Dalek is looking good, but is it about to exterminate that nice roadster? It would be a shame. It might also disrupt your workshop a bit.

 

Here in the Detroit Michigan area it is currently (9AM FRiday) about 16 degrees F and a "serious 25 MPH Breeze" and some snow coming down, promising to continue falling. The roads were icy but the salt trucks delivering about a ton of salt per mile we are covered with corrosives that tend to melt the stuff until it gets a bit colder.
(addition now at 3 PM it is 5 degrees

 

The qr

Hey, Nick. Small progress. I hate to keep you hanging but here in the US Midwest we are suddenly dealing with…

View attachment 283693​

It is currently -7℉ (-22℃) with 12MPH winds and guests of 25mph. I’m inside and safe, but it required us to prepare for at least the next 3 days (food, etc.) over the last two. We have our son and his family with us and we are well snowed in.

Things should settle out over the next day or so and I can concentrate on this. I feel badly about taking so long—but I do have a Seeed Studio XIAO (an really great little board, by the way) along with the stepper controller and a couple of sound sensors on a breadboard and the stepper library is operating. So I have done something however weak. The challenge is concentrating on writing some clean code with the current situation. Please don‘t give up, though.

The Dalek is looking good, but is it about to exterminate that nice roadster? It would be a shame. It might also disrupt your workshop a bit.

Hi Ya’akov
I have been following the terrible weather back here in the UK, looks horrendous!
Take care, we complain at -1 and the Uk grinds to a halt.
i Will catchup with you in the new year
Stay safe and happy holidays

 

The qr

Hi Ya’akov
I have been following the terrible weather back here in the UK, looks horrendous!
Take care, we complain at -1 and the Uk grinds to a halt.
i Will catchup with you in the new year
Stay safe and happy holidays

Thanks for the understanding. The delay is embarrassing so your tolerance is greatly appreciated.

 

@nicktruman:

tl;dr: I have the hardware bits sorted and found what seems the best servo library (easiest to use). Now I need to incorporate the sound sensors and work out what the problems are. I know of some challenges and have plans to deal with them, but what else will pop up is anyone's guess.​

​

Even though the things I mention in the text below are extensive and sophisticated, the plan is incremental release. I will get you the basic function as soon as practical, then add refinements. That way you can get started on your end. We will need to identify the appropriately sized stepper, etc. But things can progress incrementally so long as we start with a good platform to build on. I hope and expect that the hardware will stabilize quickly and the rest will be software updates.​

​

In any case, I am committed to delivering something working and documented sufficiently that others can take it forward if they'd like.​

I've got the Dalek sound sensor prototype hardware together and it's all set for some code.

I've identified what is probably the easiest library to deal with, and confirmed it has decent long term stability. Even open loop it is returning to the calibration point consistently, as you can see below. I am very happy with it and don't expect to need a position sensor (though there will be some sort of calibration required since all the moves are relative. This could be done with a simple switch a the 0° rotation point, we can worry about that later, though).​

The test rig running a positioning loop.​

Now I have to work out out to use the sound sensors effectively.

They have an adjustable digital threshold output and an analog level output. The plan at this point is to use the threshold as a sort of squelch to fire an interrupt when there is a detection, then use the level out to compare the two sensors and rotate in the direction of the higher one.​

There are some challenges.

One is integration time. If the sound is short, it won't have time to swing to equalization. So, I am going to work out some approximation mechanism. If the sound stops while trying to find the null, it will "guess" based on the last readings.​

​

Another is the likelihood there will be "ringing" due to overshoot as it tries to null. I might be in inclined to try a PID approach to control that, which might provide other advantages as well, but I also have a couple of simpler ideas to fix it if it indeed occurs.​

Another challenge is self noise. I added the green LEDs on the sensors and they are currently just lighting when the DO of the sensor is high. The indications you see are from the noise caused by the motion itself. So I am thinking I might have to write some code to ignore the detections that occur when the arm is moving and pause it for a quick reading at intervals.​

Hopefully, I can get the reading without the motion looking to jumpy. I also thought about initiating the motion based on sound but switching to radar to find the source. That might be fun to work out, and I think it could work well.​

In any case the approach will be incremental release.

I will get basic functionality working so you can start implementing it on his end, then add refinements.​

 

Considering that initially the direction that the sound is arriving from should deliver the first trigger, that could serve to initiate the first bit of motion while the software is deciding the exact direction based on the difference in amplitudes.
If the two channels have identical response times for a given amplitude, then possibly the amount of delay could even be measured and serve to determine the amount of rotation. It would require a fast time counter triggered by the first detection signal and latched by the second signal. So it would not experience the A/D converter delay.

 

Considering that initially the direction that the sound is arriving from should deliver the first trigger, that could serve to initiate the first bit of motion while the software is deciding the exact direction based on the difference in amplitudes.
If the two channels have identical response times for a given amplitude, then possibly the amount of delay could even be measured and serve to determine the amount of rotation. It would require a fast time counter triggered by the first detection signal and latched by the second signal. So it would not experience the A/D converter delay.

I considered ToF (Time of Flight) but I don‘t believe i am make the sensors reliable enough for that. I can try an experiment and see if the sensitivity differences are a problem.

I haven’t had a chance to characterize the sensors fully, but I am going to at least generate a quick and dirty response curve and also see if the 10-turn trimmers are needed to balance or if fixed resistors act the same in every board. If there isn‘t a need for the trimmers to make a match, I might replace them with fixed resistors for reliability.

 

I considered ToF (Time of Flight) but I don‘t believe i am make the sensors reliable enough for that. I can try an experiment and see if the sensitivity differences are a problem.

I haven’t had a chance to characterize the sensors fully, but I am going to at least generate a quick and dirty response curve and also see if the 10-turn trimmers are needed to balance or if fixed resistors act the same in every board. If there isn‘t a need for the trimmers to make a match, I might replace them with fixed resistors for reliability.

Time of flight would be a lot more complex than determining which sensor triggered first. Time between triggers would determine the offset distance from straight ahead.(maybe) but could serve to determine the distance to swivel. That will be much simpler thatn time of flight, and not as accurate. But simple.

 

@nicktruman:

tl;dr: I have the hardware bits sorted and found what seems the best servo library (easiest to use). Now I need to incorporate the sound sensors and work out what the problems are. I know of some challenges and have plans to deal with them, but what else will pop up is anyone's guess.​

​

Even though the things I mention in the text below are extensive and sophisticated, the plan is incremental release. I will get you the basic function as soon as practical, then add refinements. That way you can get started on your end. We will need to identify the appropriately sized stepper, etc. But things can progress incrementally so long as we start with a good platform to build on. I hope and expect that the hardware will stabilize quickly and the rest will be software updates.​

​

In any case, I am committed to delivering something working and documented sufficiently that others can take it forward if they'd like.​

I've got the Dalek sound sensor prototype hardware together and it's all set for some code.

I've identified what is probably the easiest library to deal with, and confirmed it has decent long term stability. Even open loop it is returning to the calibration point consistently, as you can see below. I am very happy with it and don't expect to need a position sensor (though there will be some sort of calibration required since all the moves are relative. This could be done with a simple switch a the 0° rotation point, we can worry about that later, though).​

The test rig running a positioning loop.​

Now I have to work out out to use the sound sensors effectively.

They have an adjustable digital threshold output and an analog level output. The plan at this point is to use the threshold as a sort of squelch to fire an interrupt when there is a detection, then use the level out to compare the two sensors and rotate in the direction of the higher one.​

There are some challenges.

One is integration time. If the sound is short, it won't have time to swing to equalization. So, I am going to work out some approximation mechanism. If the sound stops while trying to find the null, it will "guess" based on the last readings.​

​

Another is the likelihood there will be "ringing" due to overshoot as it tries to null. I might be in inclined to try a PID approach to control that, which might provide other advantages as well, but I also have a couple of simpler ideas to fix it if it indeed occurs.​

Another challenge is self noise. I added the green LEDs on the sensors and they are currently just lighting when the DO of the sensor is high. The indications you see are from the noise caused by the motion itself. So I am thinking I might have to write some code to ignore the detections that occur when the arm is moving and pause it for a quick reading at intervals.​

Hopefully, I can get the reading without the motion looking to jumpy. I also thought about initiating the motion based on sound but switching to radar to find the source. That might be fun to work out, and I think it could work well.​

In any case the approach will be incremental release.

I will get basic functionality working so you can start implementing it on his end, then add refinements.​

Hi Ya’akov
I hope you are staying safe! The weather over your way looks real bad!
This is very exciting, I can’t see any images though.
Spent the last 2 days doing a clutch on my son’s Audi TT, so poor old Damian hasn’t had any attention