The easiest way to get speed and position from a wheel encoder is a
microcontroller. There is a frequency to voltage conversion chip that would
give you speed and you could build counter circuitry to track position but
it would much easier with a microcontroller.
I 'm planing to use a microcontroller to control H-Bridges for 2 DC motors,
monitor wheel encoder feedback and check motor current and will communicate
to the main processor through a serial link. This motor-controller will
generate error messages for stall conditions and task complete responses.
Everything necessary for robot motion but the will.
This way the motor-controller can be told to move at a specific speed for a
specific distance or told to rotate a specific number of degrees, while the
main-processor continues executing its 'Prime Directive' and monitoring
"Dave" <blank> wrote in message
Thanks for reply. I only have one microcontroller right now unfortunately
and my robot is controlled with a Basic stamp and I don't think it's
possible to count the pulses from the encoders and command the servos for
movement simultaneously, at least I haven't found a way to do it. I could
use a dedicated servo controller to pulse the servos which would free up my
stamp to monitor the encoder input but my robot also has numerous other
sensors and devices that my stamp has to monitor and control. Another really
nice option is that Parallax just came out with their PWMPAL which would
definitely solve my problem. But both of those options are $$$ and I was
hoping for a cheaper solution.
This is my first attempt at wheel encoding and the primary motivation right
now is straight line tracking. I figure if I can keep count on the number of
pulses or the frequency of each wheel I can write software to equalize the
speed of the wheels and adjust automatically as it drifts from day to day,
you probably know how fickle servos can be.
If I could find an inexpensive chip that would count the pulses and even
give the frequency of the pulses (preferably a serial device that wouldn't
take more than a few I/O) I'd consider myself to be in heaven.
Using feedback to close the control loop is the only way to go.
I can't speak about the 'Stamp' microcontroller, I use the Atmel AVR line. I
would program an ATTiny-12 ($1.94). You can build a programmer for about
$4.00 and all the software is free. The big cost here is the learning
Analog Solution (Speed)
You could use 2 frequency to voltage chips
(http://cache.national.com/ds/LM/LM2907.pdf ) and a couple comparators.
This would provide a 'left too fast' and 'right too fast' outputs.
Digital solution (Position)
You could use an Up/Down counter 74LS193 to count the pulses from each
wheel. (It has separate up and down inputs) 'Or' the lower 3 bits with
diodes to generate the Error output (Too left or right) and the High bit to
indicate Left or Right. This would support a maximum error of 7 pulses and
I'm not sure what would happen if Up and Down came on at the same time.
P.S. Excuse the name change, I thought I had it right the first time.
"I'm pullin' for you; we're all in this together", Red Green
"Dave" <blank> wrote in message
If you are using the stamp, you can interface an ls2166 or ls7266
http://www.usdigital.com/data-sheets/ls7266r1%20Data%20Sheet.pdf uses a lot
of port pins, but adds a lot of flexibility. This will give you absolute
If you are trying to track speed, for velocity feedback, I think there are
commands on the stamp to read a frequency or pulsewidth. You should be able
to interface 1 channel of a TTL encoder to a pin on the stamp. If you assume
you know the direction of rotation, this method works.
If you must know the direction, there are chips on the same site which
convert an encoder to step/direction. This would allow you to read pulses or
direction, but the stamp would only give you an approximation.
What are you trying to achieve by counting the pulses; speed or position?
If it's speed your interested in then rather than counting the pulses you
could time a pulse. I believe there is a command to do this on the STAMP.
The speed is simply the reciprocal of this value; the shorter the pulse the
faster the speed.
You might be able to cram all the code in to the STAMP if you plan and
re-code a bit.
If I remember correctly; when driving servos you only need to provide the
pulse (1-2ms) every 20ms. Any longer than that and they go in to a
power-saving mode (don't hold their position).
You might be able to 'fudge' it so you provide your servo pulses (say 4)
this leaves us with a minimum of 12ms to spare (20ms - [ 4 * 2ms]). We can
use this 12ms to measure our pulse width and so get an idea of speed.
To improve things look at increasing the number of the teeth on the encoder
and this will reduce the pulse time (making it fit into our limited window).
Just a thought.
"Dave" <blank> wrote in message
I'm mainly interested in speed for starters, hence the desire for frequency.
I suppose measuring the length of the pulse with the stamp PULSIN command
could work but according to the docs it only measures the duration of the
high time or low time whichever you specify, not the entire period (which in
theory should just be double that). But still, even though this isn't the
true period perhaps it could be useful for determining speed. I have the
luxury right now of having a 2nd borrowed stamp, I'll try that. Thanks for
the suggestion. I'm seriously considering at this point just getting a 2nd
micro to do the work, it's about time I started learning to program the
Atmel chips anyway and have been thinking about it for a long time (STK500),
they're dirt cheap which is right up my alley. Best regards,
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
You are right the stamps count the length of high or a low pulse.
and since these are rarely 50 /50 duty cycles measuring one or the other is
For more predictable results I measure both. Measure the high and add it to the
low and take the reciprocal to get the frequency.
Actually you probably don't need to take the reciprocal, just use the period as
a speed reference.
before you buy a second stamp, if odometry is what you are after, look at
the IsoPod, MiniPod and family.
an IsoPod can read 6 quad encoders w/o extra hardware, generate 12 channels
of PWM, and has 8 channels of 12 bit A/D.
"Dave" <blank> wrote in message
The newmicros stuff looks impressive. Of course I started with the stamps as
they are great for beginners but they are rather limited and I'm at a point
where I do need to graduate to something else, I'll consider the "pods" as a
possible upgrade path. Thanks.
Just went and checked prices on DigiKey, to see if what I suspected
might not be true here: I've got something I'd like bring up about this
"dirt cheap" concept.
Another Basic Stamp $59
Another STK500 $79
So you're one $59 committed with your one old micro, and talking about
using another $59 old micro for a while to see if you can fix the
problem. But you might spend $79 (to be able to use $2 chips which will
sure cost more when put on a board with support parts, etc.) instead.
The (somewhat self serving) point I'd like to make, is:
By comparison, for $89, you could buy a DSP56803 based MiniPod(TM) and
do the whole thing. This board has many times more computing power of
your $59 and $2 ones put together, and actually has the feature set you
need to do the task you're working on.
Most significant to this discussion: The new micro has quadrature
decoders to read the wheel encoders in built-in hardware. So the
original hardware thing you were looking to add on to the old one is
built in to this new micro.
Also significant to this discussion: The new micro also has multiple PWM
hardware outputs which can drive your RC Servos directly. So the
original thing that is hard to do 2 of at the same time on the old one
is built in to this new micro along with a multitasking operating
Finally, there's more to making something go straight than just reading
its speed, and making a proportional adjustment, which was the point of
the Navigation above Odometry thread, if you care to go back and check
it. (See Gary Lucas site in particular. There's a very neat simulator on
his site that will show you want track an uncorrected robot will take)
You're going to need PID and trignometry. Your old micros are not really
capable. However, software described in that thread is already worked
out, and available upon request for the new micro.
So to wrap up my point, I'd like to suggest this:
Adding patches to an old micro that can't do the job is not as cost
effective as getting a new micro built to do the job in the first place.
You're right the investment of the STK500 is not insignificant but it's the
cost of the micros that I was looking at, they're so cheap I could buy them
like candy for any little thing I want do. And I plan on doing alot
microcontroller programming for many things in the coming years. However you
guys have me taking a serious look at the newmicros stuff for robotics
purposes particularly. Those look really nice. Of course in hindsight it
would've been a better choice but as mentioned in another post I started
with the stamps because of ease of use and they have been good for that but
I'm sorely feeling the limitations as my robot projects get more
sophisticated. I think I found the robot navigation thread you're referring
to, I'll check it out. I couldn't find anything from Gary Lucas. You have a
link to his site? Thanks.
That's one of them. See also
for the motion applet.
Randy M. Dumse
Caution: Objects in mirror are more confused than they appear.
On Tue, Nov 04, 2003 at 11:10:40PM -0600, Randy M. Dumse wrote:
But the STK500 is kind've the Cadillac board. It's nice, but you
don't need to spend that much. For example, the programmer can be as
simple as this:
This is built from spare parts - very low cost. Some other
programming options can be viewed here, at varying price levels:
So ... I think your comparison might be a bit weighted.
Even if one does buy an STK500, it's a one time cost. You don't have
to buy one for every project - you only need 1 (if you want one at
all). Thereafter, you can simply buy another chip at $3 or $4 each,
or buy 100 at a time, they are cheap enough to do that. 100 ATmega8's
will set you back only $375 at Digikey prices. Just think of all the
projects you can do with those? And these aren't impotent little
chips either - they run at 16 MIPS, come in an easy to work with 28
pin DIP package, have 8 10-bit A/D converters, 8K Flash (program
space), 1K SRAM, on-board EEPROM, hardware I2C, SPI, UART, can run
with _no_ external support parts (has built-in internal oscillator -
no xtal needed), etc, etc.
By comparison, a Basic Stamp II runs at 0.004 MIPS, has only 32 bytes
of RAM, 2K of program space, and you still need a board to plug it
And if you still want to program in BASIC, grab up a copy of
BASCOM-AVR for around $80 - again, a 1 time cost. But if your code is
less than 2K, you can use BASCOM-AVR for free. Only when your code
size goes over 2K do you need to purchase the licensed version. This
is great since you get to try it out before you spend your money.
I'm not saying an Isopod or Servopod is not worth it - they look very
nice and your prices are respectable. Just trying to add a little
balance to the equation.
Brian Dean, email@example.com
BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
Oh, sure! ... I don't mind the comparison a bit. I was just using the
items the original poster had mentioned in my comparison. In fact, I'm
glad you give a credible counter point.
I was left wondering if anyone really could use a $2 chip, as was
suggested above. I figure comparisons like that are pretty bogus. You
can't just _use_ a $2 chip without some PCB mount it on, and a power
supply, and a low voltage detector for reset, and a..., and a..., and so
on. So comparing a chip to a board is always misleading.
For reference, you can get the core processor for the 'Pod boards for
$10 to $15. So they're not so onerous viewed "bare" that way.
But with this DSP chip, there's no such option as just using a simple 2
layer proto board to hook it up, because you need a good power and
ground plane, or the timing inside the chip gets off (Mot specifically
recommends against this.) So you need 4 layer minimum to reliably
operate the DSP chip. So using a $15 chip with a one-off 8-layer board
like we've made the IsoPod with, will set you back about a grand. (And
that's just a board to stick it to. We haven't even begun to address the
value of the languages we provide.)
Your comments about <$4 28-pin DIPs not even needing a crystal makes the
point well. It still should be tempered with the question, what is
cheapest little board you can buy commercially with one of these on
But back to following on the original post's theme, can one of these
28-pin DIPs really do two channels of servo control, with encoder
counting, PID control of the speed, and odometry and navigation, and do
it all in a high level language? For instance, the Basic you mentioned?
Let me say, I'm sure one of the larger AVR chip could be made to do the
whole show, but that job sure sounds like one for only a well-skilled,
real-time, interrupt-driven, multitasking-experienced assembly language
programmer to me.
drifting off topic a bit, but it also how much resource you want to tie up
doing timing things, when you could use a micro like the 5680x or 68332 with
a lot of timing capability. This leaves your processor open for other
Well, you make a good point and remind me I should respond. While it is
true the bigger 'Pods (IsoPod(TM) & ServoPod(TM)) can do 26 RC Servos at
once, it is more impressive to know, that is in set and forget hardware.
Some day I'll have to sit down and see how many additional RC servos I
could drive in software. I'm pretty certain I could drive all the
available GPIO pins, for another 22 RC Servos in software, and still
have processor time left over. However ostentatious it sounds, 48 RC
servos would probably be closer to the "apples-to-apples" comparison.
The 332 TPU is quite a remarkable timing unit. It's also quite the bear
to figure out.
I prefer the larger processors for dedicated applications for basically
one reason, the large linear address space. I've just begun using MCORE
for that reason, and I'm also looking at the ARM processors.
well for avr's you don't want a stk500 always as they are not good for mounting in bots etc.
But you use it as the programmer
or build your own isp programmer for as little as $5.
For some cheap boards for pic, 8051 and avr
Not as capable as servo pod or isopod.
And can take a while for them to ship(few weeks).
If you use c, winavr port of gcc is free.
Then you have Brian's nice little boards.
For the maveric boards
work real well.easy enough to build if you have done
surface mount soldering before unless you buy a built one.
again easy to use and program. good features.
You can slao quite easily use the dontronics simssticks
for robotics apps, just need to make sure you mount them properly.
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.