I built an optical shaft encoder using a photointerrupter. The photo interrupter's output varies from about 1.5V to 3.5V, which I'm running through a Schmitt-triggered hex, non-inverting buffer to clean the signal (ie 0-5V).
When I hook this up to my HC11's input capture port (IC2), I get anywhere from 5 to 30 pulses for each segment that the photointerrupter sees.
Any suggestions on how to filter out these jitters?
I'm using the circuit from "How To Build Robot Drivetrains" if that helps. Thanks
Hi mark -- I believe I'm one of the author's of the book you're referring to. What do you mean by "segment". Do you mean that for each interruption of the photointerrupter you get 5-30 pulses? Are you moving the encoder by hand, or running a motor?
As an aside, oscilloscopes tend to be pretty valuable in these situations. That way you can verify the actual output from the encoder circuitry.
I was originally turning the wheel by hand, with an LED hooked up to the output of the buffer to ensure basic operation.
I added a .01uF decoupling cap across the photointerrupters output, and added a 1Mohm resistor across the input and output of the buffer for added hysteresis. This has reduced my "jitter" problem to just 3 pulses for each segment transition. I wrote this result into the code, and I got very accurate odometry when the motor runs slowly.
I then tried running the motor fast and the odometry got out of whack again, which has taught me that when testing it I need to test it with the motor running. I did get a cheap, handheld scope (TPI 440, heard of it? comments?) to look into this. At this point, though, I'm sick enough of calibrating the odometry subsystem that I've moved on to something else and I will come back to odometry later to fix it up.
Unfortunately I'm headed back to school soon, and I'm putting this work aside until the first holiday break, but I'll report back then with results.
PS.. Sorry for forgetting the name of your book! It has been extremely helpful, though. Thanks for writing it! I recommend it often.
It's not uncommon to get "jitter" in single-channel encoders, and the best way to handle this is write "debounce" code in your software. You basically look for one nenative-going pulse in a given time period, and ignore all others. You can calculate what that time should be given the number of slots in your disc, and the maximum speed, in seconds, of your motors. Add some percentage for reasonable overhead.
Example: If there are 24 slots and the motor turns at no more than 2 rps, thats 48 transitions per second. Add say 20% overhead, or about 60. Find the period, and the result is 16.6 milliseconds. (Anyone, feel free to check my math.)
If your MCU is overtaxed already, though, you can do this with a pulse-stretcher circuit. There are a ton of switch debouncer circuits out there using discrete components, such as the 555. If you use something like the 556 (dual) or 558 (quad) you can reduce the part count a bit.
If you built a quadrature decoder, it is FAR easier to use a chip designed to filter and decode the signals. LSI makes one, and is resold by US Digital
for about $3.50. Worth every penny.
-- Gordon Author: Robot Builder's Bonanza Budget Robotics: