two questions about quadrature decoders

I'm looking to count revolutions on a fast (e.g. 2000-4000 RPM) motor output shaft. I can easily put in a couple of optical switches and an interrupt disk. This leaves me pondering quadrature encoding:

  1. Do I really need to bother with quadrature encoding? Of course you have to for something like an input knob, where the user may turn it in either direction. But in this case, I'm in control of the motor (it goes through a worm gear before getting to user-accessible outputs, so the user won't be able to rotate the motor anyway). Can I simply count the pulses from a single opto switch, and assume that I know which way I'm driving the motor? Or will I run into problems where the motor continues to turn in the old direction for some (unknown) number of pulses after I've told it to reverse?

  1. Assuming I do need to worry about that, and assuming that quadrature encoding is the best way to go -- can anyone recommend a good (cheap but reliable) quadrature decoder chip? It would need to track something like 100-200 pulses per second, which doesn't seem all that fast in the world of electronics.

I'm a complete newbie to this area, so any pointers or resources you can share would be greatly appreciated.

Thanks,

- Joe

Reply to
Joe Strout
Loading thread data ...

If you can take the time to be sure that the motor has really stopped, you can do it with a simple tachometer.

Joe:

I personally use the LS7366, which is not easy to obtain. I'll be ordering a bunch of the LS7366's next week. It may be over kill for your application. We are using a Solutions Cubed motor with a gear ratio of 30:1 and a US Digital shaft encoder with 300 steps per revolution -- a total of 30*300 = 9000 steps per wheel rotation. Thus, we need something that can keep up tens of thousands of steps per second. A LS7366 may be total over kill for your application.

US Digital sells a bunch of the LSxxx chips:

You might try one of them.

At 100-200 pulses a second, almost any microcontroller can keep up. Learning how to program a microcontroller (PIC/AVR/etc.) is a very useful skill to acquire in this hobby.

-Wayne

Reply to
Wayne C. Gramlich

A simple encoder is good for position and velocity information as long as your are continuously spinning in the same direction. It becomes highly inaccurate if you stop or reverse directions. When the motor is nearly stopped, small vibrations may trigger the switch on and off, falsely indicating motion. Likewise, you note that direction reversal may cause inaccurate counts.

This page may be of interest to you:

formatting link
Later, Daniel

Reply to
D Herring

Quadrature is not always required but it actually makes many things a lot easier, and isn't all more difficult to obtain. Wayne provided the URL to US Digital and you should definitely poke around their site. They have some non-industrial encoders that are very affordable, and with the shaft-through option you can often just attach them on the output shaft of the motor with stick tape, assuming the shaft is long enough.

A 4000 rpm motor runs at about 66 rps. You can get encoder discs down to about 12-16 counts per rev, which means over 1,000 pps. It would have to be a very coarse code wheel to put out only 200-300 pps. Still, that's only 1kHz, which is very slow. And this is at 1X resolution; quadrature allows you to count at 2X or 4X.

I'd look into ordering an encoder with maybe a 32 to 128 cpr disc. You ought to be able to get the lower-end LSI chips interfaced to your rig quite readily. These chips have pulse stretchers and other built-in features that improve accuracy and dependability, yet they're only $3 in low quantity.

-- Gordon

Reply to
Gordon McComb

Good to know, thank you.

Indeed, for my purposes I'd be perfectly content with a disc divided into just two sectors, one clear and one opaque. But I worry that this might be unbalanced, causing vibration, so I'll make one instead that's got four sectors, resulting in a balanced wheel. That'll be higher resolution than I need by quite a bit, but that's OK.

Right. That gives me hope that, if some simple decoder chip can't be found, I may be able to program a cheap PIC to do the job.

They sound great. Can you recommend a specific part number? I'm very new to this, as you know, and I wouldn't know where to find the chips you describe. I've tried searching at Mouser for things like "quadrature decoder" but had no luck.

Thanks,

- Joe

Reply to
Joe Strout

OK. I may have to simply experiment to find out if that's doable in my application.

