New gear motor product ID 28819 counts per output shaft resolution?

rabaggett · 2014-05-26 04:32

Anybody know how many counts per revolution of the output shaff for this new gear motor? Seems to be about the only thing missing from the details..

Chuck Thomas · 2014-06-26 05:25

The encoders have a resolution of 64 pulses per revolution of the motor shaft, which translates to 1920
pulses per revolution of the output shaft. If you dont need directional information and want to simplify
your encoder routines you can just use a single output (A or

. This will give you 32 pulses per
revolution of the motor shaft, which translates to 960 pulses per revolution of the output shaft.

From the product PDF. 6-15V Gear Motor with Encoder (#28819)
Chuck

J^3 · 2014-12-18 21:40

Has anyone else tried to measure the counts per motor rev.

I have measured approx. 12 counts per motor rev on a single channel which does not agree with the documentation. This measurement was made by manually rotating the motor shaft, not the gearbox output shaft.

I also measured the frequency of encoder channel A with a armature voltage of 7.2VDC. My measurement was ~540Hz.

Dividing 540 by 12 gives motor revs/sec of 45.

Multiplying by 60 gives motor RPM of 2.7K.

Dividing by 30, gearbox reduction, you get 90 RPM on the output of the gearbox.

This is what I have observed by counting the gearbox output revs with a stopwatch.

I know these measurements are crude, but a count of 32 for a single channel just doesn't make sense.

Any comments would be appreciated.

Thanks,
J^3

Duane Degn · 2014-12-18 22:03

I think this come down how a "count" or "pulse" is defined. I'll pull one out to make sure, but I'm pretty the encoders on the Parallax motors have the same resolution as the Pololu motors.

With encoders, transitions from high to low or low to high will be considered a "count". Sometimes this "count" is also referred to (IMO incorrectly) as a "pulse".

What if you try your experiments assuming there are 16 pulses per rev? Do the numbers start to make sense.

Looking at some of your past posts, it appears you have a Propeller. I've been experimenting with motors and encoders and I posted some demo programs in this thread. Hopefully theres a program which will be useful.

As I said, I will dig my motor out to make sure the encoders really are the same as the ones on the Pololu motors.

J^3 · 2014-12-19 07:09

Hello Duane,

My thoughts exactly, what are they defining as a pulse.

If a pulse is any transition, low/high or high/lo, then I would have 24 pulses/counts per motor rev. This and 16 still don't make sense with what i have measured on the output of the gearbox over 1 minute.

IMHO, a pulse should be the same as 1 cycle, period, etc. An edge transition doesn't make sense for a pulse, especially if you are counting both of them.

Thanks for the thread, I will check it out.

Duane Degn · 2014-12-19 11:49

I added a piece of tape to the encoder so I could make sure and see when 1 rev occurred and I I counted 16 cycles (on the white wire only) as I rotated the motor.

I opened up the gearbox and counted the gears.

The gear attached to the motor shaft had 10 teeth. The first gear in the chain had 25 outer teeth and 10 inner teeth. The second gear had 30 outer and 10 inner teeth and the final gear had 40 teeth.

The gives a ratio of: 25/10 * 30/10 * 40/10 = 5/2 * 3 * 4 = 60/2 = 30

So the 30:1 gear ratio is correct.

J^3 · 2014-12-19 12:23

Thanks Duane,

I agree with the 30:1 ratio on the gearbox, however I am only getting 12 cycles for a single channel. Maybe my measurement isn't accurate enough.

It shouldn't matter which channel you use, A or B, to my understanding of how the encoder works. Would you agree?

I will try to measure it again.

Thanks,
J^3

Duane Degn · 2014-12-19 12:44

J^3 wrote: »

It shouldn't matter which channel you use, A or B, to my understanding of how the encoder works. Would you agree?

I agree. I just powered the encoders with 4.2V (anything between 3.3V and 5V should be fine) and used my DMM to watch the voltage on the white wire. Maybe you moved the encoder too fast and missed a pulse (or four)?

J^3 · 2014-12-19 12:49

Maybe,

So, since you count 16 cycles that means the documentation is counting edges, rising and falling, as a pulse giving you 32 pulses per channel.

I am eating lunch right now, but will get back to it as soon as I am done.

Thanks,
J^3

J^3 · 2014-12-19 13:19

Hey Duane,

I still count 12 rising edges, or cycles, in one rev. This time I wrote a quick program to do the counting for me, pretty basic.

I don't know what the deal is here for me, however 12 works for me consistently in calculating the motor RPM at different speeds.

Thanks for your input.

/*
* FRDM_KL25Z demo board
* Count rising edges of encoder channel output in a single rev
*/


#include "mbed.h"


//Creates an interrupt object tied to D2 pin 
InterruptIn encoder(D2);

volatile uint32_t cnt = 0;


//ISR
void counter(void)
{
    cnt++;
}

int main(void) 
{
    //configure interrupt to trigger on rising edge and point to ISR
    encoder.rise(&counter);
    
    for(;;)
    {
        printf("\nCount = %d\n", cnt);
    }
    
}

Chris Savage · 2014-12-19 14:13

Hey everyone. The encoders were characterized in two ways when we first received samples of these motors. I haven't re-tested them since, however nothing should have changed. If more than one of you are getting inconsistent results I can rig something up again to test. Initially I counted the pulses on one rotation, but due to magnetic flux and the fact that these are brushed motors I would sometimes be off by a count or two. So after averaging I decided to run the motor and count not only the pulse output from the encoders, but I added a reflective strip on the wheel and used an optical pickup to tell me when that strip came up. From the start of one signal from the optical encoder to the next there were 32 pulses per revolution. Next I multiplied the number of pulses times 30 (gear box ratio) and programmed the motor driver to turn the motor through 960 pulses and then stop. I put a mark on the output shaft wheel and when the program ran the wheel would turn one complete revolution (minus just a hint of overshoot when the motor shut down). I did this test again programming the number of pulses for 3 and 5 revolutions. So if you're getting different results that would indicate something is wrong on your end or something changed.

Note: A pulse would be a transition from high to low. I do not count the low to high as an additional pulse. As I recall these encoders go low for each pulse output.

J^3 · 2014-12-19 14:28

Thanks Chris,

It appears that I am the only one with a problem.

Just for clarification, what are you considering a pulse? Do you consider both the high/rising_edge and low state/falling_edge?

I am considering a pulse the rising_edge/High state of a single channel and have measured this count as 12/rev.

I ordered two motors, so I am going to see if I get the same results with the other one tonight.

Is it possible that the disc on the motor shaft has changed?

I don't want to disassemble the encoder just to see what hall effect sensor was used, and that still wouldn't tell me anything about the disc. Can we get any info. w/respect to what sensor was used. What is in the disc? Are there just magnets spaced evenly around the disc, or what is going on there?

With my count of 12, I am assuming there are small magnets placed every 30 degrees in the disc to trigger the sensor which has two detectors.

Just curious.

Thanks,
J^3

J^3 · 2014-12-19 15:15

Gents,

I was digging around on Pololu's site and noticed the following motors.

http://www.pololu.com/product/2273

These guys have an encoder with 48 CPR (both channels, both edges). So, for a single channel and single edge you would get 12 CPR.

I think Parallax's most recent batch of motors do include a 30:1 gearbox, however, some how have ended up with the 48 CPR encoder on them.

I haven't tested both of my motors yet, but I plan on testing the other one as soon as I get home tonight.

I find it interesting that some use both edges as part of the count. Is there any advantage to this, or are both methods equal. I an't see an advantage.

Thanks,
J^3

Mark_T · 2014-12-19 15:28

J^3 wrote: »

Gents,
I find it interesting that some use both edges as part of the count. Is there any advantage to this, or are both methods equal. I an't see an advantage.

Thanks,
J^3

If you don't use both edges of both signals you cannot guarantee precise counting. That's the deal with quadrature signals you
need to see every transition to distinguish direction and avoid being confused by noise and poor transistions. So long as
your encoder guarantees only one signal can change at a time then you have perfect information by sensing all transitions.

Draw some waveforms and compare what happens with glitchy transitions and direction changes with all edges sensed v.
rising edges only... It'll become clear.

[ Oh yes, I have an encoder PASM object in the Obex, nearly forgot to plug it

http://obex.parallax.com/object/737 ]

J^3 · 2014-12-19 15:44

Thanks Mark,

I was curious why they were specified that way. I don't believe it applies to the issue at hand since I am turning the motor shaft by hand, so noise and glitchy signals really aren't a factor. However, I can definitely see how it applies with a running motor.

Thanks for the info,
J^3

Duane Degn · 2014-12-19 16:05

J^3 wrote: »

I find it interesting that some use both edges as part of the count. Is there any advantage to this, or are both methods equal. I an't see an advantage.

As Mark mentioned, it's important to monitor both edges when using quadrature encoders.

Monitoring both edges is even more important when using encoders which don't have a lot of resolution. As long as the encoders are precisely made, one can compute the speed of the wheel accurately monitoring the time between transitions. I'm attempting to do this with Arlo hardware. Rather than counting the number transitions seen in a given amount of time, I'm measuring the time between transitions. I'm hoping this will allow more precise control of the motors than by counting transitions.

Monitoring both the rising and falling edge of the encoders isn't as important when the encoders are on the motor rather than the output shaft. With your 12 pulse per rev encoders, you've got 10 times as many transitions per revolution of the output shaft than the Arlo's encoders produce. I think you can get by with just monitoring a single transition type in order to monitor speed.

When did you purchase your motors? I've only have mine for a few months so the 12 pulse per rev version must be relatively new. I have three more of these motors. I'm going to check them to make sure they're all 16 pulses per channel per revolution.

J^3 · 2014-12-19 16:15

Hello Duane,

I just received them yesterday, and purchased them on Tuesday.

Thanks,

J^3

Hal Albach · 2014-12-19 18:17

Check the disc to sensor alignment, the sensor may not be seeing all the magnetic domains. The brown magnetic disc should be fully aligned with the top half, the thinner portion, of the sensor.
Several months ago I received a pair of motors where only one of them had a signal from encoder, the other one was flatlined. Comparing the two motors I noticed on the failing unit the brown magnetic disc was not aligned completely with the upper, thinner, part of the sensor like the good one was. I carefully moved the disk into proper position (it's a snug fit on the shaft but it can be moved, carefully). Now the failing encoder is outputting pulses on both channels.
This oversimplified drawing shows how it should look. If you are going to try to move the disc, be very careful to apply even pressure on both sides of the shaft. I believe the disc is sintered metal and probably a bit brittle.

Encoder alignment.bmp

J^3 · 2014-12-19 20:21

All,

I tested the other motor I received in my order yesterday...same deal, 12 counts (rising edge single channel)per rev.

Chris,

Do you mind setting up a test and seeing if you get the same results? I don't know how many of these you guys keep on hand, or how you will make sure to get a motor from the same batch as the ones I have received, but these motors definitely seem to have a 48 (rising and falling, both channels) CPR encoder on them.

Thanks,
J^3

Duane Degn · 2014-12-19 21:19

J^3 wrote: »

these motors definitely seem to have a 48 (rising and falling, both channels) CPR encoder on them.

IMO, This is a big deal.

I can imagine someone ordering one of the 12 pole encoders to replace a 16 pole version and being very frustrated their code no longer works correctly.

I plan to use the four motors I have to make a Mecanum wheeled robot. If it worked well, I planned to make additional robots with the same parts. I'm very disappointed to hear I'll have to change my software to work with motors I may purchase in the future.

I checked my other three motors and they all have 16 pulses per channel per revolution.

Thanks for bringing this to our attention J^3.

Chris Savage · 2014-12-22 08:50

Duane Degn wrote: »

IMO, This is a big deal. I can imagine someone ordering one of the 12 pole encoders to replace a 16 pole version and being very frustrated their code no longer works correctly. I plan to use the four motors I have to make a Mecanum wheeled robot. If it worked well, I planned to make additional robots with the same parts. I'm very disappointed to hear I'll have to change my software to work with motors I may purchase in the future. I checked my other three motors and they all have 16 pulses per channel per revolution. Thanks for bringing this to our attention J^3.

Please bear in mind this has not yet been confirmed. I will be in the Rocklin office tomorrow and obtain a newer motor to compare with the existing motors I have. Until then I wouldn't be too concerned. If the manufacturer changed something on us I will find out and look into it. The documentation would have to be revised. But until I test them myself I'm not going to jump to any conclusions. If something has changed it isn't because of anything Parallax has done (or failed to do). We order the same part number each time. The manufacturer has not discussed making any changes to this motor.

In the past they have offered to replace the motor with a higher resolution version. This new motor actually had multiple pickups (hall-effect) sensors but was rejected because I did extensive testing and determined that the phase angle was off by too much. It was not 90 degrees and was low enough that with jitter there was the possibility of overlap. Also the outputs were not pulled high and required external pull-ups. Parallax has the highest quality standards in 3rd party products we carry. Unfortunately we can't always control what the manufacturer may do. I will look into this further tomorrow though.

Chris Savage · 2014-12-22 08:53

J^3 wrote: »

All, I tested the other motor I received in my order yesterday...same deal, 12 counts (rising edge single channel)per rev.
Chris, Do you mind setting up a test and seeing if you get the same results? I don't know how many of these you guys keep on hand, or how you will make sure to get a motor from the same batch as the ones I have received, but these motors definitely seem to have a 48 (rising and falling, both channels) CPR encoder on them.

Thanks,
J^3

I certainly will look into this tomorrow. We have 106 on hand at the moment and I believe we order them 250 at a time. I will pull two from stock and test them and then when I get home I will compare them against the older set I have.

GordonMcComb · 2014-12-22 09:49

In the interim for Chris' retest, if these encoders are 32 CPR, and have A/B outputs at quadrature, the maximum resolution is 4X, or 128 CPR.

This would assume standard quadrature decoding. I never do this myself in discrete hardware or software, but rather "cheat" by using the LSI chips from US Digital that perform conditioning and decoding all-in-one. They're pretty cheap, especially for the time you save.

Duane Degn · 2014-12-22 10:12

GordonMcComb wrote: »

In the interim for Chris' retest, if these encoders are 32 CPR, and have A/B outputs at quadrature, the maximum resolution is 4X, or 128 CPR.

I think you're off by a factor of two. The 32 CPR figure is counting transitions per encoder not pulses per encoder.

With both channels, you get a total of 64 transitions per rotation of the motor giving 1920 transitions per revolution of drive shaft.

GordonMcComb wrote: »

This would assume standard quadrature decoding. I never do this myself in discrete hardware or software, but rather "cheat" by using the LSI chips from US Digital that perform conditioning and decoding all-in-one. They're pretty cheap, especially for the time you save.

Do you have a part number for these?

I'm not sure how useful they would be on low resolution encoders since the time the transition occurs can be very important when computing speed of the robot. I'd think having a chip between the Propeller and the encoder would add latency to the feedback.

GordonMcComb · 2014-12-22 11:14

Duane Degn wrote: »

I think you're off by a factor of two. The 32 CPR figure is counting transitions per encoder not pulses per encoder.

With both channels, you get a total of 64 transitions per rotation of the motor giving 1920 transitions per revolution of drive shaft.

In that case they are 16 CPS per channel, so you are correct that it is 64 CPS at 4X resolution. I missed that the 32 CPR figure was both falling and rising. That's not a good technique, anyway, unless you signal condition, and/or are sure the pulses are very close to 50%.

Duane Degn wrote: »

Do you have a part number for these?

I'm not sure how useful they would be on low resolution encoders since the time the transition occurs can be very important when computing speed of the robot. I'd think having a chip between the Propeller and the encoder would add latency to the feedback.

http://www.usdigital.com/products/interfaces/ics

Output variations include pulse trains with a separate up/down line, or separate pulse trains per direction.

As for counting, they work okay with my very low res vinyl cut encoder patterns of 6-12 CPS. An interface doesn't know complete revolutions from a hole in the ground, as CPS by itself is meaningless (unless it has a separate index input, but we're not talking about that). All well designed encoder interfaces are perfectly fine at very low speeds. A benefit of these chips is that they know how to handle transition positions, which can otherwise cause serious bounce.

As for computing speed, yes, the higher the CPS the more accurate that can be. But with encoders you get what you get. This applies no matter what form of interface you use.

J^3 · 2014-12-24 12:38

Chris Savage wrote: »

I certainly will look into this tomorrow. We have 106 on hand at the moment and I believe we order them 250 at a time. I will pull two from stock and test them and then when I get home I will compare them against the older set I have.

Thanks Chris,

J^3 · 2014-12-24 12:55

All,

I believe this is a known fact, however I wanted to get it on record.

My question regarding the CPR of the encoders I received is not a question of the efforts made by Parallax to provide a quality product. It is clear to me that these motor/encoder combinations are purchased by Parallax from another manufacturer and the resolution of the provided encoders could have easily been changed by the original manufacturer, intentionally or unintentionally, without any notification to Parallax.

My question is purely a question of understanding and clarity.

While in school Parallax was my first introduction to embedded computing, or computing of any sort for that matter, and was a very rewarding experience. By the time I had reached an introductory course in embedded systems for credit (we used the STK500 dev board, AVR studio, and an Atmega32A) it was an easy A due to the experience I had gained tinkering with the BS2, prop, and other micros.

Now that I have graduated and am working, I still continue to tinker and try to share my experiences with my nephews and others. I recently purchased an Arduino shield kit for my nephew and have been guiding him through the 'Learn' activities associated with the kit. I chose this path for him due to my experiences with Parallax's educational material and recommend Parallax to anyone interested in embedded systems.

Thanks,
J^3

Chris Savage · 2014-12-29 09:14

I did pick up some motors when I was in Rocklin, however the holidays got hectic and I only just got my bench reconnected yesterday. It's a busy day so far but as I get time I will connect the motors up and see what I get.

I also wanted to respond to an earlier reply where I was ambiguous as to counts/pulses. The code I have that calculates counts increments on each transition of either output (A/B). So when either channel transitions from one state to another the count is incremented. This is typical of a rotary/incremental/quadrature encoder.

But I also counted pulses for verification. These pulses were fed into a logic analyzer and pulses were counted as a high-to-low-to-high transition, since when looking at the output on the logic analyzer or scope that is how it appears. I will try to be more clear about my measurements today once I have tested both sets of motors.

Chris Savage · 2014-12-29 20:13

I will be modifying this post with updated information as I acquire it, but it does seem at least as far as appearance that the encoders have changed somewhat since the original motors I characterized. I will post the three variants I have found and my measurements of them in counts. I will stick with counts because the A/B inputs affect the count via 90 degree out of phase high/low transitions in both directions.

- This was the original sample they sent me. This motor measures 48 counts per revolution.

- This was from the first batch. Because of the difference in appearance I characterized these for the documentation. This motor measures 64 counts per revolution. The documentation inaccurately states 64 pulses. I will be correcting that mistake and properly explaining how pulses are used.

- This is the motor I pulled from stock on 12-23-2014. This motor measures 48 counts per revolution. So something has changed.

I apologize for the inconvenience. J^3 if you could post a photo of the encoder on your motor I would appreciate it. I will have our purchasing agent contact our supplier to find out what happened. I will also fix the documentation. I appreciate you all bringing this to my attention. We take quality and consistency very seriously and changes like this undermine our ability to provide consistency in our products.

As a note, J^3, your measurement of 12 pulses per output, per revolution sounds accurate. It takes 4 transitions across the two channels to get 4 counts, however that translates to one low-high-low (or high-low-high) transition. So the pulses will be 1/4 of the counts. This diagram illustrates.

J^3 · 2014-12-30 08:23

Hello Chris,

Thank you for the additional testing.

Please find the requested pictures attached, the pics of my line following bot are just for fun.

There was no inconvenience for me, I ordered the motors just for tinkering and didn't even know what the CPR was when I ordered them, or how it is traditionally measured with both channels. I would call this a success on two fronts; I have learned something and purchasing is aware of the rogue encoders

.

I can also settle a debate with my better half on whether or not I can do simple math!

Thanks,
J^3.

Chris Savage · 2014-12-30 11:56

Interesting...the magnetic disc on your motor is even slightly different than the one I pulled from stock. The issue I see is in how to document this for those who get either motor. With the encoder wheels and some of the boards looking different I need a way to identify which is which.

New gear motor product ID 28819 counts per output shaft resolution?

Comments