Pages: [1] 2 3   Go Down
Author Topic: Homemade wheel encoder  (Read 12330 times)
0 Members and 1 Guest are viewing this topic.
Buenos Aires
Offline Offline
Full Member
***
Karma: 0
Posts: 208
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley-grin 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):



« Last Edit: October 31, 2009, 10:06:19 pm by Aniss » Logged

ottawa, canada
Offline Offline
God Member
*****
Karma: 5
Posts: 989
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 331
Posts: 16548
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
« Last Edit: October 31, 2009, 08:38:00 pm by retrolefty » Logged

Buenos Aires
Offline Offline
Full Member
***
Karma: 0
Posts: 208
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley-wink

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

Like I said everything is relative..
Logged

Buenos Aires
Offline Offline
Full Member
***
Karma: 0
Posts: 208
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley

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

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

« Last Edit: October 31, 2009, 08:56:38 pm by Aniss » Logged

0
Offline Offline
Edison Member
*
Karma: 7
Posts: 1411
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Toronto, Canada
Offline Offline
Full Member
***
Karma: 0
Posts: 144
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged


Buenos Aires
Offline Offline
Full Member
***
Karma: 0
Posts: 208
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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..
« Last Edit: November 01, 2009, 07:23:25 pm by Aniss » Logged

Buenos Aires
Offline Offline
Full Member
***
Karma: 0
Posts: 208
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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:
#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 smiley
« Last Edit: November 02, 2009, 02:18:25 am by Aniss » Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 34
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 ...

Logged

0
Offline Offline
Jr. Member
**
Karma: 0
Posts: 61
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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...
Logged

B0100111001000011, USA
Offline Offline
Edison Member
*
Karma: 0
Posts: 1503
I'm confused.  Wait, maybe not..
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Cool project!

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

Melbourne, Australia
Offline Offline
Newbie
*
Karma: 0
Posts: 7
Fast. Cheap. Bug-free. Choose  two.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley) 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
« Last Edit: January 27, 2010, 11:30:58 pm by PCPete » Logged

Cardiff
Offline Offline
Newbie
*
Karma: 0
Posts: 45
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

0
Offline Offline
Jr. Member
**
Karma: 0
Posts: 73
Duinian Citizen
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Pages: [1] 2 3   Go Up
Jump to: