Author Topic: Encoder pulses as timer ticks  (Read 2270 times)

0 Members and 1 Guest are viewing this topic.

Offline kasuntTopic starter

  • Jr. Member
  • **
  • Posts: 7
  • Helpful? 0
Encoder pulses as timer ticks
« on: May 31, 2011, 10:36:22 PM »
Hi guys,

For a robotic project I am using two of HEDS-5500 encoders in combination with a HTCL 2032 decoder IC. For the microcontroller I have chosen AVR 128 as the ideal mcu as it has a number of timers.

So what I want to do is use the HTCL 2032 DEC pin outputs, i.e. DECX and DECY to trigger two interrupts. One of each axis. In other words I have DEC X (left encoder) to INT 3 and DEC Y (right encoder) to INT 2.

Instead of reading the decoder bytes I want to use two of the 16-bit timers count the pulses after the interrupt triggers. One timer for each encoder. I think the most suitable are timer1 and timer3.

Has anyone here done this ? Or could help me out with it ? I would like to know how to convert the timer ticks to the proper encoder pulses.

Im running HTCL 2032 on 20 Mhz and AVR 128 on 16 Mhz.

Offline Soeren

  • Supreme Robot
  • *****
  • Posts: 4,672
  • Helpful? 227
  • Mind Reading: 0.0
Re: Encoder pulses as timer ticks
« Reply #1 on: June 01, 2011, 06:17:57 AM »
Hi,

So what I want to do is use the HTCL 2032 DEC pin outputs, i.e. DECX and DECY to trigger two interrupts. One of each axis. In other words I have DEC X (left encoder) to INT 3 and DEC Y (right encoder) to INT 2.

Instead of reading the decoder bytes I want to use two of the 16-bit timers count the pulses after the interrupt triggers. One timer for each encoder. I think the most suitable are timer1 and timer3.
Not knowing the decoder IC (you didn't provide links!) I cannot say much about it, other than why use it at all, if you just want to count pulses?
Your measurements will be flawed, should it ever rotate in the opposite direction, if you just use a decrement output.

Given you already have a quadrature output from the sensor, you could let the controller trig on each (or eg. each positive) transition of both A and B (and know the direction as well), time the periods between each transition and make a running average of a few samples to remove jitter, if used for speed control.
That way you don't need the decoder at all and the load on the controller will be about the same..

'What are you gonna use the measured data for - speed, distance or ...?
Regards,
Søren

A rather fast and fairly heavy robot with quite large wheels needs what? A lot of power?
Please remember...
Engineering is based on numbers - not adjectives

Offline kasuntTopic starter

  • Jr. Member
  • **
  • Posts: 7
  • Helpful? 0
Re: Encoder pulses as timer ticks
« Reply #2 on: June 01, 2011, 01:20:57 PM »
Thanks for that.

My bad for not giving the link to the decoder. http://www.avagotech.com/docs/AV02-0096EN

What I wanted to do was minimize the calculations on the MCU. What about reading off an available 16bit timer ? Do you think Il still need the direction ?

Its for speed calculation.

Offline Soeren

  • Supreme Robot
  • *****
  • Posts: 4,672
  • Helpful? 227
  • Mind Reading: 0.0
Re: Encoder pulses as timer ticks
« Reply #3 on: June 01, 2011, 08:25:55 PM »
Hi,

What I wanted to do was minimize the calculations on the MCU. What about reading off an available 16bit timer ? Do you think Il still need the direction ?

Its for speed calculation.
No you don't really need the direction info for speed control, but you still need a count when in reverse (if you need speed control in that situation at least).
Given the CPR (50 to 1024, depending on your specific model), you shouldn't need more than an 8 bit timer, as long as you choose the timing accordingly.

A small interrupt routine could handle this easily, without much load on the controller. If you make a qualified evaluation that says it would be a close shave, a faster controller is cheaper than buying specialized circuits (or use a 6- or 8 pin controller as a decoder to unload the main controller.

To get the speed, just time the intervals between pulses. Depending on how many counts/rev. the encoder gives, you can count just the rising edge on A (1*CPR), both rising and falling edge on A (2*CPR) or both edges on both A and B (4*CPR).

The time between pulses will be the reciprocal of speed (i.e. the faster you go, the less time between "clicks".
As I mentioned, a running average on a few samples will avoid any jerkiness, should any appear.
Another way of averaging is to always count two ticks, but swapping out the oldest sample and replacing it with the newest (this can be expanded if needed), or a logarithmic decaying average, where samples matter less and less,the farther back in time they are (but that's probably overkill for this app.).

If you want to keep it outside the '128, a 6-pin controller (going at less than $0.40) will be a better solution than a specialized IC that may soon become a rarity (i.e. no or very expensive replacement) - plus you'll know how it works down to the least bit of code.
Regards,
Søren

A rather fast and fairly heavy robot with quite large wheels needs what? A lot of power?
Please remember...
Engineering is based on numbers - not adjectives

 


Get Your Ad Here