Pololu Blog » Engage Your Brain »
New products: Magnetic quadrature encoders for micro metal gearmotors
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:
Encoder for Pololu wheel 42×19mm with wheel, motor, and bracket.
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):
5V encoder version, motor approx. 30k RPM: 5-tooth wheel at optimal distance from sensors.
One of many Kickstarter projects to incorporate Pololu components.
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:
Prototype encoder wheels for interrupter-style sensor solution for micro metal gearmotor encoder.
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:
Pololu magnetic encoder concept drawing.
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.)
Magnetic Encoder Pair Kit for Micro Metal Gearmotors, 12 CPR, 2.7-18V (old version).
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!
Encoder A and B outputs of a magnetic encoder on a high-power (HP) micro metal gearmotor running at 6 V.
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.
Magnetic encoder test board for sensor geometry evaluation.
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
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:
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.
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.
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.
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?
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?
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.
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.
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.
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.
No excuses now Pololu, we want "our 1024-step-encoder", better if its not just for the micrometal motors :)
Is it possible to offer these higher resolution encoders as independent items? The mounting and general appearance seem very similar to the 12CPR ones.
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.
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.
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.
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.