I'm looking to a simple solution to keep the position of a robot. It has two DC motor and one wheel encoder for each. The encoder are incremental type.

I need to be able to get the current count of increment from an atmega.

I found some chip like the LM628/629 who will do great job, too great in fact, because it cost ~50$.

Do you know a dedicated IC that has only the count (in both direction) features for a wheel encoder, Or is it possible to make à simple one with an attiny ?


"Do you know a dedicated IC that has only the count (in both direction) features"?

You may be surprised to learn that a few simple, cheap, generic logic chips are sufficient to decode a rotary encoder -- it doesn't require some special chip specifically customized for rotary decoders. The Codewheel Generator Page has a few relatively simple circuits that decode the 2 rotary quadrature outputs into a "direction" and "count" outputs. Those outputs can be wired into the "direction" and "clock" inputs of any up/down counter -- such as, for example, the CD4029, the CD4516, the CD40193, 74HC193, etc.

"is it possible to make à simple one with an attiny"?

Yes, you can make a simple quadrature encoder with an ATtiny. Some tips for connecting a quadrature encoder to a Atmel chip and decoding it in software are at:

If you have relatively few pulses-per-second, you might be able to run the 2 signals from each encoder directly into your main ATmega and use the above techniques to do it all in software, without any external conversion hardware.


Wheel encoders are very easy to use for dead-reckoning systems. If you have just a slotted wheel and two detectors it'll be a quadrature encoder; you call one of the signals your clock and the other one your direction. Get both signals into your microcontroller and either set it up so that it counts clock pulses (i.e. an event counting algorithm). Whenever you get a clock pulse, check the direction line. It will always be '1' for one direction and '0' for the other.

The fancier (more expensive) encoders are usually Grey code encoders and are less suitable for dead reckoning, although they will give you better dead reckoning position due to their higher accuracy. You could feed the output of one of them into your microcontroller and have an interrupt or timer that reads the position of the wheels and determines how far and in which direction the robot moved. This is a more complicated solution.

Be aware that dead reckoning systems do drift over time and unless you have some means of resetting the dead reckoning system your robot's idea of where it is in space will become more and more inaccurate.

  • \$\begingroup\$ I understood how it works. I want to know the possible hardware to do it. i.e : Is there something easiest than a microcontroller ? \$\endgroup\$ – jojo l'abricot Sep 26 '10 at 18:13
  • 1
    \$\begingroup\$ A pair of wheels phased 90 degrees apart is a Gray code (not "Grey"). You will not often find gray code encoders with more than 2 bits, mainly because of the decode complexity/incompatibility. Their accuracy isn't any better than a 2-bit system, it's just that you get a larger range of "absoluteness" \$\endgroup\$ – Jason S Sep 30 '10 at 12:28
  • \$\begingroup\$ I always considered the 90 degree detectors a "quatrature encoder" -- in industry we had many 16 bit gray code (I'm Canadian, grey/gray is one of those fuzzy points of spelling here) encoders and yes, for exactly that reason: you wanted absolute position information with a high degree of resolution. \$\endgroup\$ – akohlsmith Sep 30 '10 at 12:52
  • \$\begingroup\$ to answer jojo l'abricot's comment: You want to do dead reckoning for a robot without a microcontroller? Take one of the bits into the "direction" input of an up/down counter. Take the other bit into the clock input. I don't think you can get too much simpler than that, although I also don't think you'll be able to do much with a count value if you haven't got something (i.e. a microcontroller) to understand it. \$\endgroup\$ – akohlsmith Sep 30 '10 at 12:54
  • \$\begingroup\$ @AndrewKohlsmith: Gray code is named after a person, not a color, so there's no ambiguity of spelling. \$\endgroup\$ – endolith Dec 12 '11 at 22:50

One approach might be to use a programmable logic device as a gray-code ripple counter with enough stages that you can simply poll the value at a convenient rate and not lose counts. Note that one advantage of a gray-code ripple counter over some other approaches is that there's no danger of noisy inputs glitching the counter provided that no input changes when the other input isn't stable.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.