Pulse counting

Nov 02, 2003 24 Replies

Hi All,



Now that I have wheel encoders on my robot, I need a way to count the pulses that they generate and possibly even convert to frequency. So I'm wondering if anyone here knows of a chip that someone makes (TI, maxim, etc.) that will do this. Thanks.


-Dave


Hi Dave,

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 sensors.

Jay

Hi Jay,

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.

-Dave

communicate

Hi Dave,

Using feedback to close the control loop is the only way to go.

Cheapest Solution 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 curve.

Analog Solution (Speed) You could use 2 frequency to voltage chips

formatting link
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.

Good Luck

Jay

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

---------------------------------------------------------------------------- .

If you are using the stamp, you can interface an ls2166 or ls7266

formatting link
uses a lot of port pins, but adds a lot of flexibility. This will give you absolute odometry.

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.

Mike

unfortunately

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.

Best regards,

Geoffrey

Hi Geoff,

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,

-Dave

unfortunately

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 misleading.

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 d> Hi Geoff,

before you buy a second stamp, if odometry is what you are after, look at the IsoPod, MiniPod and family.

formatting link
IsoPod can read 6 quad encoders w/o extra hardware, generate 12 channels of PWM, and has 8 channels of 12 bit A/D.

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 system.

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.

Hi Dave,

Check out the Butterfly at

formatting link
AVRFreaks is a great resource.

Jay

Hi Mike,

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.

-Dave

channels

Hi Randy,

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.

-Dave

I think I found it.

formatting link

-Dave

That's one of them. See also

formatting link
and

formatting link
for the motion applet.

-- Randy M. Dumse

formatting link
Caution: Objects in mirror are more confused than they appear.

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:

formatting link
This is built from spare parts - very low cost. Some other programming options can be viewed here, at varying price levels:

formatting link
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 into.

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.

Cheers,

-Brian

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

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

formatting link

formatting link
=20
formatting link
formatting link
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.

formatting link

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.

Alex

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required