Scribbler Wheel Encoder Project
Whit & I are so taken with our beloved little Scribblers that we're embarking on a project to add wheel encoders.·We plan to hook up two Hamamatsu P5587 sensors·(http://www.junun.org/MarkIII/Info.jsp?item=48) to the user port, which will replace two of the photocells. Obviously this is headed towards odometry and navigation. But·baby steps: first part will be just making·a Scribbler drive straight and measure distance travelled. Hopefully this will not be too disillusioning and later we'll add more capability.
First choice is to not add any more processing power (ie, another Stamp just to watch the encoders). It will be a big challenge to use the Scribbler's relatively slow BS2 chip to monitor both encoders AND adjust motor speeds on the fly. This is asking a lot of a single-thread processor, and the little BS2 will essentially be juggling and spinning plates while tap dancing.
The Scribbler's motor drivers are of the single-pulsout "set and forget" type, and don't require the continuous pulse/pause sequence that BoE-Bot's servos do, so that is one advantage. But sending one PULSOUT 13,2000 (motor stop) still takes 4 ms. PULSOUT 13,3000 is full forward, and takes 6 ms;·3 times as long to send as the 2-ms reverse command: PULSOUT 13,1000. So I'm sure we'll end up either driving in reverse or reversing the motor wires to drive forward while using the faster-sent reverse commands.
There will be a maximum limit on how fast the encoder pulses can be read while adjusting the motor speed.·This will affect the top speed of the robot as well as the encoder resolution (pulses per revolution).·I anticipate leaving one wheel running·at a fixed medium speed and only adjust the other motor to speed up or slow down to stay in sync. That eliminates control time lost·for the fixed-speed motor.
2 photos attached of the paper encoder disks I've put on my Scribbler already.·Prelim tests show that the sensor reads them reliably from·up to·0.25 inch away even in room light, but my plan is to have them as close to the disk as possible, probably underneath to minimize external light effects. Sensor hookup per http://www.acroname.com/robotics/parts/R64-P5587.html·and encoder disk is from http://mitros.org/p/projects/encoder. I used just the two center disks on that pattern, they fit perfectly inside the Scribbler's wheels after cutting out a 1" center hole for the hub. I'll only use one of the two rings (TBD)·for the encoder, but the second ring diameter was useful for properly centering the·encoder disk on the wheel.
We're just·starting up this project and I'm throwing·it out·here to·see if there's interest and also to ask what·Forumites think and what they may have already done. I've swapped PMs previously with odometry guru PhiPi and seen his incredibly detailed BoE-Bot article. And I'm sure Mike Green has insight & experience that will help. Any & all comments from this wise·group appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
First choice is to not add any more processing power (ie, another Stamp just to watch the encoders). It will be a big challenge to use the Scribbler's relatively slow BS2 chip to monitor both encoders AND adjust motor speeds on the fly. This is asking a lot of a single-thread processor, and the little BS2 will essentially be juggling and spinning plates while tap dancing.
The Scribbler's motor drivers are of the single-pulsout "set and forget" type, and don't require the continuous pulse/pause sequence that BoE-Bot's servos do, so that is one advantage. But sending one PULSOUT 13,2000 (motor stop) still takes 4 ms. PULSOUT 13,3000 is full forward, and takes 6 ms;·3 times as long to send as the 2-ms reverse command: PULSOUT 13,1000. So I'm sure we'll end up either driving in reverse or reversing the motor wires to drive forward while using the faster-sent reverse commands.
There will be a maximum limit on how fast the encoder pulses can be read while adjusting the motor speed.·This will affect the top speed of the robot as well as the encoder resolution (pulses per revolution).·I anticipate leaving one wheel running·at a fixed medium speed and only adjust the other motor to speed up or slow down to stay in sync. That eliminates control time lost·for the fixed-speed motor.
2 photos attached of the paper encoder disks I've put on my Scribbler already.·Prelim tests show that the sensor reads them reliably from·up to·0.25 inch away even in room light, but my plan is to have them as close to the disk as possible, probably underneath to minimize external light effects. Sensor hookup per http://www.acroname.com/robotics/parts/R64-P5587.html·and encoder disk is from http://mitros.org/p/projects/encoder. I used just the two center disks on that pattern, they fit perfectly inside the Scribbler's wheels after cutting out a 1" center hole for the hub. I'll only use one of the two rings (TBD)·for the encoder, but the second ring diameter was useful for properly centering the·encoder disk on the wheel.
We're just·starting up this project and I'm throwing·it out·here to·see if there's interest and also to ask what·Forumites think and what they may have already done. I've swapped PMs previously with odometry guru PhiPi and seen his incredibly detailed BoE-Bot article. And I'm sure Mike Green has insight & experience that will help. Any & all comments from this wise·group appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Comments
This looks like a good project for the Scribbler! The internal motor controller will provide you plenty of processing relief for wheel odometry, so long as you don't get too ambitious with the number of pulses per revolution. If you try to use the encoders for coordinated motion, though, the motor controller will more likely be in the way, since it doesn't give you the same fine control afforded by sending (or omitting) individual pulses to a servo. But this is okay, since grosser course corrections, in lieu of coordinated turns, can still get you to a target position.
-Phil
Thanks for the encouragement Phil! erco and I have been reading your encoder article. For those of you who have never seen it, you can find it here - www.parallax.com/dl/docs/prod/datast/ApplyEncoder.pdf As erco said, it is very detailed.
Phil, you warned about not geting too ambitious with the number of pulses per revolution. For the BOEBot (and in the article mentioned above), you were using 16 pulses. Is that a good place to start? erco's disks are at 24 on the outside, is that too many? I made some disks awhile back at 64 (something I found on the web). I would assume that is way too many. To be honest, I kinda got dizzy looking at them.
I would sure like to achieve the goal of starting in a Scribbler size square (tape on the floor)·- heading out on a small circuit and being able to return to the square (or pretty close).
I also remembered (it is from a year ago!) this thread and found it with a Parallax Google·search -
http://forums.parallax.com/showthread.php?p=696656
A bit of a different approach...
Hey erco and Phil, I just had another idea. Could a properly placed Vibra Tab sensor - (see http://www.parallax.com/Store/Sensors/PressureFlexRPM/tabid/177/CategoryID/52/List/0/Level/a/ProductID/89/Default.aspx?SortField=ProductName%2cProductName) count the wheel turns kinda like the old playing cards in the bicycle spokes trick? It might also make an interest sound! I may give this idea a test. Just thinking out of the box...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Whit) : 12/30/2008 12:36:00 AM GMT
PhiPi: Thanks for your encouraging words. As you've seen, I've come full-circle, from a differential drive scoffer to a PID wannabe! Your superb article (that Whit referenced) and another at http://www.seattlerobotics.org/encoder/200108/using_a_pid.html has released my inner geek.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
I agree. I am not sure the Vibra Tab application is better. I thought it might suit the Scribbler unique wheel configuration (that is the uniform in and out of the wheel's "spokes"). If it worked, it would also work·in any lighting condition.
I imagine, the Hamamatsu P5587 sensors will be a better bet. The encoder disks also fit very well into the recess in the Scribbler's Wheels.
What do you think about the number of pulses issue that Phil addressed?
This seems reasonable to me. We have to find the balace between how many pulses we can count (per Phil's comment) and counting enough to make this as accurate as possible. With an infinite number of pulses and corrections you could go in very straight line. The fun part will be seeing how close we can really come with the constraints we have.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
At any rate, more gear reduction is moving in the right direction. I disassembled·one gearmotor and calculated a gear ratio of 126.9:1 which is probably what Vigor/Solarbotics/Pololu call their 143:1 for some strange reason (running change?). See the GM8 motor at http://www.pololu.com/docs/0J10·. I plan to use their GM2 gearmotor, which·is the same size but has an advertised·224:1 gear ratio. I can't wait to see what it really is. I have some at work, so I'll have to stop by during the break and grab two for testing. I'm hoping they'll swap out pretty easily, and that's as good a time as any to reverse the motor wires so the Scribbler goes forward using the quicker-executing original reverse commands.
Meanwhile, my·attention·is divided.·I just got my BS2-based WasteBot running around last night and that's·very fun·to chase the dog with. I'll have to post a Youtube vid soon.
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
I will run the test program on mine and make a video of it. May be tomorrow though.
Can't wait to see the waste can bot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
My Scribbler confirms your results (but in a slightly different way).
See test video here - http://www.youtube.com/watch?v=hDFWkKyB2l4
Mine seemed to run straightest at low speeds (both forward and reverse). Because the results vary through the speed range, the corrections that can·be made with the Scribbler Program maker calibration routine might help one speed but not another (incidently, I reloaded the original Scribbler software first, so that I new we had no corrections from the calibration routine). This is (of course) why we need the encoders!
Happy New Year!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Whit) : 1/1/2009 5:19:15 PM GMT
But this is only side A. Side B deals with turns, and you have to calibrate for those, too. Theoretically, one could measure the wheel separation and compute the calibration constants. It's much more accurate, though, to spin the bot, first on one wheel, then on the other, for a certain number of encoder pulses and keep track of what one of the light sensors sees as it rotates. By downloading this info to a PC program, an autocorrelation can be performed on the light sensor data to come up with a precise period, i.e. how many (fractional) encoder pulses there are per complete rotation. Even this will be subject to error, due to wheel wobble and rolling surface variabilities; but it's a close as you'll get without an additional directional reference, such as a compass.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Here is a test video of using the Vibra Tab sensor to count the spokes of the Scribbler Wheel. I don't know how well it would really work, but at least it shows that the basic idea will work. The video is pretty dark, but I think you can see the main points.
The Scribbler is running your motor test routine.
Check it out - http://www.youtube.com/watch?v=CjD3FMH84ws
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Just took a look at the Vibratab encoder video. This is an interesting idea. It would be great to write a little x = x + 1 program that increments a variable by one every time the tab is hit, and to remove any pauses from the sample program. I'm not sure about the vibra tab's time to settle between spoke hits, but it appears that you're counting every time even with the DEBUG statement in your program. Some of the most interesting finds come from these simple little demonstrations, don't they?
In the case of the Scribbler, low-resolution encoders may be AOK. Just the ability to drive straight, even if corrected every 1/8th of a rotation, would be a tremendous improvement.
Good job, erco and Whit+
Ken
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Thanks for the kind words. erco and I started on this based on our love for the Scribbler and his idea to develop a good encoder system that fit the simple and fun concept of the bot. The Vibra Tab idea just came to me as I studied the wheel shape. I will see if it can be developed.
erco,
No rush here! I have had a bit more than usual time to play between Christmas and New Year's. I won't be able to keep up the pace myself because the real world returns on Monday. Get to feeling better! And keep me posted!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
It can easily read the wheel at full speed with the stock gearmotors; I haven't yet put the higher-reduction gearmotors on yet, but I still plan to. My first program flickered an LED in sync with encoder reading and DEBUGed the encoder status with "0000111100001111" strings. I'm sure you know that DEBUG commands are very slow to execute, but at full motor speed I was still getting 4 or 5 zeroes & ones in a row. That's encouraging, it tells me that we will be able to use the Scribbler's built-in BS2 instead of adding another processor. It will still take some tricky software coding to monitor both wheels and control motor speeds, but that's the fun part.
Long story short, my confidence level is pretty high at this early stage. This flubug is slowing me down a bit, but this bit of encouragement will keep me rolling on this when I can. I'll get some photos posted perhaps tomorrow morning.
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
To make something work one must build, test, and verify bfore proceding.· -- myself
http://www.parallax.com/Store/Accessories/MotorServoControllers/tabid/160/CategoryID/35/List/0/Level/a/ProductID/481/Default.aspx?SortField=ProductName%2CProductName
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
To make something work one must build, test, and verify bfore proceding.· -- myself
I aligned the sensor to read·the outer ring of the encoder wheel (link also in my first post), and mounted it horizontally from axle in the top body shell. Each encoder circuit has 3 wired connections: +5V, ground, and output. I disconnected photocells to use the encoders. Photocells are also mounted in the top body shell on a small green PC board under a black plastic light shield. No need to remove anything. Just unsolder green wire from P4 on the circuit board to disconnect·all 3 photocells. The green wire becomes the ground connection for both encoders. Connect left encoder output to pad P3 and right encoder output to pad P1 on green photocell PC board. Stamp-wise, the left encoder will be IN2 and the right encoder IN0. +5V connection from 6-hole Hacker port header on main PC board.
Also attached is a screenshot of a program and its resulting DEBUG output to show how fast the encoder sample rate is. With the motors at full speed on new alkaline batteries, a·tight for/next·loop can sample each black or white encoder square well over 20 times. That should be sufficiently fast to·achieve some modest odometry goals.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Jax
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If a robot has a screw then it must be romoved and hacked into..
Post Edited (GWJax) : 1/3/2009 5:49:25 PM GMT
Fantastic job. This is very exciting! I love the way you mounted the sensors. Extremely neat and out of harm's way. It is also encouraging that your readings are working so well.
I did a little more computing on the vibra tab system...
The Scribbler's wheel has 8 spokes on each side, actually 8 high spots and 8 low spots. That is 16 positions for one turn of the wheel. The wheels are 3-1/8" in diameter (approximately). The circumferece is 9.82" or 9-13/16". For each 16th a turn, the wheel has travelled 0.614" or 5/8".
I think with the encoder wheels (depending on how many black/whites you had) divided into 18 segments (a bit of a strange number) you could travel a 1/2" per segment (that is, 9-13/16" / 18 = 1/2" - or 1/4" for 36 segments). The simpler numbers per count might make more sense intuitively.
I know this doesn't really matter as much for keeping the wheels in sync for straight running, but it would be nice for distance measuring. I mean a simpler number like 1/2" per count rather than something odd like·5/8" (not that it really matters).
I found the attached program the other day (from here - http://www.societyofrobots.com/sensors_encoder.shtml)·It is an encoder wheel design program and it is pretty neat...
Jax - great to hear from you! (Don't you think my test video's have a G.W. Jax sort of narration quality?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Whit) : 1/3/2009 7:17:04 PM GMT
Jax, those are dedicated IR encoder sensors by Hamamatsu, not photocells. Tiny & cheap ($2), they have internal signal conditioning circuitry with filters & Schmidt triggers. Check the link in my first post. This is my first time using them, and I'm sold! I appreciate your upbeat comment on my compact code. I cringe when I think what modern "PBasic Style" purists must think of my old school code. I learned on the BS1 with DOS and I still like for/next loops and simple undeclared B0 variables!
Whit: Of course you can use any resolution on the encoders. I'm going for the highest resolution I can, especially since I still plan to use high-reduction gearmotors. I wouldn't choose to sacrifice resolution to simplify encoder ticks/inch, though. Even if it's an odd or fractional number of ticks per foot, it will still require experimentation to verify distance & position. And in my ultimate software vision, I'll never hard-code those numbers through keystrokes anyway. I'll just drive the Scribbler using an IR remote and it will WRITE the route in EEPROM, to READ back later as it drives the route on its own. In that case, resolution is everything. I may end up going to higher resolution if the BS2 can keep up.
But simple goals first, let's just see if this sucker can drive relatively straight!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
I may continue work for a while on the Vibra Tab idea as a simple experiment that Scribbler users can try to get a taste for encoding. Best case would be to achieve this with as little Scribbler hardware modification as possible.
This is a fun project all the way around!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
My question is, whould it work as effectively to paint the face of each of the teeth white and use the contrast between the tooth and the black wheel to generate the encoding pulses? It would also seem that you could get a higher resolution by using the 24 teeth to trigger the vibratab sensor rather than the 8 curved "spokes" of the wheel.
Also, with the encoder disks that you have, wouldn't measuring and comparing·the pulse width generated by each encoder give you a more immediate indication of how out of sync the wheels are?
I can't wait to see where you guys take this next, thanks,
Duffer
What is interesting in the video is to watch the 3 green user LEDs as the robot drives in a straight line. They display which wheel is playing "catch up", or if they're even, the center LED is on. You can see the course corrections against the floor grid pattern.
Photo attached shows two encoders tucked into upper body. Those Hamamatsu sensors work great. All in all, a rewarding outcome for a couple days of building!
Duffer: Thanks for your interest. Per your question, it may work to paint the 24 "teeth" on the wheel, it all depends on the relative reflectance of the light/dark spots. I found the encoder disk quick and simple to use, I just printed it on paper and mounted with carpet tape.
Whit can answer your Vibratab question.
Measuring pulse width is another valid way to pull data out of the encoders, but the Stamp can only do one thing at a time. You have to try to monitor both wheels "simultaneously" or as quickly as possible. My tests indicated that in the entire duration of a light or dark pulse, I can sample one or both encoders over 20 times. So, I wouldn't use PULSIN, which would cause unnecessary waiting on a single wheel, but you could have·two interwoven timing loops to monitor the wheels'·timing·as you sample them. Try it and see!
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."
Jax
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If a robot has a screw then it must be romoved and hacked into..
That works great! The proof is in the video. With improved code and perhaps greater divisions on the encoder wheels - you will certainly have something better than I thought possible. (matter of fact - as is - it is pretty impressive!) The floor pattern makes it so easy to see how the little bot is doing. The LED feed-back is also very nice.
The existing motors work very well. Are you still think of trying the others?
Do you care if I post your video on my blog. I have been posting about the project there.
Duffer,
I will try the Vibra Tabs on the teeth. The teeth on the wheel are offset and help hold a rubber "o" ring that serves as a tire. It is great idea to use them. I will see how it works and report back.
Mikerocontroller,
Who needs encoders if you can train a monkey to drive your Scribbler!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Whit) : 1/4/2009 3:56:12 AM GMT
Plse I cant wait to see your results with the vibratab, Yo to can compete to see whos scribler is better.
Jax
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If a robot has a screw then it must be romoved and hacked into..
Nicely done!
-Phil
erco
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."