Keith's Electronics Blog

As noted in Googly Eyes Part 1, I built a demo back in February out of a CD-ROM drive optical sled assembly and a couple of ping-pong balls. In the earlier installment, I discussed reverse-engineering the sled’s electrical connections; now here’s how I rebuilt it to operate eyeballs.

I had thought I might find some googly eyeballs in the Wal-Mart craft department, for making big puppets or something. But all their googly eyes were the flat, button-like kind that just stick onto a surface, so I went with my fallback plan of ping-pong balls.

I drew an eye onto two of them, with a black pupil and green iris. I didn’t mean to get the iris quite so dark, but at least I made it with radial lines.

I located and marked the north and south poles of the ping-pong ball as carefully as I could, then drilled through with PCB drill bits. After stepping through several increasing sizes, I was able to use my stepped drill bits to make nice, round, even holes for the axle. I stuck a bolt through and threaded a nut up fairly close to the ball, so it could swivel but not move up and down much.

The sled assembly didn’t have the right sized holes in the right places, so I used big fender washers to make things fit. The eyeball-mounting nut is tightened against the fender washer, with another washer and nut on the bottom side. The bolts continue through the frame and act as legs to raise the underside of the carriage off the surface it’s sitting on, with cap nuts (acorn nuts) for feet to keep the end of the bolt from scratching.

This was actually a bit less than ideal, because the mounting hole for the right eyeball (left edge of the picture) is in a section that’s bent up and raised above the plane of the other holes. I tried compensating for the height difference with an extra nut under the left eyeball, but it’s still not quite right. Probably a washer in between the two nuts would fix it up.

Finally, I needed to translate the sled’s linear motion into the eyeballs’ rotary motion. I turned a loop into the end of a couple of pieces of stiff wire, and . . . had to take the eyeballs back apart again. I drilled another hole in the back of each one, then pushed the wire loop into the interior and reassembled them with their bolts going through the wire loops. Once reassembled, I dabbed some hot glue where the wires came out of the eyeballs; now I could use the wires as control rods to rotate the eyes.

I removed all the optical parts from the carrier sled, then ran a bolt up through it to the height of the eyeballs. I made a loop in the center of another piece of wire and sandwiched it between two nuts on the sled bolt, then made a loop at each end around the eye control rods. After a little tweaking of the angles, I got it set up for fairly smooth movement, with the ends bent to keep things from slipping out of the loops.

In Part 3, I’ll discuss the software that moves the motor and watches the optical disk to monitor travel.

Back in mid-February, I wanted to demonstrate motor control with the LogoChip to class, but it’s hard to see what a motor is doing unless it’s geared down and attached to something. I decided to make googly eyes that could look around, and here’s how I went about it.

CD Read Sled

Although the motion of each individual eye is rotary (right to left; these can’t look up and down), to synchronize their actions, I needed linear motion.

Digression: Predator species have eyes on the front of their face, to triangulate the distance to their target. Prey have eyes on the sides of their heads, to keep the widest possible view of their surroundings and watch out for predators. Predators’ eyes generally move in synchronization. Of course, they may look slightly inward when watching a nearby object (binocular convergence; think of looking cross-eyed at your nose); but for a simple model like this, two eyes always looking in exactly the same direction is adequate.

I figured my best shot was something from a dead CD-ROM drive, so I went down to examine my stash. What I call the read sled assemblies looked the most promising–they’re the ones that move the read head in and out along the radius of the disc to find the right position to play. The tray motors might also work, but the trays have a good 5″ range of motion. The ∼2″ range of the read sled seemed much more useful.

Several of the assemblies I examined used a stepper motor, but I wanted to demonstrate a simple DC motor, so I kept looking. Finally I came across this one, which had a DC motor (on the underside), a nice geartrain, and an optical encoder (the faint grey circle between the green PCB and the medium black gear) to determine the position of the sled.

The motor was mounted from the back side, and the optical disk was press-fitted to its shaft.

Reverse-Engineering the Optical Assembly

