October 1, 2006, 11:29 pm
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?
2. 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
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?
2. 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
Re: two questions about quadrature decoders
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:
<http://www.usdigital.com/products/ics.shtml>
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
Re: two questions about quadrature decoders
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
Re: two questions about quadrature decoders
[snip]
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
Re: two questions about quadrature decoders
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. :)
http://www.newmicros.com/
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 http://www.sparkfun.com/
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. :)
--
D. Jay Newman ! Author of:
jay@sprucegrove.com ! _Linux Robotics: Programming Smarter Robots_
http://enerd.ws/robots/ ! "Heros aren't born, they're cornered."
Re: two questions about quadrature decoders
either reflective or breakbeam sensors. They also have the sensors
(single or quadrature) You could even hook tem up to a Serializer (from
the same site) to control the motors, sensors, etc. It even includes
H-bridges. Hope it helps.
Ringo
D. Jay Newman wrote:
Re: two questions about quadrature decoders
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:
http://www.fpga4fun.com/QuadratureDecoder.html
Later,
Daniel
Re: two questions about quadrature decoders
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
Re: two questions about quadrature decoders
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
Re: two questions about quadrature decoders
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:
<http://www.geology.smu.edu/~dpa-www/robots/sr04/sr04.html>
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.
<http://www.geology.smu.edu/~dpa-www/robots/mpeg/sr04_sq_001x.mpg>
Here is a link describing how to add home-brew encoders to a Pittman
gearhead motor, both single channel and quadrature:
<http://www.geology.smu.edu/~dpa-www/robo/Encoder/pitt_html/encoders.html>
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:
<http://geology.heroy.smu.edu/~dpa-www/robo/nbot/>
but not necessarily needed for accurate speed control and navigation,
like on SR04:
<http://www.geology.smu.edu/~dpa-www/robots/sr04/index.html>
best
dpa
Joe Strout wrote:
Re: two questions about quadrature decoders
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
Re: two questions about quadrature decoders
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
Site Timeline
- » Mars Exploration Rovers Update - September 29, 2006
- — Next thread in » General Robotics Forum
-

- » 802.11x, PCMCIA (or USB) adapter with RSSI and external antenna
- — Previous thread in » General Robotics Forum
-

- » evoMUSART 2013: First CFP (with correct dates)
- — Newest thread in » General Robotics Forum
-

- » Re: Exclusive: U.S. [Illegally?] lets China bypass Wall Street for Tre...
- — The site's Newest Thread. Posted in » General Metalworking
-

- » Próba ciśnieniowa zbiornika: bezpi eczeństwo
- — The site's Last Updated Thread. Posted in » Engineering Science (Polish)
-


Subject







