Shop OBEX P1 Docs P2 Docs Learn Events
Basic Stamp 2 Maximum Wheel Encoder Resolution — Parallax Forums

Basic Stamp 2 Maximum Wheel Encoder Resolution

Martin_HMartin_H Posts: 4,051
edited 2012-01-27 20:00 in Robotics
I plan to build a quick and easy robot using the Board of Education I was given. These Solarbotics wheels http://www.solarbotics.com/products/sw/ have encoder patterns molded into them which would be useful. But they have 64 stripes and the most I have used with a Stamp is 32 stripes. The BOEBOT wheels have an evening lower resolution, so I am wondering if 64 stripes would cause problems?

I figure that one revolution per second is top speed for any servo robot. A basic stamp 2 does 4000 instructions per second so in a 64th of a second is about 60 instructions would execute. Which is not bad since most PBASIC programs are only a few hundred lines long and most don't execute each iteration.

So it seems like the encoder resolution on the wheels should be OK. Any opinions?

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-25 20:40
    Don't forget that you have to generate servo pulses completely between encoder pulses if you don't want to miss any, Then there's all that other sensor stuff coming in.

    -Phil
  • Martin_HMartin_H Posts: 4,051
    edited 2012-01-26 04:46
    Don't forget that you have to generate servo pulses completely between encoder pulses if you don't want to miss any, Then there's all that other sensor stuff coming in.

    Good point. I picked up a servopal when they were on sale back in the fall. That way I can avoid repeating the pulses and the pause. I think that might give me some extra headroom?
  • ercoerco Posts: 20,256
    edited 2012-01-26 08:19
    What is really cool with this new design is the inclusion of a 64 strip pattern designed to match the popular "Wheel Watcher" optical encoders. Just paint in every other stripe pocket, and you're ready to go!

    You gotta be kidding me... PAINT your encoder stripes?

    1) lots of work
    2) poor accuracy, no two the same
    3) no control over reflectivity, your particular paint may or may not work. Won't know until it's too late.

    I'd stay clear of those unless you're feeling particularly adventurous. My encoder building experience says you need to exercise careful and complete control over every step, from creating & mounting perfect disks to tuning the optical sensor distance & electrical characteristics so you read 50% black and 50% white for maximum read speed.

    http://forums.parallax.com/showthread.php?121179-Reading-Quadrature-Encoders&p=899765&viewfull=1#post899765
  • Martin_HMartin_H Posts: 4,051
    edited 2012-01-26 09:25
    erco wrote: »
    You gotta be kidding me... PAINT your encoder stripes?

    1) lots of work
    2) poor accuracy, no two the same
    3) no control over reflectivity, your particular paint may or may not work. Won't know until it's too late.

    Well I was planning to use water thinned matte black acrylic so it would settle and fill in the pockets. After it dried it would leave paint in the pockets but not in the raised sections. Black matte acrylic is pretty non-reflective so the raised surface would reflect much more IR in comparison. To tune it 50% on versus off I was planning to use trim pots feeding into a Schmidt trigger. But who am I to argue with a man who smoked a Solarbotics motor for science!?

    Leaving aside the encoder stripes. Your test and Tracy Allen's calculations show that a BS2 doing nothing but reading pulses can count 327 pulses per second. That's far in excess of my 64 per second, so it seems like an encoder resolution significantly higher than the stock BOE Bot ones is pretty doable?
  • ercoerco Posts: 20,256
    edited 2012-01-26 09:31
    Sure, 'cuz I actually got 394 PPS. If you use a single sensor (technically a tach sensor instead of a quadrature encoder) per wheel, you cut your overhead in half, as long as you're certain which way your wheels are turning. But that may be problemmatic if you're using CR servos that "creep" in random in random directions around their "stopped" point (1.5 ms PW). That's where DC motors & speed controls can be superior.

    Using a Servopal reduces some overhead, but not completely. You need to be careful not to miss encoder pulses while you're sensing a Servopal command. Worst case, a Servopal command would be a pair of 1 millisecond pulses back to back, which may take 3 milliseconds with overhead. Now suddenly you're limited to reading 333 pulses per second MAX, divided by two wheels. Not looking at anything else. Resources get used up quickly. That's one reason I like my relay speed controls, the high/low commands to control them execute nearly instantly.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2012-01-26 10:39
    erco wrote: »
    You gotta be kidding me... PAINT your encoder stripes?

    1) lots of work
    2) poor accuracy, no two the same
    3) no control over reflectivity, your particular paint may or may not work. Won't know until it's too late.

    The way the WheelWatchers work there's likely more success to this method than one might suspect, though it still takes a good opaque paint. It probably wouldn't be more time consuming than building your own.

    The WheelWatcher uses an LSI chip that compensates for a lot of variations in encoder patterns. Because it uses quadrature encoding, and it cleans up and conditions the signals, you don't have the usual issues that plague single-channel and homebrew quad encoders. As long as there's a reasonable differentiation between white and black, you'll get clean output even if you do a pretty crappy paint job. Obviously you can't skip a stripe, but stripes can have a pretty wide latitude in thicknesses.

    That said, a stickon codewheel made of mylar and pre-printed with a compatible stripe pattern would be better. I imagine they didn't do it this way because it would have involved making a die and registration plate to accurately cut out the donut shaped disc.

    -- Gordon
  • ercoerco Posts: 20,256
    edited 2012-01-26 14:00
    IMHO, robot odometry using homebrew encoders is a rite of passage to manhood. Phil's S2 object does such a beautiful job of navigating using the motor encoders that it's transparent to the user. People who never tried to make a blue Scribbler go straight can't really appreciate what's going on.
  • Martin_HMartin_H Posts: 4,051
    edited 2012-01-26 14:57
    Well I've home brewed encoders before. I wasn't planning on using the wheel watchers, although I have to admit that the combination of wheel watchers with the wheel commander looks pretty compelling.
  • ercoerco Posts: 20,256
    edited 2012-01-26 15:22
    Martin_H wrote: »
    the wheel commander looks pretty compelling.

    But for $89 http://www.acroname.com/robotics/parts/R279-WC-132.html , you're letting them have all the fun!
  • Martin_HMartin_H Posts: 4,051
    edited 2012-01-27 18:23
    I was just reading the latest wheel watchers manual. They have always had decoding circuitry so you didn't have to process quadrature signals. But the latest version has a microcontroller with a serial mode which tracks wheel position and velocity. So your microcontroller doesn't need to track every pulse because the smart sensor does the work for it. Really nice one plus to their design.
  • ercoerco Posts: 20,256
    edited 2012-01-27 20:00
    Impressive and necessary, but I repeat, you're letting them have all the fun! :)

    Do all that from scratch with a Stamp or Prop and I'll be your biggest fan.
Sign In or Register to comment.