Go Down

Topic: Homemade wheel encoder (Read 17221 times) previous topic - next topic

Aniss1001

Nov 01, 2009, 02:16 am Last Edit: Nov 01, 2009, 04:06 am by Aniss Reason: 1
Basically I just printed out one of these (laser printer recommended):



...And attached it to a wheel.

Then I hooked up one of these (cheap IR sensor):



...And attached it to a motor pointing towards the wheel.

I've been testing it a bit with a few lines of Arduino code and damnit it works :D I'm now able to measure how much the wheel is rotating and therefore calculate how far a robot is moving. I just love it when these cheap lowtech solutions work.

Here are some photos (sorry about the bad quality):




bill2009

Quote
I'm now able to measure how much the wheel is rotating and therefore calculate how far a robot is moving. I just love it when these cheap lowtech solutions work.

cool.  I don't know if you're being ironic but a micro-controller using an infra-red sensor to read a laser-printed pattern attached to the wheel of a freaking ROBOT is not what I would have called low tech.

retrolefty

#2
Nov 01, 2009, 02:36 am Last Edit: Nov 01, 2009, 02:38 am by retrolefty Reason: 1
If you add a second detector you can make it into a quadrature encoder and would be able to work in both forwards and reverse directions without losing track. You just have to align the two sensors such that one is in the middle of a segment the other is just at the transition between two segments.

Lefty

Aniss1001

Quote
I don't know if you're being ironic but a micro-controller using an infra-red sensor to read a laser-printed pattern attached to the wheel of a freaking ROBOT is not what I would have called low tech.

Hehe...actually I wasn't being ironic at all, but I see your point..

However everthing is relative and I was comparing it to other more advanced, expensive ways of measuring distance traveled, like a GPS or an accelerometer.

This IR sensor (QRB1134) is very basic and costs like 2$. I wouldn't exactly call it hightech unless I compare to a spoon ;)

And the encoder itself is a piece of paper with a simple pattern printed on it.

Like I said everything is relative..

Aniss1001

#4
Nov 01, 2009, 02:56 am Last Edit: Nov 01, 2009, 02:56 am by Aniss Reason: 1
Quote
If you add a second detector you can make it into a quadrature encoder...

Yes I heard/read about that. However I don't quite see the point of it in my application since I always know the direction of the motor: I'm controlling it :)

But perhaps you mean that it would minimize the accumulated error in the application?

Anyway thanks for the input. Allways more than welcome...


florinc

Nifty.
Isn't this how a 2-wheeled (mechanical) mouse works?

Ro-Bot-X

Quote
Nifty.
Isn't this how a 2-wheeled (mechanical) mouse works?


Yes. The old ball mouse had 2 optical quadrature encoders inside.

The quadrature encoder lets you have 4 times more clicks than the number of stripes on the wheel. So, if you have 6 black stripes, a simple encoder can read 6 low to high transitions or, if it also counts the high to low transitions, it reads 12 clicks per wheel rotation. A quadrature encoder can read 6x4 clicks per wheel rotation. This improves the resolution.

The problems measuring traveled distance with encoders are:
- the wheel may slip when it is starting/stopping or if it is blocked by an object and so on...
- the fact that you need to multiply the wheel diameter with PI, that is an unending floating point number...
- encoder resolution, best is to calculate it to have a (traveled) millimeter per click or even higher resolution, try to avoid another floating point number if possible.

If you succeed to have a (relatively) fixed number of millimeters per click then you make your calculations easier and improve on your errors.

Anyway, I consider that for a robot, en encoder is mandatory. There is no way anyone can expect the absolute precision by using any means in determining the robot's position. All sensors have errors. You will have to use several ways to determine the position and correct for errors.

Aniss1001

#7
Nov 02, 2009, 01:16 am Last Edit: Nov 02, 2009, 01:23 am by Aniss Reason: 1
Ro-Bot-X:

Thanks for the info. I'll keep it in mind when I start playing around with the robot and the calculations.

Ro-Bot-X + florinc:

BTW newer optical mouses (mice?) also has a (quadrature?) encoder inside for the scroll button. I recently salvaged one. Havent used it yet though..

Aniss1001

#8
Nov 02, 2009, 01:20 am Last Edit: Nov 02, 2009, 08:18 am by Aniss Reason: 1
Ah just thought I'd post the test code and the schematic I used to hook up the QRB1134 sensor:



I used a 0.1uF ceramic cap. Don't know if that's what was intended? It does have a + indicating a polarized cap, but I dunno? Man I wish people would write the kind of cap you're supposed to use, but apparently that's obvious to everyone but me :/ If anyone has a suggestion of what to use I'm open?

And the code:

Code: [Select]
#define IOP 14
#define PWM 3

int val_new;
int val_old;
int clicks = 0;
int turns = 0;

void setup() {
     Serial.begin(115200);
     pinMode(IOP, INPUT);

     val_new = digitalRead(IOP);
     val_old = val_new;
}

void loop() {
     analogWrite(PWM, 80);

     val_new = digitalRead(IOP);
     
     if(val_new != val_old) {
           if(clicks == 40) {
                 clicks = 1;
                 turns++;

                 Serial.print("TURNS: ");
                 Serial.println(turns);  
           }
           else clicks++;
           
           Serial.print("CLICKS: ");
           Serial.println(clicks);

           val_old = val_new;
     }
}


