DIY encoders?
rwgast_logicdesign
Posts: 1,464
So im hoping some of you guys with more practical, hands on experince can give me some input to save.a few hours of testing and working out bugs when i try to build my wheel encoders.
I have a lot of IR stuff on hand, that i picked up specifically to make encoders, line following sensorss, edge detectors and beacons. I never acually had to make encoders until now though, as ive been lucky in the sense that most motors ive pirchased have them built in. As we all know the stingray does not come with encoders. The first thing im curious about is interupt vs reflective, I want to go with reflective becuase its much easier to make the discs, but is there a reason to use interupt over reflective when designing from scratch?
So my original plan was to use some vishay cny70 reflective sensors, the a basic photo transistor/ir emitter combo. Ive seen these used in some encoders with only a few resistors, on the other hand some say a comparator and schmitt trigure is needed. I also have very nice 15 degree LEDs with metal cans around them, or very wide angle 75 degree straw hat style leds. These are all 950nm LEDs and i have matching wavelength photo transistors and 38khz recivers. The IR recivers take care of cleaning up the signal edges along with being immune to ambient light correct? Which is the better choice here modulated 38khz ir, or just a plain photodiode set up? Ive also thought about using an ADC to help, maybe this would be an easier way to read sensors with slow rising/falling edge times? I know Erco and a lot of other like hamatsu reflective sensors or something like that, but im spent, nor could i find these sensors ANYWHERE when i spent all my alloted cash for this.
The second question is resalution for each channel. I was thinking 180 pulses per rev would be a good number that gives me 2.15mm of wheel travel per pulse. What is the practical upper limit of IR based systems, maybe I should move to, 240 ticks, or higher? Alot of motor encoders are in the 100 pulse per channel, per rev area, I suspect theres a reason. What is the practicality of super Hi Resalutions like 500-1000 pulses?
I have a lot of IR stuff on hand, that i picked up specifically to make encoders, line following sensorss, edge detectors and beacons. I never acually had to make encoders until now though, as ive been lucky in the sense that most motors ive pirchased have them built in. As we all know the stingray does not come with encoders. The first thing im curious about is interupt vs reflective, I want to go with reflective becuase its much easier to make the discs, but is there a reason to use interupt over reflective when designing from scratch?
So my original plan was to use some vishay cny70 reflective sensors, the a basic photo transistor/ir emitter combo. Ive seen these used in some encoders with only a few resistors, on the other hand some say a comparator and schmitt trigure is needed. I also have very nice 15 degree LEDs with metal cans around them, or very wide angle 75 degree straw hat style leds. These are all 950nm LEDs and i have matching wavelength photo transistors and 38khz recivers. The IR recivers take care of cleaning up the signal edges along with being immune to ambient light correct? Which is the better choice here modulated 38khz ir, or just a plain photodiode set up? Ive also thought about using an ADC to help, maybe this would be an easier way to read sensors with slow rising/falling edge times? I know Erco and a lot of other like hamatsu reflective sensors or something like that, but im spent, nor could i find these sensors ANYWHERE when i spent all my alloted cash for this.
The second question is resalution for each channel. I was thinking 180 pulses per rev would be a good number that gives me 2.15mm of wheel travel per pulse. What is the practical upper limit of IR based systems, maybe I should move to, 240 ticks, or higher? Alot of motor encoders are in the 100 pulse per channel, per rev area, I suspect theres a reason. What is the practicality of super Hi Resalutions like 500-1000 pulses?
Comments
Without modulation, you will need some sort of signal conditioning for sure. But that won't solve the problem of strong ambient light, or interference from fluorescent flicker. If you're using a Propeller, though, you could still modulate the IRED and use a sigma-delta input for the phototransistor, along with a counter and code to demodulate the incoming signal.
-Phil
That said, since the disc is separate from the wheel, a transmissive setup would be easier to deal with than a reflective one.
-Phil
Now let's build some robots.
Along the lines of Erco's suggestion, you might try building an encoder as a project in and of itself, rather than in the context of a larger robotics project. Use different encoder disk patterns with code to count the high low transitions and see if they match an expected input. I find these mini projects much easier than doing them in the context of a big project, and I learn a lot doing them. They can also keep up your motivation for bigger projects.
http://en.wikipedia.org/wiki/Analysis_paralysis
Sadly that wiki article describes my personality a lot, I wouldn't say thinking like this stops things from getting completed, but it sure makes them take a lot longer, ill try to work on that
Back to my mini project, a 4x40 LCD serial backpack to mount of this bad boy. I wish parallax would ship my stuff already!
Attaboy. BTW, I'm not trying to discourage you from doing researching and due diligence, but encouraging you to keep your hands busy. Building things, discovering what does & doesn't work in your situation and solving problems is very therapeautic.
It is a hall effect sensor (Melexis 90217) glued to a magnet,
Detecting nail heads instead of gear teeth...
Whatever you use for encoders, be sure to record your Stingray's first launching testings.
-Tommy
I will definately get some pics and video up as I build/test the stingray. I have alot of the basic hardware ready to go, and a plans for extra construction. like a scanning wii cam arm and a tower for the compass and radios etc. I definately have some holes to drill! Im just having a hard time figuring out how i want to mount my wiicams, there are so many ways to use them! Im thinking of making beacons that shoot ir at the celing and using the wii cam to do triangulation, kind of like navigation by the stars. I ordered my wireless stuff and servos from china, itll be a while before i see em, got to love holidays that last weeks!
Then bent up a more permanent bracket.
Marking the holes on the wheels was easy enough, using the GearGenerator site to make a template.
Getting the courage to drill the holes and install the nails into those pretty wheels was the hardest part.
There is plenty of room in the stingray for Wheel encoders, AND Motor encoders too.
You can just encode the heck out of your wheels and motors...
-Tommy
Encoders are definately a must for my area of indoor robotics exploration however I end up implementing them. I will post more details in a seperate thread as I would like feedback and maybe even a group effort project to start. I eventually intend to use lasers/sonars to plot a 2d map of a room in a standard text format. The measurements would be scaled to wheel encoder ticks. Then id like to use that data to generate a map in a standard open format maybe a doom wad or something. The next step is to then teach the robot to use the map for navigation along with its other sensors running to correct any mapping errors and update things, like the couch moved. The hole point is so when you tell your encoders to go to an x,y pos you can easily relate that to, under the kitchen table. The hardware needed would be 1-3 wiimote cams, lasers, encoders, beacons, compass, and sonar. The ultimate goal would be to have a 2d mapping algorithm and software sweet that would work on most hobby robot micros along with a PC. The whole system could be built for any bot realatively cheap compared to 1000 dollar laser scanners. Using a combo of ebay/samples/diy one could get all thos stuff well under 50 bucks, about 15 if you already had wiimotes to crack open.
I saw that BaneBot sells them for $6.50 each, so I stopped worrying, and started drilling.
Parallax sells the MLX 90217 for $4.95, I bought four of those,
and one 60 inch servo extention cable that I chopped up.
So for around $25 bucks, you can make four encoders for the price of one of those $25 Lynxmotion lick and sticks...
Which are great, but since the price is out of reach right now, So, I must consider them sour grapes for now..:)
I am sure I am missing something important about having two encoders per wheel, But all I can see the second
encoder doing, is telling me which direction the tire is spinning... I kinda already know that...
What else can you do with a second encoder? I am sure some one will set me straight on this..
-Tommy
- double the effective resolution of the encoder (an edge is triggered every "half" stripe or slot, not on every whole stripe or slot)
- tells you for sure the direction wheels are turning -- imagine you are applying a very small forward speed, and you are traveling up hill. The forward speed is not enough to move forward, in fact, the platform is slowly moving backwards (I have had this happen on a very heavy robot). If you rely on a "soft" direction (i.e., if you tell the motor to move forward, presume it is), you will have a hard time correcting -- your encoders will be registering a velocity, but in the wrong direction
- much simpler firmware (not as big a deal, but on memory/speed constrained controllers, this can be an issue)
As far as price 25 for two encoders is alot!!
Vishay CNY70 reflective sensors, .70 a pop, $2.80 for 4
Some Protoboard, maybe 50 cents worth
Optional Comparetor , a buck
Prop built in schmitt trigger, free
Encoder wheel on laser paper, also free
With wire that puts two quad encoders at just under $3.00
I really want to see this. Please document your build and results.
As I said this project is quite a Grand idea and Localization is something that even Academia struggles with, Im not pretending my sting ray will be rolling generating maps by the end of the week, ill be lucky to have this serial back pack done, due to some issues in the LCD screens library. But I do believe if there are enough of you out there that want this and were all willing to work together a basic system could be accomplished in maybe 6-months to a year. The very first steps I will be experimenting with is mapping inside a small empty area with boxes for walls, once I have the bot doing accurate scanning and receiving decent measurements, the next step will be to take those scan measurements and convert them to a nice graphical map. I have a lot of experience with game mapping software for shooters, ranging from the doom era all the way to quake 3/unreal tournament. So I thought it may be easier to take a set of tools from an old 2d shooter game like DOOM or Duke 3d (Both GPLed now) and then come up with a way to convert the laser/ping/sharp IR scan in to a map file compatible with one of those games. This way the user can see a pretty map on there PC and edit it themselves if they like. Next would then be to get the bot to map a whole room in sections, that correlate to the range finders length, then somehow glue them all together in one usable map of a room. This goes on and on in small steps, as I said I will post this idea later, as id really like any input on it that I can get. Before I post anything i want to finish this document,
http://ocw.mit.edu/courses/aeronautics-and-astronautics/16-412j-cognitive-robotics-spring-2005/projects/1aslam_blas_repo.pdf
This is called SLAM for dummies, or Simultaneous Localization and Mapping, its a fairly complex subject and requires a lot of math along with kalman filtering, but this MIT paper is one of the simplest introductions to the subject I can find, Its also using a laser range finder along with encoders, which is exactly the tools I have in mind, although there using a SICK scanner that costs thousands this techniques application will work with any range scanner down to a sharp IR sensor. Using a sharp/ping can work it just wont be as accurate and take a lot longer. There is also something else called WAVEFRONT I would like to investigate, along with an autonomous car class over at udaCity. But I believe if you throw modulated laser projection in the mix you can do great things with indoor tracking. For example
I have looked in to every possible option to get my robot to know where my dog is and track it.. well if the dog had a wireless connection/micro/and small camera/wiicam on its collar this may be possible. The collar would see the ceiling beacon, this would #1 tell us what room the dog is in, #2 give us all we need to triangulate the dogs x,y according to the beacons, then send this data to the bot, or server, where the bot could access it. The bot then loads it maps to find its way to the room the dog resides in and converts the dogs x,y on the Cartesian coordinates to encoder ticks.
I know this all sounds very Ambitious, and I also know there will be a lot of learning, it is all theoretical at the moment and will be done in small steps. It may sound like im trying to build a "Big Brain", "wink, wink, nudge, nudge", but I promise this is all based on things that have been tested and proven to work and is totally doable! One of the reasons I want to do more research is because im not sure how "doable" this is on a Propeller/bs2/Arduino. Im hoping a dedicated prop can handle all the math by itself, or at least doable with a prop and math co processor. Im afraid a PC may have to crunch the numbers or at the least a very fast ARM MCU. These MIT papers are all using an Evolution ER1 with laptop as there Brain.
Hey thanks for that Zoot!, I knew I must have been missing something important.
Double effective resolution is for sure very important.
Knowing what direction the wheels are turning was not so important to me, Until you mentioned the up hill, down hill thing.
Good point, especially since I wish to build a "Dune Crawler" at some point in time.
Simple firmware is a plus for myself, but if you have a few moments, could you elaborate a bit on that point?
I am still new here.
Thanks for your patience, I learn much here on these forums.
-Tommy
If you have quadrature, the decoding is pretty simple, and only takes a few instructions. While I wouldn't call it "complex", having to parse out what your user (or "sent") speed is and then deciding based on that if you should increment or decrement "ticks traveled" takes more instructions, plus if you change the way you track "user" motor speeds, you have to change your encoder code (e.g., I have some projects where I use a byte for user motor speed. Some projects use 128 = stop, 0 = reverse, 255 = forward. This means that bit 7 of the speed is the direction -- where 1 = foward. Now, say I change my mind and decide to use signed bytes, where 0 = stop, -127 = reverse, +127 = forward. Now the direction can still be parsed out from bit 7, but 1 = reverse. I'd have to go change single encoder code to reflect that -- otherwise my encoder ticks would now be counting down when they should count up and vice versa).
With quadrature, on each sample of the two encoder pins, you just need to compare the reading of the two pins with the last reading of the two pins to determine direction and count (e.g., to update a signed value that represents the change in "ticks" over time). With a single encoder, you still have to compare with the last reading (to see if there's been an edge change) but then you additionally have to pull the value of the last "sent" motor value to decide, in theory, which direction the tick represents.
Don't get me wrong, single encoders are perfectly great when quadrature doesn't have necessary advantages or because it's just not physically feasible to do quadrature. I just wanted to make the case that of course there are good reasons for quadrature, or it wouldn't be done so often
Once again, my thinking strayed far from the reality of the situation,
I figured that one thing was easier to count compared to two things to count, and I thought I had an advantage here, As I am pretty handy at counting to one...:)
Ok, thanks again Zoot, I am now off to build a second encoder for each side of my Stingray, and make it a Quadrature encoder system.
Say, Why do they call it Quadrature, when there are only two sensors on a wheel?
Never mind, I would just hurt myself trying to figure it out.
-Tommy
I based my four quadrature encoder object (available in the Rover 5 thread) on what I learned from Jon's article.
However, if space allows for actually positioning the sensors 90 degrees apart, then it's not hard. Just make sure that your encoder disk/wheel has an ODD number of PAIRS of stripes. In other words, the number of stripes or slots divided by 2 should be an ODD number.
Then if your sensors are 90 degrees apart, you are guaranteed to have 90 degrees phase on your two encoder signals. Perfboard can be nice for this, as it's 90 degrees already ...
For some of my projects, I drill a hole in the perfboard that fits the axle of the motor perfectly. I also drill what will be mounting holes for the board itself. I fit the board to the axle, mark where the mounting holes fall on the motor assembly/chassis, then drill those. At that point, I can cut off the part of the board that fits over the axle, knowing when I mount the board with the sensors on it, it will maintain concentricity with the axle. Mount the sensors at 90 degrees from each other and alignment is virtually guaranteed.
The attached show it better -- the first picture shows where the sensors will be laid out at 90 degrees, the mounting holes, and the axle. Then the steps through to finished encoders.
http://www.geology.smu.edu/dpa-www/robo/Encoder/pitt_html/encoders.html
There's also a really clever encoder pattern on that page that lets you put both sensors in a straight line (the phase is in the encoder disk, so alignment is not necessary).
Anyways I was thinking I would print off my encoder wheels and add them while constructing the bot, My mother is huge on crafts and things so we dug threw here stuff to find a suitable material to glue my encoder patterns to. In the process I found these....
She told me I could have them if they would work, but not to go ruining them if they wont. They are some kind of metal... One has 12 teeth the other 20, this would give me 720 steps per rev, or 1200 steps per rev, respectively. As I said I dont want to ruin them if they wont work, as they will need to be mounted some how. My first concern is the shape of the teeth, secondly is that there metal so im not sure a slot interrupt will read them right, would they need to be painted? I guess what im thinking by looking at the awkward shape of the teeth on either set up is that I wont have equal hi and low times.
If those wheels are ferrous, you might think about using a hall effect sensor -- you put a magnet on one side, the sensor on the other. As the ferrous tooth comes between the magnet and the sensor, the field fluctuates -- you can read this signal like most any other "encoder".