Reading my motor encoders properly

[jgeidl]

I have motors with encoders that will provide from 1600 CPR to 6400CPR
depending on what part of the rise and/or fall I read from the A & B
outputs. I plan on using this with and Arduino and using interrupts
on the Arduino otherwise, I won’t capture all the ticks.

Here’s my question. For the sake of this question let’s say I am
reading 1600 CPR – rise only on a given motor. If the motor is
running at full speed this is going create a real flood of
interrupts. Isn’t that going to make any other procedures extremely
sluggish? Am I going about this the right way?

Thanks,

Jim, K6JMG

[Wayne C. Gramlich]

Jim:

What you want is a quadrature encoder counter chip. A stand alone
chip that does the job is the LS7366. The other alternative
is to use a microcontroller that has one built in. The costs
are actually quite comparable.

The higher level issue you are running into is the "my microcontroller
is running out of steam" issue. The solution is usually 1) faster
microcontrollers, 2) more microcontrollers, or 3) both. Personally
I've moved onto embedded ARM microcontrollers -- ARM Cortex M3's to be
more specific. I use them like popcorn. Yes there is some learning
curve. Frankly, that is what the HBRC is all about -- people with
similar interests helping one another.

Regards,

-Wayne

On 04/17/2012 02:57 PM, jgeidl wrote:
> I have motors with encoders that will provide from 1600 CPR to 6400CPR

> depending on what part of the rise and/or fall I read from the A& B

> outputs. I plan on using this with and Arduino and using interrupts

> on the Arduino otherwise, I won�t capture all the ticks.
>
> Here�s my question. For the sake of this question let�s say I am
> reading 1600 CPR � rise only on a given motor. If the motor is

> running at full speed this is going create a real flood of

> interrupts. Isn�t that going to make any other procedures extremely

[Chris Palmer]

Hi, Jim...

I recommend creating a little spreadsheet to do the math. It should be pretty easy to setup and you can tweak it as you go. You will need the specs of your processor and other data: clock frequency, how many cycles per instruction, how many instructions for overhead to enter an interrupt, how many instructions to clean up after exiting an interrupt, how may instructions you will spend in the interrupt, and the like. You can then easily calculate a theoretical maximum rate of detecting pulses by interrupt. Compare this with the number of pulses per second that you expect from the encoders and find out what shape you're in.

If you find you can keep up with the pulses, but don't have enough cycles for doing much else, you mght simply offload this task to a dedicated slave microcontroller. You will aso need some cycles to communicate the data to your master controller. Unfortunately, this might also be need interrupts, which could interfere with pulse capture. If you find that you cannot handle pulses at a fast enough rate at all, it is desirable to use a dedicated quadrature decoder chip or on-chip hardware module (some microcontrollers will have them).

Ones I know about:
* LS7366 -- 32-bit hardware quadrature decoder chip
* PIC 18F2431 (and family) -- on-chip quadrature decode module (probably others have it, too)
* CPLD or FPGA -- roll your own, or find something already built like Demand Peripherals' solutions

I'm sure there are other options, but hopefully this gets you started off.

For reference, I use a dedicated PIC 18F2431 for each motor for full PID control of the motor. On a regular timer interrupt, I read the counter from the quadrature module (aka "QEI module") and calculate the rotational direction, rate, and distance of travel. The only things using actual instruction cycles are the PID and data communication routines, as the hardware module keeps counts completely independently of other work. This is good enough for quite fast tick counting, as my motors can go up to 6000RPM (100 rotations per sec, times 300 encoder lines per rotation, times 4 for full-quadrature decode, which is up to 120k ticks per second). Solutions like this are great for prototyping, letting you not worry about strange symptoms coming from missed encoder ticks.

-Chris

jgeidl <but...@gmail.com> wrote:

-- 
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To post to this group, send email to hbrob...@googlegroups.com.
To unsubscribe from this group, send email to hbrobotics+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hbrobotics?hl=en.

[Butokim]

Thanks, Wayne. I will do some research on the chips. I am not ready to
switch mc yet. I have got to stop bouncing around and start actually
accomplishing some so I am.

James M. Geidl, K6JMG
D.B. Cooper, you have a message.

Jim:

Regards,

-Wayne

> on the Arduino otherwise, I won't capture all the ticks.
>
> Here's my question. For the sake of this question let's say I am
> reading 1600 CPR - rise only on a given motor. If the motor is

> running at full speed this is going create a real flood of interrupts.

> Isn't that going to make any other procedures extremely sluggish? Am

[Alan Marconett]

That's about the only way you can do it.

Alan

DE KM6VV mobile

[Butokim]

Chris,

 