Basically I just add 1 to the variable clicks every time the color in front of the sensor changes. When I reach 40 clicks I reset the variable clicks and add 1 to the variable turns. And off course I'm logging everything through serial for testing. That's it :)

roony

Excellent post, thnx for that

"If you add a second detector you can make it into a quadrature encoder and would be able to work in both forwards and reverse directions without losing track. You just have to align the two sensors such that one is in the middle of a segment the other is just at the transition between two segments. Lefty"


I was wondering if anyone had some code to add a second detector? i need to track both forwards & reverse directions ...


cr0sh2

Quote
Yes I heard/read about that. However I don't quite see the point of it in my application since I always know the direction of the motor: I'm controlling it


The point of an encoder, and especially a quadrature encoder, on a robot is not just to allow the controller (microcontroller, computer, whatever) to know the distance, speed, and (in the case of a quad encoder) the direction the motor is turning; it is to let the controller know if the motor (or wheel, actually) is turning when the motor isn't running!

Say you have a motor connected to a wheel, and your robot is going uphill. You turn the motor off, but the weight of the robot causes it to roll backwards. If you had an encoder attached to the wheel (and the encoders output tied to an interrupt), your controller could deal with the fact that the robot is moving backwards (by applying power, or a brake, or something).

You could also do things like put encoders on the wheels of say a vehicle with a differential (like a regular car), as well as an encoder on the motor output attached to the differential. With this kind of arrangement, you could measure slippage of the differential, and if you had a way of locking the diff electronically, you could do this as well (as needed). This is a simple method of traction control.

Another form of traction control (something I have thought about trying), is setting up the robot vehicle so that all four wheels have motors on them. If you set things up so that both the front and rear of your "car" use an Ackerman steering linkage (but not actually attached to a steering mechanism - just a simple linkage between the pivot arms), you could vary the speed of the motors driving the wheels to effect an electronically controlled steering system; encoders placed on the wheels (as well as angle sensors on the pivots) would help to both let the controller (controllers, likely) know that the commanded direction is the direction being driven in, as well as to help with four-wheel traction control.

Scale it up with hub-mounted motors (although there might be too much unsprung weight; might be better to place the motors on the chassis and lead out to the wheels with CV joints), and you could build an interesting mobile AWD and steering platform...

TchnclFl

Cool project!

Where'd you get that IR unit for that cheap?

PC Pete

#12
Jan 28, 2010, 05:26 am Last Edit: Jan 28, 2010, 05:30 am by PCPete Reason: 1
Quote
I used a 0.1uF ceramic cap. Don't know if that's what was intended? It does have a + indicating a polarized cap, but I dunno? Man I wish people would write the kind of cap you're supposed to use, but apparently that's obvious to everyone but me :/ If anyone has a suggestion of what to use I'm open?

It sounds like you've used a small tantalum cap. The small value tants look a lot like a mono (ceramic) bypass cap, except they're usually "rounder", more like a droplet of snot than the typical monos.  ;D

As long as the + goes to the most positive voltage, you're pretty safe. Otherwise you get a SED (smoke emitting device), and if you're really unlucky, maybe even an FED (fire emitting device). Either way, when the smoke's out, it's not a cap anymore, it's a kind of resistor. :-/

Since the electronics you're using aren't all that complicated, you can get away with (and it sounds like you did get away with :)) either a mono cap or a small electrolytic/tantalum.

The easiest way to remember the difference (and where to use them) is: use monos where mild spikes or a little noise might interfere with a sensor/IC, and use tants or electros where there's a LOT of noise/major spikes, or where more than about 10mA is being drawn by a sensor/IC.

A good rule of thumb is to use one mono cap per IC package (or sensor), and one electro/tant per 4-5 ICs.

There's usually no such thing as too many caps, unless you have layout problems or a ground loop or really, really long wiring runs - in which case you get a free (usually undesired) oscillator if the caps are a bit "much" for the traces.
HTH!

Quote

Where'd you get that IR unit for that cheap?

I found the Junun Robotics store has the same sensors for US$1.50 a pop, and extremely reasonable shipping rates. HTH 2!
-PCPete

Emyr

Quote
- the fact that you need to multiply the wheel diameter with PI, that is an unending floating point number...


Given that you know the wheel size and encoder count in advance, you can express distance travelled as some number multiplied by a constant.

If you express your distances in encoder clicks instead of human measurements you can reduce the number of flops required.

MYX

Quote
This IR sensor (QRB1134) is very basic and costs like 2$

Hey for $2 you could go to a garage sale buy an old (actually somewhat new) inkjet printer. You then would get a hand full of the things. On many printers, they are actually pre wired for you as well. All you need to do is attach them to headers, or just strip em and solder em. Plus of you are doing the robot thing, there is a vast array of stuff like some really nice little stepper motors to perhaps drive your robot, there are also gears, good solid metal plating, springs, some heavy duty steel rods, not to mention a bunch of nice scroungable components on the circuit boards (really nice smd tantalums, diodes, inductors, and resistors)

BTW, If you can find an old Epson, they have some of the nicest steppers I have seen in any printer.

Actually, many HP Printers actually have these really cool clear plastic encoder wheels that are way finer than any of us could print.

Go Up