I was interested in trying to reuse the optical assembly so that I too (well, my program) would know where the sled was, so I desoldered the flex pcb ribbon cable and set about figuring out the connections on the PC board.

The larger black rectangle that overlaps the optical disk was obviously an optointerruptor–one side has an LED and the other side some kind of optical sensor. When a hole in the disk passes between them, light is transmitted; when a bar passes between, the light is interrupted, and the receiver can tell the difference.

The two smaller black rectangles (southwest of the screw head) are surface-mount resistors, reading “181″ (180Ω) and “752″ (7.5KΩ). I could visually follow some of the traces (the light green lines) on the board, but I got lost with exactly what happens underneath the resistors.

I assigned numbers to the five solder pads from the cable, arbitrarily numbering from the outer edge of the board. (In retrospect, that was incorrect–the pad to the left in this photo is shaped differently than the others; that makes it pin number 1. Ah well.) Then I made this table (actually edited here on my blog–all the notes have been sitting around for six weeks, and it’s only the narrative that I’m adding later) describing where each pin went, to the best of my visual acuity.

Pins 1 and 2 obviously run to the motor, and it was pretty clear that they didn’t have any connections to pins 3-5. So I used my ohmmeter to measure the resistance in each direction between each pair of pins out of 3-5. I got this:

It was obvious that pins 4 and 5 were connected directly via the 7.5KΩ resistor. It was also apparent that there were diodes from pin 4 to 3 and from pin 5 to 3. That gave rise to this diagram:

Which made a lot more sense once I redrew it like this:

Pin 5 is the supply voltage, pin 3 the ground, and pin 4 the readout of the voltage divider between the 7.5KΩ resistor and the photosensitive diode. Voila!

Using the Optical Encoder

A 180Ω current-limiting resistor with a 5V supply would give ∼24mA of current through the LED, and that seemed a little high. I’m guessing that part of the circuit ran on 3.3V, making the LED current ∼14mA–a more reasonable value.

I wanted to shoot for 15mA, so 4.3V / 15mA ≅ 290Ω, of which 180Ω was already in the circuit, leaving 110Ω to add. I had a 120Ω resistor in my bin, so 4.3V / (180Ω + 120Ω) ≅ 14mA, which was close enough. I used the 120Ω resistor to wire pin 5 to the 5V supply, placing it in series with both diodes. (I figured its impact on the 7.5KΩ resistor and photodiode whould be negligible.)

Turning the encoder wheel very slowly and carefully and reading the voltage at pin 4 yielded a minimum voltage of .77V and a peak of 3.4V. (Alas, I don’t remember which was when the light was blocked and which when it was passed . . . probably the photodiode conducted and pulled it down to .77V when light was passing . . . but I don’t know that I really care.)

I didn’t really want to have to use an A/D converter input and deal with a 10-bit numeric value when all I needed to know was whether the light was blocked or passing. But I wasn’t wild about feeding a continuously varying analog voltage into a TTL input–it tends to make them overheat. Happily, the PIC datasheet (p. 102) revealed that pin A4 has a Schmitt trigger input, and my problem was solved.

A Schmitt trigger has hysteresis–the input signal has to rise above a certain point (the “high-water mark”) before it reads high, then fall below a lower point (the “low-water mark”) before it reads low. It’s intended for reading digital values from analog signals, it was exactly what I needed, and it worked exactly as desired. I fed the optointerruptor signal into A4 and got clean, predictable digital results.

Next Steps

That’s probably long enough for one post. Next: Building the eyeball assembly and programming the motor.

I haven’t touched the DIY rangefinder project for a couple of weeks, but I realized I also never wrote up my latest work on it.

Receiver Comparator

After my previous post about building two amplifier stages, I intended to use one of the spare channels on the LM324 as a comparator to “digitize” the amplified receiver signal and provide a clean input to the LogoChip. Unfortunately, the first time I prototyped it was late in the evening when my brain doesn’t work too well, and I built it just like the first two stages–as a linear amplifier. I was really surprised to see more analog waveforms on my scope when I expected sharp edges. At only 24kHz, I didn’t think it should be a slew rate problem, but I wasn’t thinking clearly and just set it aside for the night.

