Make Your Own Encoders
Lots of encoder chat here lately, so I'm starting a·dedicated·thread on the specific encoders I used on my Homebuilt platform. I had great results.
My·friend "Hollywood" made the attached encoder disks·in Adobe Illustrator, the one I used has 36 b/w stripes and the new one has 72. Ten and five degrees, respectively.
An encoder site with some info: http://groups.csail.mit.edu/mac/users/pmitros/encoder/
I used·this sensor : http://www.junun.org/MarkIII/Info.jsp?item=48·with·this circuit:·http://www.acroname.com/robotics/parts/R64-P5587.html
That tiny chip has internal signal conditioning and Schmidt triggers. It·outputs·a clean digital signal that I fed directly into a Stamp input pin.
A word about the encoder disks: they must be mounted PERFECTLY to achieve consistency. Perfectly flat, true, and concentric. Mount your paper encoder disk centered perfectly on a strong, flat background. Wobby or eccentric encoder disk will give the same results as wobbly or eccentric wheels. Do not skimp or rush this step. Make your encoder disks PERFECT.
Some printers may print these as ovals, which are utterly useless. Use calipers or a compass and verify that your encoder disks are PERFECTLY circular.
Properly implemented, more stripes can yield better resolution and an improvement in accuracy, but in the end it comes down to a demand for absolute mechanical perfection in your drive system.·Just because·you·use a motor encoder and get hundreds of pulses per revolution (PPR), it doesn't·guarantee you will get incredible repeatable accuracy. Wiggle your wheels in all directions, be brutal. Any play, wiggling or flexing anywhere is the beginning of the end. All the processing power in the world can't make up for a sloppy transmission or·an eccentric·wheel. There are many mechanical factors.·Transmission backlash (gear slop) kills repeatability. Any wobble, slop, or end play in your·wheel axles kills repeatability.·Wide tires and tire tread work against repeatability.· Pneumatic tires work against repeatability, they are mushy and usually far from circular. Higher tire pressures may lead to better results. Tank treads and 4-wheel skid steering are very difficult to get any repeatability from whatsoever.
Make your encoder disks as large as possible and locate the·encoder sensor as close to the outer diameter of the wheel as possible. This gives you a wider stripe to read, no matter how many stripes you have. The sensor must be oriented properly. The two dots (LED & PTX) on the sensor must be oriented radially, not circumferentially for best repeatability. A line connecting the two dots should intersect the center of your axle. Experiment with the gap between your sensor and encoder disk for best output·results. I used about 0.080", but·that may change for different paper and·printers.
Two pics of my encoder installation attached. This allows my robot to drive a very straight line: http://www.youtube.com/watch?v=Trv682XZ_8c
Hope this info is of some help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Post Edited (erco) : 1/22/2010 6:20:19 AM GMT
My·friend "Hollywood" made the attached encoder disks·in Adobe Illustrator, the one I used has 36 b/w stripes and the new one has 72. Ten and five degrees, respectively.
An encoder site with some info: http://groups.csail.mit.edu/mac/users/pmitros/encoder/
I used·this sensor : http://www.junun.org/MarkIII/Info.jsp?item=48·with·this circuit:·http://www.acroname.com/robotics/parts/R64-P5587.html
That tiny chip has internal signal conditioning and Schmidt triggers. It·outputs·a clean digital signal that I fed directly into a Stamp input pin.
A word about the encoder disks: they must be mounted PERFECTLY to achieve consistency. Perfectly flat, true, and concentric. Mount your paper encoder disk centered perfectly on a strong, flat background. Wobby or eccentric encoder disk will give the same results as wobbly or eccentric wheels. Do not skimp or rush this step. Make your encoder disks PERFECT.
Some printers may print these as ovals, which are utterly useless. Use calipers or a compass and verify that your encoder disks are PERFECTLY circular.
Properly implemented, more stripes can yield better resolution and an improvement in accuracy, but in the end it comes down to a demand for absolute mechanical perfection in your drive system.·Just because·you·use a motor encoder and get hundreds of pulses per revolution (PPR), it doesn't·guarantee you will get incredible repeatable accuracy. Wiggle your wheels in all directions, be brutal. Any play, wiggling or flexing anywhere is the beginning of the end. All the processing power in the world can't make up for a sloppy transmission or·an eccentric·wheel. There are many mechanical factors.·Transmission backlash (gear slop) kills repeatability. Any wobble, slop, or end play in your·wheel axles kills repeatability.·Wide tires and tire tread work against repeatability.· Pneumatic tires work against repeatability, they are mushy and usually far from circular. Higher tire pressures may lead to better results. Tank treads and 4-wheel skid steering are very difficult to get any repeatability from whatsoever.
Make your encoder disks as large as possible and locate the·encoder sensor as close to the outer diameter of the wheel as possible. This gives you a wider stripe to read, no matter how many stripes you have. The sensor must be oriented properly. The two dots (LED & PTX) on the sensor must be oriented radially, not circumferentially for best repeatability. A line connecting the two dots should intersect the center of your axle. Experiment with the gap between your sensor and encoder disk for best output·results. I used about 0.080", but·that may change for different paper and·printers.
Two pics of my encoder installation attached. This allows my robot to drive a very straight line: http://www.youtube.com/watch?v=Trv682XZ_8c
Hope this info is of some help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Post Edited (erco) : 1/22/2010 6:20:19 AM GMT
Comments
I look forward to implementing a system using encoders soon.
Very helpful.
Happy roboting,
Scope
(and, ya, I know that's not a real word) [noparse]:)[/noparse]
Will try this when my Allectronics gear motors arrive.· Thanks again for spotting/posting those!
Steve K.
·
BTW Nice job!!!
Jax
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If a robot has a screw then it must be romoved and hacked into..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
@Jax: Thanks. My simple straight-line code attached for your consideration. Not much there yet but it works fine!
@Whit: Walk a mile in the poor sensor's moccasins. Try looking at the encoder disks from .080" away while they're spinning!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If a robot has a screw then it must be romoved and hacked into..
Kim
http://list.dprg.org/archive/1998-July/005620.html
And here's an encouraging link to using odometry with a PID controller:
http://www.seattlerobotics.org/encoder/200108/using_a_pid.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Post Edited (erco) : 1/25/2010 10:09:26 PM GMT
I got further with my encoders, and am now working on some code. I borrowed what Duffer posted on the stinkray thread. I got the motors spinning and have a nice quadrature signal now. I had to change the code a bit cause I'm using HB25s instead of the controller on the MRS1 board (PWM servo method instead of dutycycle method). I sure am jelous of the resolution they get with the usdigital encoders, but I'll first try more spokes on my encoder wheels. My applications will be mostly out-doors so I should be alright with that for now.
I'm working with the quadrature encoder obex·to test·RPM sent to an obex by BR for a moving recursive average then to a PID obex for closed loop speed control.
Anyway, here are some pics of my home rolled encoders..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Post Edited (erco) : 1/28/2010 6:05:18 AM GMT
Plans are long term mission, re-con deployment, in country,·securing borders, mine field mapping/marking.
Yes the BOE remains, hence the name "PiggyBot". The BOEBot attaches with magnets and unplugs, so I can bring the brains inside for·indoor testing·by the fire place so my "pooter don't get so cold out in the shop". MRS1 board for motor control, Prop proto for mission/nav/com/GUI. I still have to add the GPS and tranceivers to the proto board.
Got room for more flux capcitors in the box, but I might add a linux board for vision instead.
Here is the latest ultra-sound from my baby...
The tach encoder uses one sensor and one I/O pin; it requires constant monitoring to count pulses. Quadrature encoders use two sensors 90 degrees out of phase, as well as two I/Os and twice the processor overhead to monitor both continuously. Miss one pulse and all is lost. One alternative is an absolute encoder (such as on a robot arm joint), which requires many I/Os (eight or more, one per bit of resolution) but doesn't require constant monitoring. The processor can decode the angular position of the encoder from an occasional snapshot of all of the I/O pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
If send the same PWM signal to both the HB25 controllers the individual wheel speeds are different due to their internal friction co-efficients. With the feed-back from the encoders I can average the speeds that they are running into a PID routine to vary the PWM to compensate the output to the HB25s to drive in a straight line, so that the faster wheel slows down to match the slower wheels RPM. I can also adjust speed according to terrain loads.
Further, I can also use the feedback for error trapping (ie. I did not send a run command to the motor, but the encoder is counting, send stop command to motor drive!). I am having problems with alien cross-talk with the cables going to the HB25s. If I have just one motor running the other motor some times picks up a false pulse (induced noise) and goes awry. I will change those cables with shielded audio (walkman head phone) cable to see if that helps.
Besides all that it was pretty inexpensive to implement. JameCo.com has the reflective sensors pn 1069835 for $0.99 each. The schmidt board and connector stuff was, I'm guessing $5.00 more for parts, so about $10.00 total.
I have 10" wheels with pi*D=31.4 circumfrence, 9 "spokes", 4 ticks per spoke gives me 36 ticks per rev or 10 degrees of resolution which works out to 0.872" of resolution +/- <0.872". I will work with a higher resolution encoder disc ie 36, 72 spokes, but ideally an encoder on the motor before the gear reduction would give me a resolution much higher ie 200:1 ratio gives 0.004" resolution, what I have should work fine for my current application outdoors.
As agfa pointed out this is not correct -- quadrature encoding increases resolution. This is because an edge is read on encoder when the other encoder is in the "middle" of stripe -- in other words, you have your "actual" edges plus the edges that would end up "virtually" in the middle of a stripe.
Second, quadrature has a huge, huge payoff in terms of accuracy, esp. when wheel slop is taken into account -- it's not just that you can get direction from the encoders, but that even if the wheel is jiggling back and forth, your encoder ticks will remain accurate, because each direction change adds or subtracts a tick from your count. In a single encoder setup, each "tick" would count as real distance/velocity.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
You're 100% right, a QE used as a wheel encoder will give double the pulses and double the resolution as a tach encoder using the same encoder wheel.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
agfa
I was trying to make that point when I said "plus 4 ticks per spoke instead of 2 ticks for a tach", but you explained it much better.
I was just thinkin and am throwing this out, but I could just use a prop cog counter and keep track of the delta time between ticks based on the current rate of time between ticks, and come up with an approximation of ticks *2 or *4 ie and double my resolution "artificially", almost kinda like a PLL multiplier. Just a thought.
Grey or is it Gray code is interesting and worth mentioning on an encoder thread. Where there are four three or more detectors, but the encoder wheel/stripe is printed so that only one bit changes per tick instead of a binary count where two bits might change simultaniously. Theyre designed for "electrically noisey" environments.
Post Edited (rpdb) : 2/4/2010 4:09:03 AM GMT