Sounds like it. In my case, I have some control over the gearbox (which has a ratio of 336:1), so I'm planning to put the encoder directly on the motor output shaft. That's why I can get away with such a low-resolution encoder, and still get the resolution I need on the final output shaft.

Thanks, that looks promising. (Gordon, please ignore my previous query about where to find these chips -- your message arrived at my news server before Wayne's.)

Agreed, and it's on my to-do list. This would certainly be a good application for me to cut my teeth on.

Do you think a microcontroller could accurately do that quadrature decoding, and at the same time do other things, like serial communications? Or is that asking too much, and I should expect to dedicate a chip to just watching the quadrature (or tachometer) pulses?

Thanks,

- Joe

Reply to
Joe Strout

Joe:

The short answer is "yes" and the longer answer is "depends". It depends upon how fast you want to do serial communication, how fast the microcontroller is, how fast the quadrature is sending pulses, etc. In short, I think a PIC16F688 microcontroller and a L298D H-Bridge would be just fine for your application of driving a Tamiya worm gear. The 'F688 has both a UART and the ability to do 1 channel of pulse width modulation.

-Wayne

Reply to
Wayne C. Gramlich

Hi Joe,

The encoders used on my SR04 robot are single channel (not quadrature) with six divisions per revolution, mounted directly to the motor shaft.

Scroll about half way down the following link for a picture of the home-made encoders:

That gives about 80 counts per inch of travel at the wheels.

The software works as you describe, i.e., the encoder counts are read and reset 20 times per second, and they are assigned the sign (pos or neg) of the most recent motor command.

While it seems like this technique would lose counts as it passes through zero, as a practical matter is doesn't seem to.

Here is a video of the robot navigating around a 10 foot square with some stationary and moving obstacles in the way, that illustrates the nominal accuracy of the system.

Here is a link describing how to add home-brew encoders to a Pittman gearhead motor, both single channel and quadrature:

I was actually quite surprised that the single channel encoder scheme that gets the motor direction from the last motor command works as well on SR04 as the quadrature encoders used on some of my other robots.

That said, quadrature data is very nice, and probably required for a two wheel balancing robot like nBot:

but not necessarily needed for accurate speed control and navigation, like on SR04:

best dpa

Joe Strout wrote:

Reply to
dpa

That's a very cool robot, and a great write-up -- thanks for taking the time.

Also, I like the idea of mounting the encoder or the rear shaft of the motor. In my particular case, I think I have room to mount it on the front side, but in other cases I may not. That's a neat trick.

Good to know. That encourages me to try this approach. I have a gadget on hand with two hardware counters; if this can work, that'll make my life much simpler in the near term.

Thanks again. I was intrigued by your comment that it's usually easier to buy a gearhead motor that's close to what you want, than to assemble your own gear train. I had been thinking lately about doing exactly the latter, as a cheaper and more flexible way to get whatever performance is needed. As you pointed out, finding the right gearhead motor often requires a bit of luck -- making your own seems more repeatable. But if finding suitable gears and other hardware is difficult or expensive, then maybe it's not such a good idea after all.

But I believe you wrote that article in 2001... has your view on this changed any since?

Thanks,

- Joe

Reply to
Joe Strout

Another option for fast quadrature decoding is the *Pod's from New Micros, Inc. I don't know the upper limit for an IdoPod because I haven't hit it yet. Maybe next year. :)

formatting link
The TinyPod, PlugAPod, IsoPod, and ServoPod are all based on the same processor family, and by default you program them in Forth with extensions. ...

Microcontrollers are fairly easy to program, though you typically have to pay more attention to details.

There are a couple of interesting new micros out there: - The Propellor chip from Parallax - The ARM Basic stamp (I forget the exact name -- it's available from

formatting link

At 100-200 pulses per second almost any micro could count pulses and communicate at the same time. It should also be able to do some other stuff in the background just to keep from being bored. :)

Reply to
D. Jay Newman

Reply to
Ringo

Not really. Only in the sense that I'm now more inclined to spend the money to buy new motors with integral gearheads and encoders, rather than trying to make do with surplus. Still, a Pittman gearhead motor for $300 new or $30 surplus, it makes a difference!

best dpa

Reply to
dpa

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.