I hope you are staying safe! The weather over your way looks real bad!

We were very fortunate not to get the worst of it. There was snow, but mostly it was the intense cold which is now moderating. Thanks for the sentiment.

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

I am happy to be making some progress. You can't the the animated GIF? It's this:

The test rig running a positioning loop.​

 

@Ya’akov

You can't the the animated GIF? It's this:

I can’t see it either. It appears like this.

 

@djsfantasi @nicktruman

I can see it here, so I really don't know why it is not visible for you. Here's it is as a video.

 

hi,
I can see the animated GIF action OK,
Win 10, Firefox.
E

 

@djsfantasi @nicktruman

I can see it here, so I really don't know why it is not visible for you. Here's it is as a video.

Hi Ya’akov
Happy New Year. I hope you had a good holiday.

Damian is now finished, and looks rather fabulous.. (even if I say so myself)
I am already to start making things move
I have a "vision" that goes like this..
In static display mode, the dome will move to the direction of a noise, and an actuator will move the gun up and down. In EV mode (driving the thing) the Dome will stay pointing forwards.
Damian is powered by 2 12v motorbike batteries in serial for the mobility scooter and tapping off 12v for LEDs, bluetooth amplifier etc.
I have ordered a Dalek voice modulator which is coming from Wiltronics in Australia.. It has now arrived in the UK, so hopefully Damian will have a voice soon.

 

Hey, @nicktruman.

That's looking great!

I have been working on the localizer prototype and I have run into some problems. There are two major issues right now:

1) Slew Rate
Obviously, you aren’t going to want to have this thing whipping around at high speed. It would be potentially dangerous but, even if that wasn’t an issue, it would require quite a motor.

With only a two mic array, the head has to progressively localize the sound by rotating. This means that short sounds require approximations which my not be near the source. I don't think the two mic array approach would end up giving you what you want, it would probably not look at all natural even when it worked—which might be only a small percentage of the time.

2) An additional problem, exacerbated by the need to move to localize is self noise. Once the array starts moving, the noise of the motor both acoustically and mechanically coupled to the array prevents further sampling. Filtering it might be a possibility but seems very complex. The strategy I was trying is pause and sample—but I don't think that can be done smoothly.

These issues mean the two mic array approach is probably impractical, but don't give up hope! I think we can do something different.

This, or something very much like it might be the answer. It's designed to localize sound sources and it can even be used for speech recognition (possibilities...). I have to order one to see if it will work but it certainly seems it will. I suggest that you try to develop a stepper-based motion system for the head. We need that anyway and you can start with just remote control or some pre-recorded movements.

You have to decide how fast you want the head to move. If you use a reduction system the motor can be smaller, but if you can size the motor for direct drive it can be much more agile. In the meantime, I am ordering the array so I will get on that as soon as it arrives.

(UPDATE: Order Placed)

 

Keep in mind that a Dalek dome rotates after the fact, it is seldom moving when the sound is happening. At least the earlier ones worked that way.
So the solution to generated noise is for the controller to decide the amount of rotation based on the amplitude difference. and also, consider that a Dalek has only a single speed drive for the dome. I don't recall them ever tracking a moving person. So what is natural for a human or an animal is rather different from what a Dalek does.

 

Hey, @nicktruman.

That's looking great!

I have been working on the localizer prototype and I have run into some problems. There are two major issues right now:

1) Slew Rate
Obviously, you aren’t going to want to have this thing whipping around at high speed. It would be potentially dangerous but, even if that wasn’t an issue, it would require quite a motor.

With only a two mic array, the head has to progressively localize the sound by rotating. This means that short sounds require approximations which my not be near the source. I don't think the two mic array approach would end up giving you what you want, it would probably not look at all natural even when it worked—which might be only a small percentage of the time.

2) An additional problem, exacerbated by the need to move to localize is self noise. Once the array starts moving, the noise of the motor both acoustically and mechanically coupled to the array prevents further sampling. Filtering it might be a possibility but seems very complex. The strategy I was trying is pause and sample—but I don't think that can be done smoothly.

These issues mean the two mic array approach is probably impractical, but don't give up hope! I think we can do something different.

This, or something very much like it might be the answer. It's designed to localize sound sources and it can even be used for speech recognition (possibilities...). I have to order one to see if it will work but it certainly seems it will. I suggest that you try to develop a stepper-based motion system for the head. We need that anyway and you can start with just remote control or some pre-recorded movements.

