# New products: Magnetic quadrature encoders for micro metal gearmotors

Posted by Jan on 2 October 2014

Everyone wants encoders on their motors. If you think you don’t, you just don’t know it yet. I think the main reason is that we really just want motors to do what we tell them to do, but they don’t. One of the most common beginner questions we get is some variation of, “why doesn’t my robot go straight?” or “I got two of the same motor but they do not go the same speed; is something wrong with one of them?” More seasoned robot builders know that since there will always be variations in everything that contributes to a motor’s performance, our best hope is to put a sensor on the motor to monitor what is actually happening and then adjust the motor control to make reality better match our desires.

Consequently, we get a lot of requests for encoder options for products like our 3pi robot. Unfortunately, encoders can be expensive or difficult to make. Many high-quality or industrial motors are readily available with encoders, but they might have resolutions that are overkill for small robots and overburden their limited computing power. We have been working on various solutions for our favorite micro metal gearmotors for years, dating back to one of our first custom wheels, where we incorporated teeth in the white hub to contrast with the black tires:

That approach has various limitations, including working only with one particular wheel. One drawback that we did not expect was that the variations in the sensors and the geometry of their alignment relative to the wheel made the raw outputs of the sensors unusable without individual calibration. We have to set the two little potentiometers on each board to the right spot for each unit we make, which is time consuming and makes the product cost go up.

We made substantial progress on this problem with the optical encoders we released last year, which involved putting sensors on the back of the motor in a more traditional encoder arrangement:

The raw output of the sensors is much better than on the older encoders, to the point that it can sometimes be used without any extra conditioning electronics (though we do not recommend it):

Longtime observers of Pololu have probably noticed that we have a bottom-up product development approach, where we first develop components we need for the robots we want to make before developing the final robots. So, for instance, you could buy the track set that we were developing for the Zumo robot long before the complete robot was available, and we developed and released the switching regulators used in our A-Star Mini programmable microcontroller boards long before we released the A-Stars. These intermediate products let us distribute our development costs and limit the chances that some unexpected challenge will derail a much larger project. It’s gratifying to see our components make it into so many other robots that we do not make, which is especially common now with Kickstarter-type projects.

The same strategy is in play with the encoders, where we tried to develop an intermediate product that would be useful on its own while serving as a stepping stone toward our bigger goals. That is one reason we made the PCB fit within the motor profile, with the half-hole pads along the edge. The idea was that this would make the motor with encoder a module that could be soldered directly onto another main PCB, the way the motors are on the 3pi robot.

However, I wasn’t quite happy with that solution since it required an extra PCB, and I kept looking for ways to get an encoder on these motors without needing any intermediate circuit boards. One avenue we pursued was with U-shaped, slot-type IR sensors. These were quite common on computer mice when they still had balls and rollers instead of cameras, and an encoder wheel blocking a light beam should give more consistent results than a wheel reflecting some light. I found a few sensors small enough for the motors, and we injection-molded some encoder discs:

The solution was still somewhat unwieldy from an assembly perspective since the U-shaped sensor locked the encoder disc and motor into position. I am sure we could have made this work somehow, but I also wanted a solution that would not be too complicated to assemble since I want to have kit versions of our robots.

So we continued exploring other avenues. Many of our larger gearmotors are available with magnetic encoders, so we started exploring getting our own custom magnetic discs made, in the hopes that we could make this kind of arrangement work:

As I hope you have guessed if you have read this far, we now have those magnetic encoder wheels available! It will still be a while before we have them integrated into a robot with built-in encoder support, but as usual, we want to make these components available for others to start using in their own robots. We have also made small boards like the optical encoders so that people looking for encoders without designing their own PCBs can get up and running right away; these are available with the magnetic discs in our new magnetic encoder pair kit. We got some negative feedback about the difficulty of soldering to those half-holes on the edge of the PCB, so we decided to make these new boards a little bigger and include full holes. (If you want that flush-mount option, you should be able to get it by grinding off a bit of the board.)