Thank you for the reply.  Between you and Wayne I get it.  I am going to have to do something different than my original idea.  Unfortunately, I have somewhere less than no skill when it comes to programming something like a PIC.  I am a database weenie and have been teach myself some of the chips; Arduino, Picaxe, BASIC Stamp.  As you might imagine, I have a really crappy teacher. 

 

I am think along the lines of using separate Arduino for each wheel and then another one for the master controller.  I haven't even begun to think this through so it may be a pipe dream.  I suppose I could do something with a couple Picaxes too since they are PIC chip with a pretty frontend on them.  The trick in all this is going to be getting everything talking to everything else.

 

James M. Geidl, K6JMG
D.B. Cooper, you have a message.
 

---

From: hbrob...@googlegroups.com [mailto:hbrob...@googlegroups.com] On Behalf Of Chris Palmer
Sent: Tuesday, April 17, 2012 3:40 PM
To: hbrob...@googlegroups.com

Subject: Re: [HBRobotics] Reading my motor encoders properly

[rdo...@bizserve.com]

I ran into a similar problem on an older robot project that was using a HandyBoard as the main controller.  The encoders would just put out information faster than the controller could handle and some of the counts would be lost.  For the project I didn't really need the high resolution but losing track of the encoders and missing counts wasn't acceptable either.  So, what I did was use a small microcontroller (SX28) in between as encoder processor to scale the values.  It is can be configured to scale down the readings to divide them down to a level that the main controller can handle.  Since it always keeps track of the intermediate values none of the counts are lost.  Since it still looks like an encoder to the host, no special communication is needed.  If you have back issues of SERVO you can find a whole write up on the project in the July 2008 issue:

 

http://www.servomagazine.com/index.php/magazine/issue/2008/07

 

Robert

[Butokim]

Robert,

 

First.  Thanks for the Parallax caster, that turned out to be a good deal.

Second.  I don't have a subscription to Servo so I can only see part of the article.  Do you have it such that you could email it to me?

 

Thanks,

 

James M. Geidl, K6JMG
D.B. Cooper, you have a message.
 

---

From: hbrob...@googlegroups.com [mailto:hbrob...@googlegroups.com] On Behalf Of rdo...@bizserve.com
Sent: Tuesday, April 17, 2012 7:54 PM

[rdo...@bizserve.com]

Hello James,

 

The code I used on the SX28 processor was written in SX/B (compiled BASIC) and the source code is in a ZIP file on the SERVO site:

 

http://www.servomagazine.com/index.php/magazine/article/encoder_matching_scaling_and_inverting_encoder_values

 

The source shouldn't be too hard to follow and may help.

 

Glad to hear that the castor kit made it there ok.

--

[George Taylor]

Jim,

 

While you are investigating chips, you might consider checking out the Parallax Propeller chip. It contains eight microprocessors (Cogs). Runs up to 80MHZ. There are several encoder programs available that can be down loaded from the Parallax site. Additionally, if you start programming the Propeller chip, I suggest getting Hanno Sander's ViewPort program so you can see what is going on.

 

See:

 

www.parallax.com

 

www.hannoware.com

 

George Taylor

AA6QZ

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To post to this group, send email to hbrob...@googlegroups.com.

To unsubscribe from this group, send email to hbrobotics+unsub...@googlegroups.com.

[Butokim]

Thanks, George.  I am trying my best to not add any moving parts (mc) into what I am doing until I have a reasonable understanding of the ones I have been working with.  The propeller might come in the future as I particularly like Parallax.

 

James M. Geidl, K6JMG
D.B. Cooper, you have a message.
 

---

From: hbrob...@googlegroups.com [mailto:hbrob...@googlegroups.com] On Behalf Of George Taylor
Sent: Tuesday, April 17, 2012 9:43 PM
To: hbrob...@googlegroups.com
Subject: Re: [HBRobotics] Reading my motor encoders properly

[Butokim]

This looks like something I may be able to figure out, thanks.

 

Something else hit me.  The smaller Arduinos only have two interrupts so I would have to use two Arduinos just to read the A and B out puts from the encoders on each wheel.  The other option is to use a Arduino Mega 2560 which has 6 interrupts available. 

 

I am warming up to the idea of having some kind of chip in between the main processor and the encoders to , as you say, scale the values.

 

James M. Geidl, K6JMG
D.B. Cooper, you have a message.
 

 

From: hbrob...@googlegroups.com [mailto:hbrob...@googlegroups.com] On Behalf Of rdo...@bizserve.com

Sent: Tuesday, April 17, 2012 8:52 PM

[Chris Palmer]

If you can find them, a LS7366 chip paired with each quadrature encoder would be your easiest solution. They aren't microcontrollers and don't need programming, but take commands from your microcontroller and will independently keep count. You poll them when you want to know their current count. Doing it on a timer interrupt is a clean way to go.