You have to decide how fast you want the head to move. If you use a reduction system the motor can be smaller, but if you can size the motor for direct drive it can be much more agile. In the meantime, I am ordering the array so I will get on that as soon as it arrives.

(UPDATE: Order Placed)

Hi Ya’akov
To move the dome I am going to use a servo or stepper motor on the edge of the 22" lazy Susan bearing. This will make the dome rotate slowly. The idea is to fit a rubber wheel to the shaft and use that to drive the dome.
I still like the idea of having the mic placed in its "ear" lights.
As the dome will only be active while the dalek is static and as the servo will drive the dome with a rubber friction wheel I think internal noise will be a minimum. Thats what I hope anyway

 

Here is an interesting and detailed Master's theses showing the challenges and a solution to the time-of flight option. It looks like most everything was done in software but filtering with hardware (circuitry) could greatly simplify the software - always a balance.

https://www.diva-portal.org/smash/get/diva2:830430/FULLTEXT01.pdf

 

Hi Ya’akov
To move the dome I am going to use a servo or stepper motor on the edge of the 22" lazy Susan bearing. This will make the dome rotate slowly. The idea is to fit a rubber wheel to the shaft and use that to drive the dome.
I still like the idea of having the mic placed in its "ear" lights.
As the dome will only be active while the dalek is static and as the servo will drive the dome with a rubber friction wheel I think internal noise will be a minimum. Thats what I hope anyway

The slow movement pretty much necessitates a mutli-microphone (>2) fixed array. As far as noise, my tests suggest the modules are not sophisticated enough to easily filter any noise. Another thing I didn't mention is the lack of calibration of the modules. They need to be matched, which can be done in software, but they have to be checked against each other so they have to provide the same relative signal levels.

Anyway, I realize you are in a hurry, but the "quick" way, in this case, looks like it will require a lot more time to make up for its inadequacies. If you want to move forward with the "simpler" method I am afraid I can't help much because it is so sensitive to the implementation I would have to have the Dalek locally.

Still, no matter what, you need to build the drive. Make it from a stepper and it can be interfaced to whatever you'd like.

 

The slow movement pretty much necessitates a mutli-microphone (>2) fixed array. As far as noise, my tests suggest the modules are not sophisticated enough to easily filter any noise. Another thing I didn't mention is the lack of calibration of the modules. They need to be matched, which can be done in software, but they have to be checked against each other so they have to provide the same relative signal levels.

Anyway, I realize you are in a hurry, but the "quick" way, in this case, looks like it will require a lot more time to make up for its inadequacies. If you want to move forward with the "simpler" method I am afraid I can't help much because it is so sensitive to the implementation I would have to have the Dalek locally.

Still, no matter what, you need to build the drive. Make it from a stepper and it can be interfaced to whatever you'd like.

I'm in no hurry! I would like it to work as you suggest, so I happy to wait for a workable solution.
Regards
Nick

 

One more time with an alternative suggestion, which is to use whatever response delay time there is that is based on which sensor gets the louder sound, that the decision as to which way and how far to rotate could be made based on the delay between the two sensor signals. Based on the amplitude difference could also work. The advantage would be that the signal would serve as a trigger, not as a setpoint to track. The decision would be made before the motion started. That will also ignore any motion caused noise effect. And a time calculation can be faster than an amplitude comparison.

 

One more time with an alternative suggestion, which is to use whatever response delay time there is that is based on which sensor gets the louder sound, that the decision as to which way and how far to rotate could be made based on the delay between the two sensor signals. Based on the amplitude difference could also work. The advantage would be that the signal would serve as a trigger, not as a setpoint to track. The decision would be made before the motion started. That will also ignore any motion caused noise effect. And a time calculation can be faster than an amplitude comparison.

The "approximations" I talked about are just what you are suggesting but the problems with counting on one sample are manifold. The precision of the sampling will have to be relatively high to hope that the calculated geometry is accurate. These microphones are not precision instruments. (There re linear response sensors, but they cost about $20 each).

There is no way to account for reflections or obstructions which would result is completely bogus calculations. With just one sample, the head might turn in what seems like random directions. Iterative approximations have the problems I discussed of slew rate affecting integration time and the self noise. Additionally, if the sound source is moving, well... you can see the problem.

Really, the only thing different about your proposal Is to use a ToF variant rather than amplitude, and to take a single example. It is my belief that single sample is unworkable. With a fixed array and access to the beamforming technology used on the various smart speakers, the self noise problem is eliminated, and however many samples it needs to localize the source can be taken while the rotation target is updated in real-time.

 