The next day, my error was obvious, and I pulled out the feedback resistor to let the op amp run open loop with infinite gain. It cleaned up the signal, although still not as much as I would have expected. Once the basic circuit was working, I replaced the fixed voltage divider with a 20k trimpot and tuned it as well as I could, trying to find the sweet spot to weed out all the noise but pass all the real signals.

I hadn’t seen it before, but now I wondered whether I was getting some false readings from noise, as John suggested he had encountered when working on similar circuits. I looked briefly at adding a low-pass filter to the circuit (it’s already high-pass filtered by the capacitive coupling from the receiver to the first amplifier stage due to the single-ended op-amp I’m using), but haven’t done it yet. First I wanted to connect it to the LogoChip and see what kind of results I got.

PIC CCP

An ultrasonic rangefinder measures distance by emitting a “ping” and counting the time until the echo is detected; dividing by the speed of sound translates the round-trip time into a distance. Because of the short durations involved, the easiest way to do this on a PIC microcontroller is with the “capture” section of the Capture/Compare/PWM (CCP) subsystem. It uses a high-resolution timer and interrupt circuitry to give a very precise measurement of how long something takes to happen.

I started with John Harrison’s CCP code from his srf_demo.txt example on the TechArt wiki LogoChip with Ultrasonic Sensor page. His code was using the PIC’s CCP module #1; but in my application, I was already using CCP1 to provide the 24kHz signal for my transmitter, so I started translating to use CCP2. The control and behavior of the two CCP channels are rather different, so it wasn’t a matter of simple substitution. Here’s what I ended up with:

• ultrasonic.txt – Program to drive ultrasonic rangefinder

Here’s the receiver section of the code:

;------------------------------------------------------------------------------
;   Routines for manipulating CCP2 and timer 3 for capture.
;------------------------------------------------------------------------------

constants [
    [CCP2CON $fba]                      ;   capture/compare/PWM 2 control reg
        [CCPxM-CAP-EVERY #0100]                 ;   capture every falling edge
    [CCPR2H $fbc]                       ;   CCP 2 register low byte
    [CCPR2L $fbb]                       ;   CCP 2 register low byte
    [PIR2 $fa1]                         ;   peripheral interrupt request 2
        [CCP2IF 0]                              ;   timer 3 interrupt bit
    [CCP2-PORT portc]                   ;   uses portc pin 1
        [CCP2-BIT 1]
    [CCP2-DDR portc-ddr]

    [T3CON $fb1]                        ;   timer 3 control register
        [T3CCP2 6]                              ;   timer 3 CCP mode bit 2
        [T3CCP1 3]                              ;   timer 3 CCP mode bit 1
                                                        ;   1x src CCP1+2
                                                        ;   01 src CCP2
        [T3CKPS1 5]                             ;   timer 3 prescale bit 1
        [T3CKPS0 4]                             ;   timer 3 prescale bit 0
                                                        ;   11 = 1:8
        [TMR3ON 0]                              ;   timer 3 enable bit
    [TMR3H $fb3]                        ;   timer 3 high byte
    [TMR3L $fb2]                        ;   timer 3 low byte
]

;   Initialize CCP by configuring timer 3 and enabling capture mode.
to ccp-init
    write CCP2CON CCPxM-CAP-EVERY       ;   config to capture every falling edge

    clearbit T3CCP2 T3CON               ;   set T3CCP to 01 to make T3 src CCP2
    setbit T3CCP1 T3CON                 ;       and T1 src CCP1

    setbit T3CKPS1 T3CON                ;   set T3CKPS to 11 to use 1:8
    setbit T3CKPS0 T3CON                ;       prescalar

    setbit TMR3ON T3CON                 ;   enable timer 3

    setbit CCP2-BIT CCP2-DDR            ;   set CCP2 (RC1) pin for input
end

;   Record starting value of timer 3 and clear capture flag.
global [ccp-before]
to ccp-start
    setccp-before ((read TMR3H) * 256) + read TMR3L
    clearbit CCP2IF PIR2
end

;   Wait for capture event and return duration.
global [ccp-after]
to ccp-wait
    waituntil [testbit CCP2IF PIR2]     ;   wait for capture interrupt
    setccp-after ((read CCPR2H) * 256) + read CCPR2L
    output ccp-after - ccp-before
end

I added code to send a ping and take a measurement:

;------------------------------------------------------------------------------
;   Top-level routines to tie it all together.
;------------------------------------------------------------------------------

;   For the sake of testing, activate on powerup.
constants [[standalone 0]]
to powerup
    pwm-init
    ccp-init
    if standalone [ pwm-on ]
end

;   Send a short burst of tone.
to ping
    pwm-on
    mwait 1
    pwm-off
end

;   Ping and measure time to reply.
to range
    ccp-start                           ;   record start time
    ping
    output ccp-wait                     ;   wait for echo and return duration
end

Wrote a little loop to display the results on the PC, and was disappointed to see that they really didn’t vary at all in proportion to the distance from the sensor to an obstacle. After a few minutes of head-scratching, I noticed that I hadn’t wired the comparator output to the LogoChip’s CCP input. Oops! And that’s when I realized I had a much bigger problem.

Overloading Port C1

The PIC’s CCP modules are implemented in hardware, and they’re hard-wired to specific pins. The input pin for CCP2 is the same as general-purpose pin C1–in fact, most if not all of the PIC’s pins have multiple functions that are selected by configuration registers.

My problem arose because C1 is already being used by the LogoChip firmware–as the Go/Stop input! Because LogoChip Logo isn’t open-source, I can’t see exactly how it’s being used, and have to guess what would happen if I tried to use it as a capture input. Since pressing a button attached to that pin makes the LogoChip stop executing user code and return to an idle state, I can’t imagine I’d have an easy time overriding that behavior and getting it to use the pin solely for CCP with no interference.

So what now? I need both CCP modules–one to use the PWM output to drive the 24kHz transmitter, and the other to watch and count time on the receiver. I don’t think I’ll be able to overload C1 with CCP2 for the receiver, so I’m left with a couple of options: swap the pins, or use CCP1 for both transmission and reception.

Swap the Pins

My first thought was to use CCP1 as the receiver (since its corresponding port, C2, is otherwise unused) and make CCP2 the transmitter (on port C1, the Run/Stop button). John says he has previously overridden C1 and used it as an output when the Run/Stop functionality wasn’t needed, so this should work.

In the long run, though, I’m a little uncomfortable giving up the Run/Stop button. I’d like to be able to integrate this technology into hobby robots, and I’d like to be able to leave them powered up but in an idle state, without having to duplicate the preexisting Run/Stop behavior myself in software. Swapping the PWM-transmit / capture-receive pins should work for a quick fix, but I’m not sure it’s where I want to be in the larger game.

Use CCP1 for Both Transmission and Reception

Alternately, I could overload CCP1 for both transmitter and receiver. There’s precedent–another student in class is using the Parallax PING))) ^(TM) sensor module, which has only three pins–ground, power, and bidirectional signal.

To do that, I’d need to make sure that transmission and reception don’t interfere with each other. Keeping transmissions out of the receiver circuit is easy–put a diode from the comparator output to the LogoChip so the transmitter signals don’t go “upstream” into the comparator.

Keeping comparator signals out of the transmitter driver is a little trickier, but I think I have a reasonable solution, based on something I was considering doing anyway. I’d like to be able to drive multiple sensors from one LogoChip, but there’s only one (er, two, maybe, sorta) PWM output available. To drive multiple rangefinders, I’d need to multiplex the PWM signal somehow–and there are plenty of ways to do that.

