For next Halloween I want a Dalek for "Trick or Exterminate"
Already have an account? Log in.
To make the experience fit your profile, pick a username and tell us what interests you.
Dalek Plans
Well I bought a set of Dalek "plans":
A Small Diversion
Last year here was my attempt at scaring the kids away:
These guys were painted with phosphorescent paint so with a UV light they glow in the dark.
My Dalek Creature
Inside my Dalek is this guy - the Dalek Creature!
The Dalek Build
Basically a remote controlled WIFI Arduino controlling stepper motor drive, a Dalek voice with one phrase - "Exterminate". Perhaps a Nerf gun?
AlanX
Start looking at master/slave arrangements using the ATTiny85 (as in the DigiSpark ATTiny85).
A have a couple of these lying around.
Found the TinyWire library.
I have some notes/code for using the timers so all good.
They are called "tiny" because after the Reset and SDA/SLC there are only 3 available pins.
Here is the I2C stepper driver board:
The idea is to place each I2C stepper driver board next to the motor to avoid interference to the other electronics.
I have played with the DigiSpark serial interface but it is not stable.
Here is the ultrasonic envelope detector transceiver board set up for I2C and Ping interface:
The above concept unfortunately will hear the 30 kHz stepper motor chopper frequency which I suspect was "the straw that broke the camel's back" that forced me to "surrender" (i.e. give up on making the Halloween deadline).
But really to begin should use HC-SR04 with a DigiSpark:
The problem with the servo solution is that scanning is too slow given the HC-SR04 can take more than 200 ms to time out. At least the ATTiny85 can hurry up the time out.
I will have to find some suitable shielded cable to link up all the modules.
I suspect that on of the issue I was experiencing in addition to Inductive kick-back (back EMF) and Inductive current coupling was the stepper PWM frequency noise up setting the HC-SR04. Although HC-SR04 uses an active filter it is probably not sufficient to filter out enough of the chopper noise.
Checking schematics on the Internet of the HC-SR04 (that I have), the nearest match was (http://remotesmart.wikidot.com/esp202):
Here is the response for the active filter (the IC2:C):
I can't read the capacitor values C2 and C3 so perhaps they are 500pF?
Others have confirmed the 20kHz centre frequency (http://uglyduck.ath.cx/ep/archive/2014/01/Making_a_better_HC_SR04_Echo_Locator.html) so I guess it is right.
The sensor itself offers little out of band rejection (if you accept the equivalent circuit):
Here is the concept (rather than a design as the Q is too low):
As the ATTiny ADC runs at 125 kHz it makes a good candidate for a Goertzel tone decoder.
Using 125 kHz sampling frequency and 25 samples (measuring 8 pulses at 40 kHz) here is what the frequency response looks like:
The band-width is 5 kHz (=125 kHz/25).
The side lopes are only -13 dB down.
This can be improved by adding a "window" to the sample data (see http://www.mstarlabs.com/dsp/goertzel/goertzel.html) but at the cost of increasing the band-width:
But does it work for pure digital data:
Here is the same window but with a log scale:
I tried using HP, Band Pass and Notch recursive IIR filters but with little success.
I am not sure why - could be coding errors or just not enough samples.
Here is the same setup but with twice the number of sample points (measuring 16 pulses):
Here is the same setup but with twice the number of sample points and twice the sample frequency (250 kHz, measuring 8 pulses):
Okay the noise floor has fallen.
And with 500 kHz sample frequency:
And the noise floor as fallen again.
I even looked at a 2 bit binary (i.e. flash ADC) and that is approximately equal to doubling the sample frequency:
Here is the original analog Goertzel using a log scale:
So it would appear that either a very fast digital read (>1 Mhz) or the analog read (=125 kHz on the ATTiny85) can work.
I finished coding the motor/sonar board and tested the software.
I used serial print and the built in LED to indicate the sonar and command/motor status.
The sonar and motors work as expected separately but when combined too many false sonar triggers.
I am wondering if motor noise and/or vibration are triggering the sensors?
The ESP12-E is not that stable as well (it can stop working) suggesting electrical problems still exist.
Many months ago I had a remote control test bed that worked fine.
I have spent months trying to get the HC-SR04 working with the test-bed.
It seemed at the time adding sonar would be a small job.
What when wrong? I still don't understand!
Yes, the steppers somehow destroyed four HC-SR04s.
The servo certainly did take out two HC-SR04s and a 6.2v 1W zener (lucky it did not take out everything).
Anything inductive needs special attention to the power supply, you have to consider inductive kick-back.
Better to build a separate motor controller and even a separate motor power supply.
Better to delegate software duties (i.e. use a master-slave setup) as managing everything on one MPU is difficult (particularly the ESP-12E).
Find a replacement for the HC-SR04!
I will return with a new plan of attack but after Halloween, AlanX
I have made a serious error in this project trying to use a common power supply for the steppers and the other electronics.
A serious error that has cost weeks if not months of extra work!
Twisted pairs for the cables and decoupling capacitors on the stepper motor outputs seemed to fix the problems.
The problems appear to be two fold:
These upset the signal lines (i.e. inputs to the MPU) but I doubt they have enough power to destroy a device (i.e. eight HC-SR04).
Twisted pairs on the power/stepper/signal cables works wonders here.
The HC-SR04 has a 10k pull-up resistor on the trigger (input) and echo (output) which obviously helps (reduces sensitivity to inductive currents).
Previously, I added 100nF decoupling capacitors across the stepper motor terminals which reduced noise and very likely electrical noise (from the PWM).
My back of the envelope calculation was that the resonance frequency was 2.6 kHz.
Which is well above the operating speed (<=400Hz) and well below the PWM frequency (>>20kHz).
I found an application note for the designed of LC low pass filters for stepper motors.
Worth a review if it reduces the EMI further.
I don't think I am having any problems with inductive coupling any more but before the next set of tests I will run the steppers by themselves and check all the drive board power and signal lines.
Ran the tests, I only found some ripple on the battery line, everything else was clear.
At last count I have "buried" eight HC-SR04s.
Probably killed the MAX232 as it a 5v device (6v absolute max).
Certainly the servo killed the last two as they shared the same power supply (note the 13v inductive kick-back - limited by the 5v regulator diode back to the battery):
The inductive pulse is pretty high powered, at least 2 Ampere as the power supply (5v) has been pulled down to less than 3v (in the above inage).
The servo now has its own high current power supply and a 100uF capacitor to absorb the inductive spike (now less than 8v).
Reducing the output voltage to about 4.9 volts and adding a 5.1v 1W zener to the voltage regulator output reduces the inductive spike to "ripple".
Had some problems with servo sweep stuttering due to background processes interrupting the timer.
Here is a bad version where I try to lock the frequency:
agp.cooper
#define servoPin D4
const int minAngle=15;
const int maxAngle=175;
int servoDir=5;
volatile int servoState=0;
volatile int servoAngle=90;
volatile unsigned long next;
void inline servoISR(void)
{
if (servoState==0) {
digitalWrite(servoPin,HIGH);
servoState=1;
next=next+40000+889*servoAngle;
} else {
digitalWrite(servoPin,LOW);
servoState=0;
next=next+1560000-889*servoAngle;
}
timer0_write(next);
}
Here is the fixed version where I let the frequency slip:
// Servo defines
#define servoPin D4
#define minAngle 15
#define maxAngle 175
volatile int servoDir=5;
volatile int servoAngle=95;
volatile unsigned long next;
volatile int servoState=0;
void inline servoISR(void) {
next=ESP.getCycleCount()-180;
if (servoState==0) {
digitalWrite(servoPin,HIGH);
servoState=1;
next=next+40000+889*servoAngle;
} else {
digitalWrite(servoPin,LOW);
servoState=0;
next=next+1560000-889*servoAngle;
}
timer0_write(next);
}It is not a perfect fix but the stuttering is gone.
The second issue was requirement to yield to background processes.
Any loop that is more than 50 ms must yield.
The yield() instruction can be replaced with a delay().
The optimum delay appears to be 2 ms (i.e. delay(2)) based on comments by other people.
But I am finding that after 40 ms the echo has not come (i.e. timed out).
Currently the software fires the next trigger pulse that triggers an echo about 300 us later (not good)...
Read more »Not a good day!
The old scanning sonar files are lost.
Okay start from scratch:
Here is the sonar scanner:
Could not get the sensor to work!
I had no problem a few days ago?
Tried three of them.
They would work if I touched them and then stop (you can hear them fire) when I move my hand away.
Changed to an Arduino Uno rather than a nano - same problem.
Use a power supply for the Uno.
All the sensor behave the same - cannot work it out.
Have I blown them up (my laptop USB has 35v AC on it - modern power supplies are all like this - unearthed)?
I will have to check if the trigger pulse is getting through with the oscilloscope (tomorrow).
Relocated to my old desktop (it is earthed and less AC voltages on the metal surfaces).
Compiled NewPing and my version of sonar code.
Well the same problem (but not as bad).
The problem is the HC-SR04 stops working and usually (not always) needs to be powered down to reset.
The HC-SR04 fails if pointed into space (i.e. timeout) but can fail in other ways.
I have test three sensors and they all fail.
Fails for 50 ms and 1000 ms between triggers.
Checking with the oscilloscope, the trigger pulse for both the NewPing and my code is fine.
(The NewPing pulse threw me at first until I realised it was a trigger/echo signal.)
Added a 100uF to the Vcc and Gnd pins - no change - There was no real noise on the power supply or signal pins anyway (when using the desktop).
How does it fail? The Echo locks high!
There are schematics on the Internet that show the outputs are pulled high by a 10k resistor and controlled by a uP.
Emil's Projects (http://uglyduck.ath.cx/ep/archive/2014/01/Making_a_better_HC_SR04_Echo_Locator.html) has a pretty good description of the SHC-SR04.
Still I am puzzled? I did not have this out right failure when before.
It is as if they were damaged by the Dalek Test-Bed?
I only have one virgin sensor (that hs never been used on the Dalek Test-Bed) that I used for the twin sensor experiment (fail):
So I tested both (I left provision for this) and one sensor does not work but the other does.
I wonder which one has never been used on the Dalek Test-Bed!
The death statistics are five HC-SR04s, all from the Dalek Test-Bed!
Well it seems plausible that the Dalek Test-Bed (with the stepper motors) has damaged the HC-SR04s.
So high voltage inductive currents could be the reason(?).
But how? The HC-SR04s are feed from a 5v voltage regulator and each are decoupled with a 100n capacitor at the jumper.
The leads although twisted do pick up noise as a HC-SR04 with an extension (far right hand side) did not work (until the extension was removed):
I wish I knew what has failed on the HC-SR04?
I think I have taken enough precautions for the power supply (because it is an obvious problem area).
But I have not done much for the HC-SR04 inputs and outputs (a possible failure mode is from inductive currents?):
Just as well I order 10 more HC-SR04s.
Scanning Sonar
Scanning sonar up and running.
Usual problem of occassional zeros etc. but nothing like problems I have been having with the fixed sensors.
Emil's Projects (http://uglyduck.ath.cx/ep/archive/2014/01/Making_a_better_HC_SR04_Echo_Locator.html) suggests if is just crappy programming of the MPU.
So now I need some flexible shielded cable, a couple of current limit resistors and a metal box to mount the HC-SR04.
Here it is:
Pretty rough job but no time for perfection.
Inside the box is a strip-board with a protective circuity that should protect the HC-SR04 from any stray inductive currents.
I suppose I could stick a face on it.
My first (two transistor) receiver...
Read more »Time is running out!
Before I walk away from DIY ultrasonic sensors I thought I better test the transmitter and LM567 tone decoder receiver.
Here is the transmit pulse on the transistor collector:
Pretty untidy! Something is going on as the base pulses are clean?
Here is a transient simulation to an 8 pulse sequence:
So it is working properly!
The ringing during the pulses is part of the network matching behavour.
The post pulse ringing (after 300 us) is due to the ring of the choke (changing the inductor value changes the ringing frequency).
Here is the sensor voltage:
Okay there seems to be sub-harmonic ringing that matches the choke ringing.
But at least the voltages are nearly 20v pp.
Damping the transmitter sensor with a 1k resistor helps a little:
and
On the receiver side I am picking up signals but very erratic:
The receive sensor (off the transistor collector):
The transmit and receive signal basically overlap (lots of ringing).
After damping with a 4k7 resistor:
Better but really still pretty useless.
There is a lot of work required to get these senors working properly!
It seems like the scanning sonar that basically worked before (but not perfectly) is going to be the fastest route to getting the Dalek finished.
So tomorrow I will dig up the hardware and see if I can get it working again.
AlanX
Dale Heatherington said:
"During my experiments I observed that large objects well within sonar range sometimes did not show an echo. Moving them a fraction of an inch resulted in large return echoes. This was caused by multiple reflections arriving at the receiver out of phase. They canceled each other out! The solution is space diversity. Two receiver transducers are placed about an inch apart. They are connected to separate signal processing chains. It's unlikely that both receivers will be in a phase null at the same time so reliably is greatly improved. Now I have three transducers per channel but it works great!" (source: http://www.botlanta.org/ahrc-publications/sonar6)
Here is Dale Heatherington's dual receiver sensor setup:
This is exactly what I was finding with my sensor tests and with the HC-SR04!
So the answer is not four sensors but eight or twelve.
Well actually all I really need is enough overlap that if a sensor will not read then just average the distance between the two adjacent sensors.
Actually a much better approach is scanning sonar like this:
Time is running out so the answer is either two sensors per direction (eight all up) or twin sensor scanning sonar.
Time is short so using the existing driver board is preferred.
Unfortunately the driver board does not have room for eight sensors:
I could add a daughter board with another PCF8574 but a better idea is to trigger two HC-SR04s at a time and the diode OR the returned echos.
The only problem now is that I only have two spare HC-SR04s.
But at least I can test the idea why I am waiting for the new sensors to arrive.
Here is the twin sensor concept (note: I have added a 10k pull-up resistor to the echo output):
The transit and receive sensor pairs are about 36 mm apart (~1/2 wave length).
So no negative transmit interference pattern (except at 90 degrees to the sensors).
The theory is simple but I did a simple simulation in Excel:
The theory is that the receivers are far enough apart that both receivers are less likely to be affected by a negative interference at the same time.
The sensor echos are diode ORed, so the first sensor to fire will interrupt the MPU.
The transmit power is doubled as well.
As Dale says, I could stack more of these sensors if increased reliability is required.
I assembled the dual sensor with ORed echos but unfortunately it was even more unreliable. I can't win! I do know one of the sensors was not that good but still.
I still beleive there is merit in the multi-receiver solution though.
AlanX
Now that I have something that is basically working, I thought it would be time to think about how I am going to integrate four sensors to the ESP-12E.
The ESP-12E does not have eight free lines after allowance for the stepper control and other planned functions.
Generating in software a 40 kHz drive signal through I2C is not possible (too slow).
It seems like an ideal job for a ATTiny (slave) using I2C to communicate with the EPS-12E (master).
I that case having an LM567 and an ATTiny85 would be a bit of over-kill.
Why not simulate the Phased Locked Loop (PLL) in software on the ATTiny85 (it is something I have previously researched).
While I am thinking of it, here is my DIY PLL (hardware design using LS-TTL, the actual PLL is the 74LS02 at the bottom of the schematic (beginning with the 2_FSK probe) - yes it is that simple):
Another option would a Discrete Fourier Transform (DFT).
A search of the Internet suggest Goertzel algorithm would be a very good choice (someone has even written an Arduino library!).
Here is the algorithm:
double goertzelFilter(int samples[], double freq, int N) {
double s_prev = 0.0;
double s_prev2 = 0.0;
double coeff,normalizedfreq,power,s;
int i;
normalizedfreq = freq / SAMPLEFREQUENCY;
coeff = 2*cos(2*M_PI*normalizedfreq);
for (i=0; i<N; i++) {
s = samples[i] + coeff * s_prev - s_prev2;
s_prev2 = s_prev;
s_prev = s;
}
power = s_prev2*s_prev2+s_prev*s_prev-coeff*s_prev*s_prev2;
return sqrt(power)/N;
}(source: Efficiently detecting a frequency using a Goertzel filter - Wilfried Elmenreich)
Note: I modified the return value for rms of signal voltage.
Going through the calculations for an ATTiny85, 25 samples at 125 kHz (K=8) has a centre frequency of 40 kHz and will take 200 us (i.e. 8 pulses). The bin/band-width would be 5 kHz. The 8 bit (0-5v) ADC has a voltage step of about 20 mv.
A CMOS 4052 (2x4 analog multiplexer) or equivalent would work well here.
The pre-amp could even be on the MPU side of the multiplexer but then shielding of the inputs would become necessary - perhaps not!
Only one analog pin and three digital (output) pins would be required for four sets of sonar range finders (easier than using four ATTiny85 and I2C).
So interface directly to the EPS-12E is a good option.
Need to check out the EPS-12E ADC.
No, the conversion speed is about 83 us (12kHz) but OP report less in loop{} (about 8kHz).
Found an external SPI 4/8 chanel ADC (MCP3004/8) which looks interesting and fast enough (75 to 200 ksps depending on the voltage).
I need to see if a digital version would work for this application.
Wrote a short C program and plotted the results in Excel.
Here is the analog filter response:
Here is the digital (0 or 1) filter response:
Testing with low mark/space ratio:
And with high mark/space ratio:
Should be pretty easy to read a digital pin quickly (one source says 0.527 us on the ESP8266) on any MPU.
Not quite sure how to set up the analog/digital interface.
Here is one idea:
Cascade two amplifiers and offset the output (the input pin of the MPU):
The gain is just less than 60dB:
At 2 mv pp (at the signal generator) the signal is less than the MPU input trip point (assumed to be 1.65v):
At 10 mv pp the signal will trip the MPU input:
At 20mv pp the signal is not that much different:
Now the question is what should the gain be?
The gain depends on the background (signal) noise.
I found this image on the Internet:
(source: http://www.botlanta.org/ahrc-publications/sonar6)
This author has used an adaptive threshold but for his set up, a fixed threshold of...
Read more »I bought these 15 mH inductors many many years ago. Finally I have a project to use them in. Here is the receiver part of the sonar range finder I have been designing:
(Note the 15 mH (=153) inductor on the left hand side.)
Before building the transmitter side (on the right of the vertical wire link), I wanted to check that it was working.
Checked the collector voltages:
Check the output for noise:
Set up a HC-SR04 as a sound source and test the receiver:
Check for miss-wiring etc., all okay.
Think about it and decide it has to be the inductor:
Hand calculated the resonance frequency - close enough.
Do ferrites age? Anyway, the inductor cannot be 15 mH.
Checked the DC resistance, less than 0.6 ohm (including the fuse of the multimeter) which is just too low when compared to a 4.7 mH inductor I have (which is about 11 ohm).
Peel the jacket off and count the windings - 22 turns!
Checked some ferrite datasheets and my estimate is about 15uH not 15mH.
I have been conned!
I have some ferrite beads (FB-43-2401) that with 171 turns of 28 AWG (i.e. ~0.32 mm diameter wire) would make a 15 mH inductor. No, threading 4 to 5 m of fine wire does not sound like much fun. I will have to order some from ebay.
Measuring the sensor directly gave voltages in the order of 100-200 mV with the sound source just 10-20 cm away. That is great, the sensor is working as expected BUT is was ringing for 100s of microseconds! Looks like the sensor will need to be damped (properly loaded). In theory, the transistor is matched to the sensor so when powered it should be damped.
Found a toroid ferrite at the local electronics shop:
Found a datasheet for L8:
Found a webpage to calculate Al:
Magic, 120 turns for 15 mH.
Reworked the matching networks for both the receiver and the transmitter and reduced the transmitter choke to 4.7 mH (which I have on hand).
Here is the updated strip-board design:
Here is the receiver:
And here is the transmitter:
I am a bit worried about ringing of the transmitter and the receiver sensors.
An unloaded receiver sensor rang for 100-200us when 15 cm away from a HC-SR04.
The matching networks should load the sensors but I have added provision resistors if ringing is still a problem when in-circuit (10k for the receiver sensor and 1k for the transmitter sensor).
I wound the 15 mH inductor last night.
120 turns on a 18mm x 10mm x 6 mm toroid of L8 material.
Here is the first stage of the transceiver:
Here is the test set up using a HC-SR04 as a signal source (30 cm away):
An here is a closeup of the oscilloscope:
Yes the output is rail to rail! The sensor Q is quite evident with the 300 us ramp up (3 major divisions). Note that the transistor output hits the rails after 200 us. The signal decay is about 400 us.
How strong should the signal be?
For this set up the sensor should (my estimate) produce about 30 mv rms (~100 mv pp).
The display matches the expected transistor performance. based on Tina. So all is good.
I have made provison to further load the sensor to damping the ringings but it is too soon to tell if it is actually required for my application.
Added the next stage (the demodulator), it works but it is not very sensitive or stable.
I think unintended demodulation from the first stage is upsetting the bias of second stage.
I am not sure how I can fix this,...
Read more »First lets start with the expected signal level.
Based on the 400RT160 datasheet (http://www.robot-electronics.co.uk/files/t400s16.pdf) and the Pro-Wave Electronics Corporations application note (http://www.prowave.com.tw/pdf/an0508309.pdf) the approximate signal level is in the order of 1 to 10 mV:
| 400SR/T400 | |||||
| Transmitter SPL | 117.0 | 10v rms at 30cm | |||
| Power adjustment | -6.0 | 5v rms | |||
| Distance loss | -28.5 | =20*log10(30/x) | Distance | 800 | cm |
| Wave absorption | -1.6 | =-0.002*cm | |||
| Receiver sensitivity | -57.0 | 3.9k load | |||
| Conversion uBar to V | -74.0 | ||||
| Signal | -50.1 | dB | |||
| Signal | 3.119 | mV |
Here I have assumed 5v rms transmitter voltage rather than 10v rms as per the standard.
The sensor input impedance is 3.9k ohms.
The signal input (3 mV) suggests a minimum receiver gain of 60dB (x1000) is required.
I have designed two circuits (more options are available for consideration).
The first is a two stage transistor amplifier (74dB gain based on the Tina simulation) followed by a diode detector. For this circuit I assumed the sensor impedance was about 20k as I had not found the right datasheet.
A very important note is that I have not designed the supply noise filtering for this circuit. With 74dB of gain (x5000) and the input in-phase with the output, the risk of feedback is almost certain.
Hers is the frequency and transient analyses:
The second version is less sensitive but should not suffer feedback oscillation:
The choice of detector diode determines the receiver sensitivity. A germanium diode would work best followed by schottky diodes and lastly conventional silicon signal diodes.
The preliminary transistor amplifier design is as follows:
| Preliminary Design | Value | Units | |
| Transistor | BC548B | ||
| Beta (2mA) | 290 | ||
| Vs | 5.0 | v | |
| Vc | 2.7 | v | |
| Rc | 4.70 | k | |
| Ic | 0.489 | mA | =(Vs-Vc)/Rc |
| Beta | 236 | =log10(2/1000)/log10(Ic/1000)*Beta(2Ma) | |
| Zin | 12.1 | k | =Beta*25/1000/Ic |
| Rb | 0.99 | M | =(Vc-0.65)*Beta/Ic |
| Av | 108 | =Vc/25*1000 |
The design formula works okay except that Tina predicts a much lower gain.
Still it is a useful starting point.
In both these sonar receivers I have used a pre-selection LC filter to reduce out of frequency response and to match the sensor to the transistor input impedance.
I used capacitor tapping to scale up the impedance in the two circuits:
RL~RS*((C1+C2)/C1)^2, where C1= 4n7F and C2=2n2F in circuit 2
In this case I used Tina to determine the exact capacitor values but there are formulas for this if you look on the Internet.
I also played with this one:
And:
The low limit of detection is in the order of 100uV which is a bit of overkill.
The second version looks about right to me if I use a Ge diode (or a Ge silicon clone).
Probably time to make a prototype using strip-board, here is a layout:
Based on the limited data on the EPS-12E the digital pins can source/sink 12 mA. This is similar to the AVR specification. So an estimate of the "source" resistance is 275 ohm (=3.3v/.012A). The effective source resistance is probably lower. The ultrasonic transmitter has a load impedance of about 500 ohm (based on the datasheet). So I matched the source impedance ad load impedance using a Pi network and updated the strip-board design. I calculate the output power to be 1.6 mW (2.55v pp based on Tina). Here is the Tina schematic:
Here is the strip-board design:
Checking the range:
| 400SR/T400 | |||||
| Transmitter SPL | 117.0 | 10v rms at 30cm | |||
| Power adjustment | -20.9 | EPS-12E single pin | 3.3v into Pi network | ||
| Distance loss | -4.9 | =20*log10(30/x) | Distance | 53 | cm |
| Wave absorption | -0.1 | =-0.0019*cm | |||
| Receiver sensitivity | -57.0 | 3.9k load | |||
| Conversion uBar to V | -74.0 | ||||
| Signal | -40.0 | dB | |||
| Signal | 10.0 | mV | Receiver detection limit | ||
A return range of 53 cm (26.5 cm one way) is practically unusable!
Okay, I either increase the transmitter power or increase the receiver gain.
Looking at the receiver I had a play with reducing the supply voltage...
Read more »The hardware is complete, here is the testbed:
The battery is missing (being recharged after a day of debugging).
The white strips are Velcro.
The testbed has been set up as an autonomous robot using the ultrasonic sensors to stay away from objects.
It basically works but there a problems (what is new!).
Currently making sure the sensor and stepper drive logic works.
The main problem is that the sensor (or sonar) ticker interrupt (every 250 ms) interferes with the stepper pulse ticker interrupt (every 10ms) as stepper pulses appear to be lost). I assume that the sonar ticker interrupt (that can take up to 40 ms (with time out) to return) is blocking stepper ticker interrupt. The ticker interrupts do not appear to be the same as normal interrupts as the sonar routine waits for a real interrupt on D3 and is working.
It is not unreasonable to assume that Ticker is blocked while servicing a ticker interrupt.
I moved the pulse timing loop out of the interrupt routine and into loop(). No difference!? Okay worked it out. Ticker is not interrupt based but "Blink without delay()" based. Better than nothing I suppose. Okay, recoded on this basis and the motors work fine but the sonar no longer works.
The sonar work fine until I turn on the steppers. The interrupt line must be picking up the stepper noise. It was okay before because the sonar blocked the stepper pulse during the echo period.
So now I have to research noise suppression.
See image:
I think I forgot how bad ultrasonic sensors are! I did a sonar project a while back so I should have known:
Filtering the bad reads is problematic. Simple averages don't work well.
With the sonar project I used the median value of three sequential reads.
This time I used two similar consecutive reads with "too far" over-rides.
This work as well as can be expected, but the code need tuning.
It still struggles to get through the doorway and still crashing into walls.
Here it is when it works (turning to avoid the wall):
I thought it was time to draw up the sensors to "engineer" the direction they point and the correct range trigger.
So here is my sketch:
I should point the sensors forward and set the range to 50 cm (assuming a 45 degree aperture based on a datasheet I have).
This gives full frontal coverage and 640 mm wide window.
But the problem is that the sensors do not detect the walls as the angle of incidence is too low (~22.5 degrees).
I need four sensor! Two short range (at 60 degrees with 15 cm range) to detect the walls:
The forward sensor worry me a little because they are only 14 cm off the ground so expecting a range of 50 cm not going to be reliable (some back-scatter off the ground is likely).
It looks like I will need four ultrasonic sensors and the PCF8574 is the obvious choice for managing these.
I have four spare ESP-12E digital pins so I should move the two sets of stepper direction and step lines off the PCF to make room for two more ultrasonic sensors.
The board layout needs a rework anyway. It would be a good idea to move the sensors away from the DVR8825s.
Spent a day resigning the board. Here is the design:
Had some work to do at the partners house (fixed 4 leaking taps and swapped out the washing machine).
But I did manage to find 4 hours to assemble the board....
Read more »
besides the cosplay, it's possible to create a real dalek. develop the shell, put a baby octopus to driver seat and let it grow with this new body. most octopus species got brains almost similar to dolphins, i think they can learn to move vehicle by using their arms.
I hope to god you've heard about projectdalek.org.
Highly detailed schematics for every dalek ever.
Hi Ryan,
No, not that site.
I am not trying too hard to make it authentic. Just scary!
I really want it to be autonomous but it has been so hard.
Any ideas for a gun?
I though a fire extinguisher would be pretty cool (saw a YouTube of Dalek's with fire extinguisher type guns) but unfortunately not very practical.
Regards AlanX
Heh, glad you're not too worried about the details then. Some of the more minimalist designs I've seen are often the scariest.
I have no idea about the gun, but you might get a better answer on the site I mentioned. It's been ages since I've been there, but I know there's enough people who've made daleks for so many different reasons that they'll probably have an idea or two to share around.
Thanks Simon,
But I seem to be bogged down getting the ultrasonic sensors working and time is running out.
I showed a video of a Dalek to my grandson (5) and he is not happy!
Told his Mum so I am in trouble!
Regards AlanX
You realise, if you make this too good... you'll have to start calling yourself davros and we need to find a doctor to stop your evil plans?
Nice work :D
M. Bindhammer
Deezmaker
junkotron
Alex Hunt
Following