I don't know if it has changed, but it used to be difficult to find a source for them. Wayne organized a club group purchase several years back, and I still have some.

-Chris

[Alan]

If I recall correctly, the LS7366 (I’ve worked with them) part is more suited to a micro processor (Intel or Motorola part) then a micro computer (Arduino).  The part has a bus, the Arduino’s don’t have an exposed bus for data/address.  (Although there’s always a way around it, if you want to bit-bang).

 

Alan KM6VV

 

On Behalf Of Chris Palmer

If you can find them, a LS7366 chip paired with each quadrature encoder would be your easiest solution. They aren't microcontrollers and don't need programming, but take commands from your microcontroller and will independently keep count. You poll them when you want to know their current count. Doing it on a timer interrupt is a clean way to go.

I don't know if it has changed, but it used to be difficult to find a source for them. Wayne organized a club group purchase several years back, and I still have some.

-Chris

Butokim <but...@gmail.com> wrote:

This looks like something I may be able to figure out, thanks.

 

Something else hit me.  The smaller Arduinos only have two interrupts so I would have to use two Arduinos just to read the A and B out puts from the encoders on each wheel.  The other option is to use a Arduino Mega 2560 which has 6 interrupts available. 

 

I am warming up to the idea of having some kind of chip in between the main processor and the encoders to , as you say, scale the values.

 

James M. Geidl, K6JMG
D.B. Cooper, you have a message.
 

.

[Butokim]

Gemini has the chips in SM and through-hole.  They are 3.95 ea with 12.00 shipping.

 

James M. Geidl, K6JMG
D.B. Cooper, you have a message.
 

---

From: hbrob...@googlegroups.com [mailto:hbrob...@googlegroups.com] On Behalf Of Alan
Sent: Wednesday, April 18, 2012 3:27 PM

To: hbrob...@googlegroups.com
Subject: RE: [HBRobotics] Reading my motor encoders properly

[Wayne C. Gramlich]

All:

Chris is correct. I did organize a group buy of the LS7366 in a DIP-16
package many moons ago. At the time, only Gemini would sell the part
in a DIP-16 package. My recollection at the time is that Gemini had
a minimum order that was greater $50 (my memory is fuzzy on this topic.)
US Digital sells the chip in surface mount form. I have 3 LS7366's
(DIP-16) sitting in my drawer that I will bring to the SIG tonight.
I doubt I will ever use them.

These are SPI devices and can be used with 4 GPIO lines from a
processor. Bit-banging works just fine with SPI devices. If you
have two LS7366's, you need 5 lines (serial clock, serial in,
serial out, select 1 and select 2.)

Regards,

-Wayne

On 04/18/2012 03:35 PM, Butokim wrote:
> Gemini has the chips in SM and through-hole. They are 3.95 ea with 12.00
> shipping.
>
> James M. Geidl, K6JMG

> /D.B. Cooper, you have a message./
>
>
> ------------------------------------------------------------------------
> *From:* hbrob...@googlegroups.com [mailto:hbrob...@googlegroups.com]
> *On Behalf Of *Alan
> *Sent:* Wednesday, April 18, 2012 3:27 PM
> *To:* hbrob...@googlegroups.com
> *Subject:* RE: [HBRobotics] Reading my motor encoders properly
>
> If I recall correctly, the LS7366 (I�ve worked with them) part is more

> suited to a micro processor (Intel or Motorola part) then a micro

> computer (Arduino). The part has a bus, the Arduino�s don�t have an
> exposed bus for data/address. (Although there�s always a way around it,

> if you want to bit-bang).
>
> Alan KM6VV
>

> *On Behalf Of *Chris Palmer

>
> If you can find them, a LS7366 chip paired with each quadrature encoder
> would be your easiest solution. They aren't microcontrollers and don't
> need programming, but take commands from your microcontroller and will
> independently keep count. You poll them when you want to know their
> current count. Doing it on a timer interrupt is a clean way to go.
>
> I don't know if it has changed, but it used to be difficult to find a
> source for them. Wayne organized a club group purchase several years
> back, and I still have some.
>
> -Chris
>

> Butokim <but...@gmail.com <mailto:but...@gmail.com>> wrote:
>
> This looks like something I may be able to figure out, thanks.
>
> Something else hit me. The smaller Arduinos only have two interrupts so
> I would have to use two Arduinos just to read the A and B out puts from
> the encoders on each wheel. The other option is to use a Arduino Mega
> 2560 which has 6 interrupts available.
>
> I am warming up to the idea of having some kind of chip in between the
> main processor and the encoders to , as you say, scale the values.
>
> James M. Geidl, K6JMG

> /D.B. Cooper, you have a message./

[don clay]

Here's a location that has them listed.  I've never used them before though.

http://www.2k1.co.uk/display_catalog.php?

[Randy M. Dumse]

Jim, this subject is one of my pet peeves. Quadrature isn't that hard, but conversely, it is very easy to trick yourself into thinking it can be done simply, that there are short cuts, rather than implementing the full necessary state machine. The short cuts have failure modes that are very hard to find and understand.

 

You can see even the professionals fool themselves on these points, as you can see in the published EDN article, then in my response to the article in the blog.

http://www.edn.com/article/512304-Decode_a_quadrature_encoder_in_software.php

 

Now I know you went through a long discussion about the Basic Stamp which is your preference, and moved on to the Arduino hoping to repeat the easy of experience. Back in those discussions, I told you about my company's products, the 'Pods, and how good they were for motion control. They were a bit more expensive, but much better featured.

 

So below you remarked you can find two interrupt lines on an Arduino, so you can probably do 1 ch of quadrature per Arduino. So for your average robot, you'll need three Arduinos to do two channels of quadrature, and then a significantly difficult real time interrupt driven state machine function that will likely take up about half of the Arduino's time keeping up with the quadrater when the motor runs fast, and the encoder counts are high for good accuracy.

 

But even when you get the quadrature details into the micro, it does you no good, because now you have to get the information out across some sort of communications bridge or protocol before the main processor has the information it needs about the wheel turning. More latency while that happens. And your serial communication link is itself another realtime task. And understanding the command to send it, also another realtime task. 

 

So there you go. Use two Arduinos, running four realtime tasks. 1) Interrupt on Phase A 2) Interrupt on Phase B, 3) Serial receive of command to give quadrature 4) Serial transmit to send quadrature out. Oh, and if you are formating the quadrature into ascii, or decoding ascii commands, don't forget that adding length and complexity to the program. Then you need the equivalent serial send and receive and translation programs on the main controller. Two of the controllers are maxed out doing the realtime tasks. The main controller is maybe spending 10 to 25% of it's time encoding decoding sending receiving. So less than 75% of it is available to do generate motor commands, navigation, etc.

 

Does that sound simple?

 

Now, let's say you instead chose one of our (not yet released) SuperPods(TM). You have to hook up two wires to one of the built-in, hardware quadrature channel, and two other wires to the other hardware serial channel. Anytime the main (only) processor needs the encoder information, it just reads a 32-bit location. Oh, and the read causes an immediate differencing with the last time it read the location. So you not only have total counts for fetching, but also the change from the last time. Then there is a whole 60 MIPs (more than all three of the Arduinos put together) processor with time to do PID routines (built into the language), navigation, etc.. (PWM is generated in hardware too, so that's easy, too.)

 

Does that sound simple?

 

I realize this is a very self serving post. But it helps highlight it could be a user serving thing as well, making robotics soooo much easier to complete. Difference in convenience to the builder is night and day. Finally in the interest of full disclosure, the timers in the SuperPod(TM) are configureable. So you can have a total of 26 PWM outputs. Or 12 PWM outputs, and 7 quadrature decoders. Software setup to make timers into quadrature decoders is two short lines of code. Pr the timers could instead be configured to time sonars, generate PWM, read Pulse Widths, or what have you of about a dozen additional choices.

 

There really is no comparison.

 

Randy

---

From: hbrob...@googlegroups.com [mailto:hbrob...@googlegroups.com] On Behalf Of Butokim
Sent: Wednesday, April 18, 2012 4:44 PM

To: hbrob...@googlegroups.com
Subject: RE: [HBRobotics] Reading my motor encoders properly

[Butokim]

Randy,

 

I stared this whole robotics thing with a BASIC Stamp several years ago.  To understand concepts, I still refer back to some of that functionality because of its simplicity.  I moved on to the Arduinos a couple years ago.   My first "significant" robot was Arduino powered and I was very happy with those early results. 

 

This is like many other things in my life; my ideas far outreach my capabilities.  I keep experimenting and learning as I go along.  Unfortunately, my learning ability, my dedication, and my wallet all get in the way. 

 

I won't argue for a minute that this whole encoder thing is a lot more involved that I first thought.  I didn't really sit and think it through. 

 

Do you have more info on your Superpod?  If so, send me a link.  From the other things I have seen of yours it is probably beyond scope for me but I would sure like to take a look at it.

 

James M. Geidl, K6JMG
D.B. Cooper, you have a message.
 

---

From: hbrob...@googlegroups.com [mailto:hbrob...@googlegroups.com] On Behalf Of Randy M. Dumse
Sent: Wednesday, April 25, 2012 3:32 PM