Shop OBEX P1 Docs P2 Docs Learn Events
Make Your Own Encoders — Parallax Forums

Make Your Own Encoders

ercoerco Posts: 20,244
edited 2010-02-04 06:18 in Robotics
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

Comments

  • ScopeScope Posts: 417
    edited 2010-01-21 15:55
    Mega-thanks!!!

    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]
  • stevekstevek Posts: 10
    edited 2010-01-21 18:20
    That thing drives straighter than I do!· At this point my wife yawns and says, Yeah, so what's your point!· Did you notice any difference with different resolution prints?· I suspect concentricity and regularity would make more difference than sharp lines.

    Will try this when my Allectronics gear motors arrive.· Thanks again for spotting/posting those!

    Steve K.
    ·
  • GWJaxGWJax Posts: 267
    edited 2010-01-21 21:31
    erco, will you post your code for that platform you showed. I'd like to see how you made it correct it's travel. I haven't done any encoder programming in my robots but I do have to check them in copiers all the time. Thanks in advance buddy...

    BTW Nice job!!!

    Jax

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    If a robot has a screw then it must be romoved and hacked into..
  • WhitWhit Posts: 4,191
    edited 2010-01-22 06:09
    Enoder wheels sure give your eyes the hebbie geebies! Thanks for the info erco

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • ercoerco Posts: 20,244
    edited 2010-01-22 06:42
    I uploaded a modified·36-stripe encoder disk tonight. Apologies, the original one didn't "take".

    @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."
  • GWJaxGWJax Posts: 267
    edited 2010-01-22 16:22
    Thanks erco!! I look this over on the weekend!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    If a robot has a screw then it must be romoved and hacked into..
  • FORBES_KFORBES_K Posts: 3
    edited 2010-01-22 17:37
    Wow, this is super helpful! I can't wait to get started!

    Kim
  • ercoerco Posts: 20,244
    edited 2010-01-25 20:52
    Here's an encoder·reference about an off-center encoder disk. This guy was using an analog sensor and could measure the voltage variation around the disk due to the eccentricity. That would lead to a phase shift after the A/D converter (LM339 in this case) and then to a position error,·just like an off-center wheel.

    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
  • rpdbrpdb Posts: 101
    edited 2010-01-28 01:19
    Hi erco and all,

    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..
    2048 x 1536 - 165K
    2048 x 1536 - 307K
    2048 x 1536 - 284K
    1536 x 2048 - 283K
    2048 x 1536 - 254K
  • rpdbrpdb Posts: 101
    edited 2010-01-28 03:29
    Here is a shot of the schmidt board mounted on "PiggyBot", I also put in a OptoMOS relay so I can on/off the whole setup with one pin. It draws about 140 mA on 10ua off. I focused the reflective sensors on the analog side and my disk to sensor is about 0.25" (quarter inch). I have plenty of runout on the wheels but the signal is good. I am curious to see what the max number of spoke are that I can reliably run.
    2048 x 1536 - 373K
    2048 x 1536 - 308K
  • ercoerco Posts: 20,244
    edited 2010-01-28 05:42
    @rpdb: Cool stuff. Batteries or cargo inside that silver case? Do I see a BoE-Bot in there? Please tell us more about your bot. Plans, goals, etc.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·"If you build it, they will come."

    Post Edited (erco) : 1/28/2010 6:05:18 AM GMT
  • rpdbrpdb Posts: 101
    edited 2010-01-28 07:32
    Batteries? No, they are flux-capacitors containing no less than a jigawatt, disguised as batteries,·but I am having·problems with the time travel, I keep getting older. Not too old to play with a bot though. (let's review.. 6.25 *10^18 electrons.. jigawhatsits..nevermind)

    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...
    2048 x 1536 - 288K
  • agfaagfa Posts: 295
    edited 2010-02-02 04:31
    I see that rpdb built quadrature encoders, and I recently purchased a set of motors that·have them.· I don't see the advantage of these over simple tach encoders in this application, other than a higher resolution.· Is there something I'm missing?
  • ercoerco Posts: 20,244
    edited 2010-02-02 05:20
    QEs don't necessarily yield higher resolution. In addition to the angular displacement magnitude, quadrature encoders indicate direction of rotation. Presumably you know which direction your are driving your motors, so you might not need the directional info. If your robot may get pushed backward (rotating the wheels) or roll downhill (opposite to the intended direction of travel), the directional info may be useful, assuming there is no wheel slip.

    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."
  • rpdbrpdb Posts: 101
    edited 2010-02-03 02:40
    @agfa- My intention is to use feed-back from the quadrature encoders for a closed loop speed and distance count. The motor/gear combo I am using is off an old PowerWheels Barbie car that my niece abused about 20 years ago. I just found new motors at JameCo for $3.35 each, the old motors had mud-dauber wasp nests inside and tore up the cooling fans when I applied voltage. I cleaned out the gear boxes and regreased them, but they are imperfect spur gears, not helical, and have various points or degrees of loading on the motors due to gear mismatch, friction etc. that cause the wheels to speed to slow/speed-up based on load, thus no straight heading.

    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.
  • rpdbrpdb Posts: 101
    edited 2010-02-03 03:47
    @agfa-about the only thing better about a quadrature encoder over a simple tach sensor is the added bonus of direction sensing, at the cost of using more I/O pins, plus 4 ticks per spoke instead of 2 ticks for a tach .
  • ZootZoot Posts: 2,227
    edited 2010-02-03 17:34
    Somebody said...
    QEs don't necessarily yield higher resolution.

    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
  • ercoerco Posts: 20,244
    edited 2010-02-03 17:48
    @Zoot: Agreed. I'm the "somebody said"! What I failed to mention is that I was talking about motor encoders, which are usually QEs. It's easy to assume that accurate monitoring of motor encoders, which can give hundreds or even thousands of pulses per wheel revolution, is the best way to go. But in practice, it doesn't necessarily yield higher resolution at the wheels. Backlash (play) in the gears, transmissions, output shafts & wheel couplings add random errors that a motor encoder can't account for. I've been using simple tach encoders on the wheels with tight transmissions.

    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."
  • agfaagfa Posts: 295
    edited 2010-02-04 00:35
    Thanks Zoot.· That hadn't occurred to me.

    agfa
  • rpdbrpdb Posts: 101
    edited 2010-02-04 03:47
    Good point Zoot,
    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
  • rpdbrpdb Posts: 101
    edited 2010-02-04 06:18
    www.pc-control.co.uk/gray_code.htm gives a decent explination of the bit progression.
Sign In or Register to comment.