One of the great features of the new encoders is that the hall effect sensors they use have built-in circuitry to provide hysteresis and digital outputs, which can connect directly to a microcontroller or other digital logic. Check out that beautiful quadrature!

As we continue working on these, we expect to update the product pages with sensors we have verified work and with the proper geometry of the sensors to make the 3pi-style motor mount work.

I love your encoders and micro metal gearmotors. The magnetic encoder ones are going to be even better. Is there any hope of having a micro metal gearmotor with a "better" gearbox? I have done some life testing, and the gearbox is the first thing to fail. The output shaft seized after 5.7 days of cycle testing.

526,517,862 pulses from the encoder sensor
/ 6 pulses per revolution of the motor shaft
/ 297.92 revolutions of the motor per one revolution of the output shaft
= 294,552 turns of the output shaft
We have evaluated many gearbox suppliers, and the ones we use are the best we know of. We would definitely like to hear more about your tests; can you provide us with more information about your setup? You could email us if the comments here on the blog are not convenient for getting into details.

- Jan
I will put together a package of information and send it to support@pololu.com if that is okay.
That sounds great; thanks.

- Jan
I sent the email a few minutes ago.
That is so true about every motor needing an encoder. The 3pi does do surprisingly well without encoders, but still would be much more awesome with encoders. The Zumo would also be much improved with the addition of encoders; I know that it is quite cramped around the motors, but would these possibly fit on a Zumo?
Yeah, they fit in there! It will still take some work to design the right corresponding PCBs and to come up with a good assembly procedure, so we're still at least a few months out from having a complete encoderized Zumo.

- Jan
I have bought some optical encóders from you. The ones for the special wheel and the newer back shaft optical. If I tell you truth I am dissapointed with them. The "half cut holes" was a very clever idea, but also a bad mecannical idea. They broke very easily if you use with cables, unless you have a very-very soft/flexible cables, or if you unsolder/desolder a few times.
And now you release this magnetic encoder with only 12cpr... I am more dissapointed. I expected much more from you, One of the top robot contests in world is micromouse, they usually use 256 to 1024 cpr encoders. I expected you released some kind of magnetic encoder, but a full sensor, not some hall effect sensors. Something like Austria Microsystems sensors (AS5040, AS5047 for example). And for the pcb disposition, take a look at this:
https://www.tindie.com/products/EmbeddedArea/a-rotary-magnetic-encoder-for-your-gear-motor-assembled-as5040-magnet/

I think that idea is near to perfection: self portable on motor, only one cable for encoder+motor, small size, great resolution. Let's do some encoders similar to that. Today's robotics need a more sophisticated encoder than a 12/16 cpr.
dragonet80,

Don't forget that these are often on a geared motor. Those 256 and 1024 cpr are probably(maybe, not sure) on a 1:1 ratio motor. For the pololu system you get 12cpr on the motor shaft side. So on a 30:1 motor thats 12x30 = 360 (wheel/output)cpr.
On the 1000:1 geared motor thats 12000 cpr! Talk about resolution. Sure you lose speed, but you gain torque and precision. Engineering is all about compromise. The 30:1 should give you the speed and cpr for just about any hobbyist's needs.
Hi Sean,

Speaking about micromouse motors, most top robot builders use motors from quality (and very expensive) brands (maxxon, faulhaber, portescap, ...). In those motors the encoder is set to the motor shaft, so 1024 crp compares directly to 12 cpr, and thats independent of the wheel reduction gear.
In the event that your application does not need that such a resolution, those sensors are programmable and you can reduce the output resolution.

As I pointed in the link from Tindie, there are ways tu use Pololu micro metal gear motors with encoders and obtain a very decent encoded motors. In fact that is the same the big brands do, of course, they do it in an upper level of finishes and refinement.

Jan, do you think Pololu can do something similar to that? That will rock the market in hobby encoder motors.
dragonet80,

Thanks for your feedback. I'm very excited about 12 CPR because I think it's close to ideal for robots like our 3pi and Zumo. With a 30:1 gear ratio, we get 360 CPR on the gearbox output, and with a 32 mm wheel, that comes out to about 0.25mm linear resolution. You can see what kind of performance you can get with that combination on Paul's dead reckoning robot:

These motors can go up to about 30,000 RPM, or 500 revolutions per second, so with 12 CPR and two channels, that gives us about 12 events per ms for our controller to deal with, which starts getting close to the limit of what is practical on a microcontroller without needing special hardware counters. I realize not everyone needs 30k RPM, and we are working on slightly higher resolutions versions of our magnetic wheels (to give us 20 or 28 CPR).

Those absolute position sensors are very nice, but they are also very expensive, and my general sense is that they are overkill for these motors. Can you share more about your applications and why you need such high resolution?

- Jan

In micromouse they (me not yet) use 1:5, 1:4 gear ratios. 99% of them use 32 bit micros with integrated encoder peripheral inputs. They need a very fine speed and acceleration control over each motor. They also use it for dead reckoning combined with giros. They need high cpr counts on their encoders to accomplish all of that. You can take a look at a nice blog from the USA at: http://micromouseusa.com/

In linefollowers we use from 1:10 down to 1:5, 1:4, 1:3 gear ratios. We do not yet need the exact same power nor the so high cpr count as Micromousers, but as per year the robots are evolving very fast, they for sure will need soon.

Top of the art, maxxon, motors are really expensive. But hobbysts cannot afford a +$200 per motor to mount their robot. Pololu, like Sparkfun and a very few others, is a reference for all of us hobby robotics. Sensor itself is not so expensive: Price (1k)*$ 4.21 http://ams.com/eng/Products/Position-Sensors/Magnetic-Rotary-Position-Sensors/AS5047D.

Anyway, that 28 cpr does sound nice. Can you tell me when are you going to have them in stock?
\$4.21 is quite expensive for us, but I will look into those sensors and keep them in mind. I'll also add a 4 CPR version of the magnetic wheels (half N half S) to our to-do list so that even if we do not have the whole solution right away, we can have magnets for people to make their own systems like that one you linked to on tindie.

We are just starting to work on the additional resolution wheels, so we do not have availability estimates yet or even know how far we can go. It looks like 28 CPR will not be feasible, so we will try 24 CPR even though that will likely require a different sensor arrangement than the 12 CPR version.

- Jan
Jan, here you have another way for an encoder:
http://www.melexis.com/Position--Speed-Sensors/Speed-Sensors/Cam-Sensor-3.aspx

Yo do not need a complex multipole magnet, but a metallic tooth gear and a simple magnet. I do not know the maximum cpr number you can obtain in this way (for sure it can't go as high as an AMS sensor), but it looks like it can overcome that 12 cpr.

Some calculus for the robotics people. If you are trying to control the motor speed (the same for acceleration), you are going to get a conclusion: you need lots of cprs. Fast robots run easily at 3 m/s and they can peak near double. A loop control time of 1 ms (some do it faster) gives you an error of 3mm (affordable in a linefollower, bad in a micromouse). If motor is spinning at 15000 rpm (250 revolutions per second, 0,25 revolution per millisecond). With a 12 cpr encoder attached, at that speed you will only have 3 cpr per millisecond. If you lower the speed (say to 1 m/s) then you have only 1 cpr per millisecond. That is totally useless in speed control. We have two options: reduce loop period (say 100 ms) but that gives an error of 300 mm (dissaster) or increment encoder pulses per revolution (complex/expensive).

At this time, Pololu encoders are very nice to mesure distance (also dead-reckoning), but not for speed control.
Thank you for continuing to push on this. I've seen that Melexis sensor before, but I think the magnet for the AMS sensor should be pretty simple to make (and we're already working on it), so I suspect that will be the easier route.

As for your performance calculations, I definitely agree that 12 CPR is lacking if you want decent resolution per millisecond. We are targeting 8-bit MCUs with no special quadrature decoding hardware, and I think these 12-24 CPR units are very well matched to that. It's definitely good to hear from customers pushing for more, and we are aware that much better MCUs that can deal with high frequency quadrature are getting more and more available.