The most straightforward is to use a few LogoChip output pins to select which transmitter to drive and AND (or NAND) them with the PWM signal. Cake! And it tidily solves my receiver-interfering-with-transmitter problem–the receiver can dump whatever it wants onto the PWM output, but it won’t go anywhere harmful unless one of the transmitter select lines is activated.

Sounds like a win all around, and I think I’ll investigate it as soon as things calm down with the exhibit and I can get back to tinkering. It means a little more work on the software side (switching CCP1 back and forth between PWM and capture modes), but I’ve never been afraid of writing code.

Last night, I prototyped the transmitter circuit; today, I worked on the receiver. Coe’s design uses a two-stage op-amp circuit, with AC coupling on the input from the transducer to the first stage, to amplify the received signal before sending it to a comparator. I wanted to do the same, but I prefer to run from a single supply voltage, so I used an LM324 and added voltage dividers to bias the signal up to 2.5V.

First, I powered up the circuit from last night and measured the receiver’s signal on my scope. With the transmitter and receiver about 2” apart, the receiver signal was about 2V peak-to-peak, attenuating to about .5V p-p at 2’. If it continues to attenuate by a factor of 10 every 2’, then to measure distance out to 10’ (round trip of 20’), the received signal would be 2 * 10^-10, or .2nV. Let’s hope that’s not the case!

The Circuit

Each stage of the amplifier circuit is taken directly from the LM324 datasheet, “AC Coupled Inverting Amplifier” (although the two stages are DC coupled). The receiver’s signal is AC-coupled to the first amplifier’s inverting input, with a 2.5V bias to the non-inverting input.

I’m not sure why C₁ is needed on the bias voltage divider, but the output waveform was considerably cleaner with it than without, so I left it in. I also don’t know what R_B does, and Forrest Mims’ Engineer’s Mini Notebook on op-amp circuits didn’t show it but the datasheet did, so I left it in as well.

Values

The bandwidth-gain product for the LM324 is 1MHz, so a 24kHz input means the maximum possible gain is about 41.7. The gain is set by the quotient of the feedback and input resistors, and it worked very naturally to select R_F = 1MΩ and R_IN = 24kΩ.

According to Mims, C_IN should have a value of 1 / (2π f_low R_IN), where f_low is the lowest frequency to pass the filter. This gives C_IN = 1 / (2π 24kHz 24kΩ) ≅ 280pF–except the first time around, I mistakenly calculated using R_F (1MΩ) instead of R_IN (24kΩ), and got 6.6pF. I had a 10pF on hand, so I substituted it; but it was still far too low a value, as will be seen shortly.

I breadboarded the circuit on my workbench and measured about .04V peak-to-peak directly from the receiver element, with both transducers pointed at the ceiling. (That was about an 8’ round trip, so my dire prediction of .2nV was fortunately not the case.) Next, I measured only about .08V p-p at the output of the first amplifier stage, so obviously something was wrong. It was at this point that I added C₁, which brought the amplifier output to about .1V and cleaned it up dramatically–but with a gain of 40, it should have been more like 1.6V.

I was suspicious about the value of the AC coupling capacitor, C_IN, and began substituting different values for it, with the following results:

It looked like I must have miscalculated by an order of magnitude (at this point, I hadn’t yet caught my frequency error in the calculation), and 100pF was probably close to the best valued, but still a little too far down the knee of the filter’s response curve. .6V output was still a little low for a gain of 40, but within a range I was willing to accept, given that I was estimating the values by counting hashmarks touched by a dirty, wiggling waveform on my scope. I put the 1nF back in and called it good.

Second Stage

After honing the values on the first stage of amplification, the second stage was easy–just more of the same. I used all the same values, but omitted the AC coupling capacitor, since I’m happy to DC-amplify around the 2.5V bias. The second stage gives me a trapezoidal waveform (clipping both the top and bottom of the transducer’s sine wave) running rail-to-rail of the LM324′s advertised output capacity–from 0V to about 4V. Tomorrow I need to run that through a comparator to clean it up just a little more, and then steal John’s capture/compare LogoChip code to start timing the echoes.

