Q? about motor encoder and wheel encoder

https://www.pololu.com/docs/0J18/18 wheel encoder libraries link.
https://www.pololu.com/catalog/product/2286 motor and encoder link
Can i use wheel encoder libraries for some motor encoder like 75:1 Metal Gearmotor 25Dx54L mm with 48 CPR Encoder?
If I can’t use the wheel encoder libraries. I would like something like the Wheel encoder libraries that pololu provided. But it’s for something like 75:1 Metal Gear motor 25Dx54L mm with 48 CPR Encoder.can someone help me get started on the code?
does the motor encoder take data even if a I manually rotate the router?

Look under the faq for those motors. I believe they link some arduino code that is good.

Alternatively, look up tutorials for “arduino quadrature decoding”

The key bit is that you won’t be able to run the motors too fast. You might want to move to a chipkit32 system (its a faster processor) in order to keep up with the interrupt speed, or you would want to get a quadrature decoder chip to do the heavylifting.

If you’re very unfamiliar, it will be a bit of work and some effort looking up tutorials. But tutorials exist, a search engine away.

Hello, Hovic.

Yes, the PololuWheelEncoders library is compatible with the encoders on the 75:1 Metal Gearmotor 25Dx54L mm with 48 CPR Encoder.


Thank you Tomek ,and David for your posts
that really made my day. :slight_smile:

With the robot is on and you push the robot manually with you hands make the wheel turn. Will the motor encoder still register the rotation of the metal shaft or router and return the count/rotation? I guessing that i have too have a separate power supply for the encoder to to still get data when there is no power going to the motors.
(motor can be used as a generator too correct)
This relates to my next question about the motor’s Red wire and black wire feed back power into pins motor1A&B and Motor2A&B. would i need to worry about it?

Yes, as long as you are supplying the encoder with the necessary logic voltage.

Even when there is power going to the motors, you likely want a separate power supply for the encoder logic that is at an appropriate level for your microcontroller. Please read the product page of the motor for information about the wires coming from it and how to connect them.

No, you shouldn’t worry about that. The motor and encoder are separate, and they can be used at the same time.



It sounds like David might not have understood what you were asking with your last question. Are you talking about A and B outputs of the encoder or A and B outputs of your motor driver? If it’s the former, see David’s answer. If it’s the latter, read on!

If you rotate the motor by hand, it will act as a generator, which usually will be safe unless you are rotating the motor fast enough to produce a higher voltage than your system can handle (this is typically not something you will be able to easily do by hand). For example, if you manually spin the motor as fast as it would turn if you supplied it with 6 V, the motor will generate 6 V. If you manually spin it twice as fast as this, it will generate 12 V. If the voltage you generate is higher than VIN, you could be sending current back into your power supply, and your VIN voltage might rise. Another thing to consider is that spinning the motor manually might generate enough voltage to partially power your system if you don’t have an external power source already connected, which could cause various components to temporarily start to run when you aren’t expecting it. So the short answer is: it’s probably not something you need to worry about, but you should exercise caution if you will be manually spinning the motor very quickly.

- Ben

Thanks again for the posts.
Have hear of the Aldebaran NAO Robot?
NAO robot Has a feature can be almost explain as stop motion picture (ex.clay animation)
someone straighten NAO’s arm, someone moves NAO arm down and someone open NAO’s hand. then that is done; someone hit play and the robot goes through these motion.
I would like to use the Orangutan SVP.
better example would be 3pi maze solver, the only difference is a human is solving it by push the robot down the right path to the finish. then the robot uses the data that it got when the human was pushing it. I would also like to be save in EEPROM so i can turn the robot off and then turn it back on. then reuse the data.

i would like to do something this,but on simple robot using EEPROM.
I got the Inspiration from the NAO Video that i saw, but can’t remember which video it was. :frowning:


  1. It won’t save anything until the robot start moving. use the motor encoders to get distance straight away and turns( moving the bot by hand).
  2. save this data in EEPROM and straight and turns are save differently.
  3. another program read the EEPROM to repeat the previous motion.

this is how I want my program to work.
if the bot is being pushed straight from where it started it would be saved in ‘S1’ or some kind of string(m1,m2 count/rotation are positive) go on for all the straight (‘S2…’) away and it take in the amount of rotations so the count reset for each straight away and turns.but save it count/rotation before it reset.

So I need some help start this code if any one help me or if this is even possible.
mostly with Initializing the pin that i want to save data to the EEPROM .
Please help.
I think in pictures not in word, so i struggle in grammar :frowning:
I have a high functioning Autism

What you’re trying to do it sounds fairly complicated, and if you have to ask if it is possible, I suspect it is beyond your current capabilities as a programmer. My suggestion is for you to start simple and ask very specific questions if you get stuck (e.g. “I need help to start this code” is way too general). Here are the steps I think you should take before you try your more ambitious project:

  1. Learn how to read and write to EEPROM. There are lots of examples out there on how to do this on an AVR. If you think you are most of the way there but it still isn’t quite working, post your code here and ask about what is still confusing you.

  2. Learn how to make your robot drive around smoothly using encoder feedback. Specifically, try to make your robot drive straight at constant speed, and try to make your robot turn in place to a desired angle. You will probably want to use PID for this. If you don’t have experience with PID, you should do some research and then ask questions about what you don’t understand.

Generally speaking, you don’t have much EEPROM to work with, so you will need to find a way to simplify your path data before storing it. I expect this to be the hardest part.

- Ben

Is there a product that i can insert a SD card to store the data?

Unfortunately, I don’t have anything specific to recommend to you. Have you tried searching around?

- Ben


static int getCountsM1()

static int getCountsM2()

how much resolution will i lose when i use the wheel encoder libraries for the 75:1 Metal Gearmotor 25Dx54L mm with 48 CPR Encoder ?

I’m not sure I understand your question. Assuming you aren’t using some exceptionally long custom interrupts, the library will register every encoder transition.

- Ben

Thank you Ben for answer.
i wasn’t sure that the resolution for the wheel encoder of 3mm/count would be the same for the Motor encoder.
You wouldn’t happen to know the mm/count for the motor encoder and how often does the motor skip? I guessing it’s rare for the motor to skip and in a result it gives false data.

I think you are confusing two different products. The measure of 3mm/count is specific to our encoder for Pololu wheel 42x19mm and has nothing to do with the library code used to read it or the 48CPR 25D motor you have been talking about. In general, our encoder library just counts the edges of the quadrature encoder pulses; the resolution is specifically a function of how the encoder relates to the wheel.

For the 75:1 Metal Gearmotor 25Dx54L mm with 48 CPR Encoder, the encoder produces 48 counts per rotation of the motor shaft, and the motor shaft rotates 75 times for every one rotation of the gearbox output shaft, so, as the product page states, you get approximately 3592 encoder counts per revolution of the gearbox output. If you want to convert this into a linear resolution, you need to know the circumphrence of the wheel connected to the gearbox output. For example, if you use our 90x10mm wheel, the circumphrence is 90mm*pi = 273mm, and over that circumphrence you get 3592 counts, so your resolution would be:

273mm/3592 counts = 0.08 mm/count

Assuming the encoder is functioning properly, it will never miss a count. If your code is written poorly, you might fail to catch a transition, though. Our library uses interrupts to trigger off of the encoder transitions, so it shouldn’t miss any as long as you don’t set up your code in a way that would prevent those interrupts from being able to trigger.

- Ben

Thank you Ben for your answer