Hi Everyone, I am still struggling with this
I have bought a powerful bipolar stepper motor, a NEMA 16, Bipolar Stepper Motor. and some A4988 Stepper Motor Driver Modules. And am trying to set up the circuit as per the image below.. and https://create.arduino.cc/projecthub/lbf20012001/sound-location-finder-92e6b0

When a noise is detected by the microphone I can see the Arduino flash, and the serial monitor prints "turning left" or "right" depending on what mic picks up the sounds
But the stepper doesn't move.. So there must be an issue with the way I have connected my stepper to the driver.. (it shudders when I power the board up)
I have built ears for my Dalek now and embedded a microphone in each ear.

My Dalek is being used in a centenary exhibition this Sunday coming, for the village I live in, in the 1970s the company that built the first Dr Who stage prop Dalek was based just down the road from where I live.

 

hi nick,
That 9V battery is not up to the job of driving a stepper, that can move the head assembly, also the circuit needs some power rail capacitors.
E

Link or datasheet for the stepper motor, would help.

 

Hi Everyone, I am still struggling with this
I have bought a powerful bipolar stepper motor, a NEMA 16, Bipolar Stepper Motor. and some A4988 Stepper Motor Driver Modules. And am trying to set up the circuit as per the image below.. and https://create.arduino.cc/projecthub/lbf20012001/sound-location-finder-92e6b0

When a noise is detected by the microphone I can see the Arduino flash, and the serial monitor prints "turning left" or "right" depending on what mic picks up the sounds
But the stepper doesn't move.. So there must be an issue with the way I have connected my stepper to the driver.. (it shudders when I power the board up)
I have built ears for my Dalek now and embedded a microphone in each ear.

My Dalek is being used in a centenary exhibition this Sunday coming, for the village I live in, in the 1970s the company that built the first Dr Who stage prop Dalek was based just down the road from where I live.

Nice to see you moving forward with this, sorry I haven’t been as much help as I’d hoped (Microphone array due any day now from AliExpress). If your current method works well enough for you that will be great! I hope it does.

A @ericgibbs points out, the power supply is certainly a problem if not the only one. A 9V battery of that sort can’t provide enough current. They are among the worst power sources around in terms of cost and capacity.

If you don’t have a bench supply, get one. A bog standard 0-30V 0-5A supply (like, if not, this one) will find a million uses and it will work for this for testing. When you find out how much current you actually need (the supply will help with that) you can find an appropriate battery, preferably a LiPo pack or some other rechargeable option.

Also, proper capacitors are needed.

 

hi nick,
That 9V battery is not up to the job of driving a stepper, that can move the head assembly, also the circuit needs some power rail capacitors.
E

Link or datasheet for the stepper motor, would help.

Hi Eric
I am using a 12v motorbike battery.
I have just realised that this stepper is 24v, that is OK as the Dalek has 24v inside. What controller should I use? I am guessing the ones I have bought will burn out
NEMA 16, Bipolar Stepper Motor 200 Steps / Rev - Made in Japan
Bipolar Stepper Motor with Brass Collar – 200 Steps / Rev – NEMA 16

• Manufactured by Shinano Kenshi
• Model: STH-39D254
• 200 Steps per revolution (1.8 deg / step)
• 2 phase bipolar motor
• 60 Ohm coil
• Voltage: 24 V
• 4 leads – 5″ long without connector (bare)
• Dimensions: 40 mm W x 40 mm D x 36 H (NEMA 16 Frame)
• Shaft dimensions: 5 mm Diameter x 10 mm Long

 

Hi Eric
I am using a 12v motorbike battery.
I have just realised that this stepper is 24v, that is OK as the Dalek has 24v inside. What controller should I use? I am guessing the ones I have bought will burn out

The module you have should be fine. 24V and 60Ω would get you around 400mA, say 1A for headroom on peaks. the module should handle 1.5A at up to 32V, so you are OK with that.

I still encourage you to get a bench supply. A 24V battery could so easily fry everything while you are working on it. The bench supply has current limiting so you can keep it low until you know you’ve got things right.

 

hi Nick,
You need decoupling capacitors on the 24v rail.
How are you deriving the Vcc for the Arduino.?
E

 

hi Nick,
You need decoupling capacitors on the 24v rail.
How are you deriving the Vcc for the Arduino.?
E

Hi Eric
The Arduino has a separate 9v supply.
How do I add the capacitors?
Regards
Nick