Ultrasonic rangefinders detect objects and measure distance the same way as a bat: Emit a high-pitched “ping” and measure how long it takes the echo to return. The speed of sound in air is nearly constant (ignoring slight variations due to air pressure and humidity), so the time from ping to echo translates directly into the distance to the object.

I’m interested in ultrasonic rangefinders for both hobby robotics and our TechArt final project. They’re available commercially, but $25 each adds up pretty fast if you need multiples to establish a view all around a bot or across the wide front of an art installation. All Electronics has transducer elements for $1 each in quantities of 10 or more, so I ordered a batch of them in hopes of building a rangefinder myself. At $2 each (two transducers, for send and receive), I can add a fair bit of supporting circuitry before hitting the $25 mark.

The Plan

I’m basing my circuit on a design by Gerald Coe at http://www.robot-electronics.co.uk/htm/srf1.shtml, and adapting it for different design goals. His circuit uses a dedicated PIC to provide the oscillator, a MAX232 to generate 16V to drive the transmitter, and 40kHz transducers. For now, I want to run my rangefinder from an existing LogoChip that’s also doing other work, avoid the complexities the MAX232 adds, and use transducers with a different nominal frequency. Later, I might build separate modules intended to stand alone and run with very low power.

Initial Testing

According to a comment on the All Electronics page for the transducers I ordered, they run at 24kHz. The first order of business was confirming that operating frequency.

I hooked my function generator to my frequency counter and scope and dialed in 24kHz, to make sure I was in the neighborhood before connecting the transducer. I then connected one transducer to the function generator to serve as the transmitter (with the frequency counter still attached), and the other transducer to the scope to serve as the receiver.

When I pointed the transmitter at the receiver, a signal showed up on the scope; when I pointed it away, the signal abated. I could bounce it off my hand and receive it, but not off the ceiling. (I’m guessing the elements weren’t aimed well enough and/or the amplitude wasn’t high enough.) And changing the oscillator frequency confirmed that 24kHz is indeed optimal.

So the project is at least possible. That’s a good start!

Connecting the LogoChip

I really didn’t feel like disassembling my balance-bot project, so I’m sure glad I bought several PICs! I built up a breadboard with another LogoChip on it and verified operation. Then I took my motor-control PWM code and cleaned it up to generate a single frequency signal.

Testing with my frequency counter and scope hooked up, it looks like I need timer 2 with a prescalar of 1 and a period of 82 to get as close as possible to 24kHz. Hm, 82 * 24k ≅ 2M, which tells me that I really don’t understand what timer 2 is using for an input clock. Wait–yes, I got it. The PIC has an internal 4x increase in oscillator speed, so the 2Mhz timer oscillator leads to the 10Mhz clocking.

Driving the Transmitter

I first tried powering the transmitter element with an NPN driver, for simplicity and to allow experimentation with the drive voltage:

I connected the receiver element to my scope to detect the signal, and was surprised to detect nothing. I looked back at Coe’s schematic and noticed that he drives his transmitter in a push-pull arrangement using the MAX232, so I scrounged around for something with totem-pole outputs that I could use to test. The quickest thing I could come up with was a 7404:

And this time, I did show a received signal on the scope, albeit a slightly weak one; so I guess the push-pull drive is necessary.

I’m not satisfied being restricted to a 5V drive, because Coe specifically mentions using 16V to get adequate detection at greater range. However, I’m not sure I have anything on hand that will do exactly the right job and which I’m happy using. None of the options quite work out:

• The 74xx chips with “high-power output” and 754xx peripheral drivers run open-collector, and I don’t see a good way to use that to provide push-pull.
• The 754410 H-bridge driver adds about $2 to the cost–not bad, but I’d rather avoid it if I could.
• The MAX232 adds about $1 plus numerous supporting components–and Coe mentioned that it generates enough noise that he shut it down after each ping to keep it from interfering with the echo detection circuitry.

I’ll probably prototype with the 754410 since I have some on hand, and keep looking for other options.