Optical shaft encoder question

Hey all--
I've been pretty quiet here but I started rebuilding my autonomous rover a few weeks ago since I've got some down time (recently graduated
student about to travel for a month).
I've built a small, tricycle drive robot with a sonar head. For odometry, I've glued a 6 CPR optical encoder wheel onto the hub of my drive wheel. I used a PNP photointerruptor focused at about 2mm from the hub, with a hood made of electrical tape to block out ambient light. The output of the phototransistor is squared up through a Schimmt-triggered hex buffer. The setup works well, putting out a fairly clean, regular pulse train. But there does appear to be a small amount of noise between some transitions, as about every 10 pulses or so it counts an extra pulse. It seems to be random so I don't think its the encoder disk. I've tried adding a bypass cap, but a few different values (.01uf, .1uf, even 10uf) didn't seem to have any effect. I'm not an EE so I'm not sure what else to try. I'd rather not use a 555 if I can help it, because I'm short on space.
Thanks for any tips.
--
|\/| /| |2 |<
mehaase(at)sas(dot)upenn(dot)edu
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Jitter with single-channel encoders is pretty common. The jitter occurs because even with a Schmitt trigger there can be noise from the photocoupling.
You didn't actually mention that it's single-channel but the description sounds like it. If that's the case, how about adding another transistor and LED, and buy either the LS7083 or LS7084 chip from USDigital.com (http://www.usdigital.com/products/ls7083-ls7084/). They're about $3 each, and have circuitry in them to clean up the signal. And since you're now working with a quadrature encoder, you'll have 6X4 (or 24) transistions, which is a little better resolution.
-- Gordon
Mark Haase wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

You don't say how you are processing the signals. The problem, as you have spotted, is that transitions may not be 'clean' - consider what happens if you stop moving exactly on a transition point, and then random noise will cause a train of signals.
IMHO the very best way to deal with this is to build a state machine for the edge transitions in hardware - then these unwanted transitions merely result in dithering between two states. If you attempt this in software, then your 'reaction' time (worst case interrupt response or sampling loop period) must be less than the smallest possible glitch, such that you respond to all transitions. This can be a severe constraint on robots with a simple single 'brain'. You can slow the response of the phototransistor, but if you slug it too much then you will lose counts at speed.
These days the simplest way of doing this sort of thing is to use a dedicated 8 pin micro (avr, pic - $2) which runs the state machine and maintains a fairly long counter for position. With an internal clock of a few MHz it will cope with any glitch. This approach removes a time critical operation from your main 'brain', which can simply 'ask' for the current 'position' when it needs it.
Have fun
Dave
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

The Schmitt trigger on the hex buffer sounds like it's doing the conditioning, which it should be able to haver a fair crack at provided the noise from the sensor is less than the hysteresis. The hysteresis is there to deal with exactly the situation you describe - stopping exactly at the transition point.
To the OP - how much hysteresis are you using on the Schmitt triggers? If it's not enough and the IC doesn't let you tweak it, you could make a Schmitt trigger from an op-amp and tweak the resistors to get the desired result. This is all /much/ easier with an oscilloscope to see what's going on.
Tim
--
You are being watched. This gives you power.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.