- Jan
Hi, in the meanwhile we developed our own encoder based on AS5040 and the original idea of the one found on Tindie (it seems it has disappeared):
https://dl.dropboxusercontent.com/u/14855888/eRobot.cat/IMG-20150215-WA0024.jpg

First prototype in the right (black pcb) works but had some mistakes on pcb, we had to "dremel" solve it.
Second prototype in the left (blue pcb) problems addressed and size shrinked a little bit.

Both use the same pin configuration as your pololu optical and magnetic versions, so they are compatible and direct-replace (except for the longer size due to use of two pcbs instead of one). They fit the Pololu motor exact size so they are smd like solderable (you do not need to use wires or cut pcb. I got the idea from your original optical encoder pads, but those broke easy (they were half cut), these are full pads and more resistant.
Wow!!! So impressive!!!
No excuses now Pololu, we want "our 1024-step-encoder", better if its not just for the micrometal motors :)
Any news about fitting in a Zumo ? Several month has passed now...
Thanks for checking back. We should have some relevant and exciting news in the next week or two; keep an eye on our blog!

-Jon
Actually, putting a high resolution encoder on the micro metal gear motors would be both a waste of time and expense. Brushed servo motors always have a large number of commutator segments to both reduce the torque ripple and to provide for finer positionability (as well as ball bearings, etc). These micro metal gear motors only have 3 poles, which is the minimum required for any self starting DC motor, and as a result they are therefore incapable of fine positioning. A higher resolution encoder would also put more strain on the microcontroller at any given motor speed since more interrupts would be generated per motor shaft revolution. I say this as a motion control (among other things) designer for decades. If you use a higher resolution encoder a far more expensive motor would also be required to effectively use that additional resolution.
It seems that the encoders that come pre-installed on some of the micro metal gear motors have either 48 or 64 CPR which would be far better than 12.

Is it possible to offer these higher resolution encoders as independent items? The mounting and general appearance seem very similar to the 12CPR ones.

Bob
Hello, Bob.

None of our Micro Metal Gearmotors come with encoders pre-installed. You might be referring to either our 25D gearmotors or 37D gearmotors with encoders.

We do not carry the encoders for either the 25D or 37D gearmotors separately, and they are not compatible with our Micro Metal Gearmotors.

For our Micro Metal Gearmotors, the highest CPR we carry is our Optical Encoder Pair Kits for Micro Metal Gearmotors used with the 5 tooth encoder wheel, which gives a CPR of 20. However, it is might be hard to get clean readings when using the optical encoders and 5 tooth wheel. Instead we recommend using our Magnetic Encoder Pair Kit for Micro Metal Gearmotors with a CPR of 12.

-Derrill
Was there any progress to making a 24 cpr magnetic encoder available, as was mentioned in Oct. 2014?
Unfortunately, we were not able to get the magnetic field strong enough with more segments on that small of a disc. We might still try with a larger disc, but that makes it less appealing for us since it wouldn't be a drop-in replacement in applications like the Zumo 32U4, plus the larger size would mean more new molds to make, so it's not a high priority project right now.

- Jan
Any changce of providing Arduino libraries for new Pololu's Magnetic Encoders?
Hello, Dejan.

Our magnetic encoders are standard quadrature encoders, so any libraries intended to work with quadrature encoders should work; there are several listed on Arduino's "Reading Rotary Encoders" page.

-Brandon
Hi! You've done great work with your encoders, which I intend to use in my next project. One question: What maximum RPM do you recommend in order to avoid missing steps?
Greetings, Tom
Hello, Tom.

The rise time for the signals is very quick and the maximum signaling rate for the encoder is generally limited by the speed of the microcontroller processing the signals.

-Nathan
I notice the Zumo 32U4 has encoders built in and the Zumo shield version does not. Do you have enoders that would fit the Zumo shield version?

I have on Zumo 32U4 but I'd like to use the shield version so that I could use a different MCU and custom board MCU board.