Homemade wheel encoder

Forum 2005-2010 (read only) General Exhibition
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 :smiley: 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):

2

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.

3

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

4

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

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

Like I said everything is relative..

5

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 :slight_smile:

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

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

6

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

7

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.

8

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

9

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 :confused: If anyone has a suggestion of what to use I'm open?

And the 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 :slight_smile:

10

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

11

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

12

Cool project!

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

13

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 :confused: 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!

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

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

15

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.

16

@MYX : I used to be the HP inkjet printer specialist in Australia... And I've done just what you suggested, but there are some problems.

Most inkjet printer carriage motors (the ones with the encoders) tend to be low-torque but relatively high speed brushed motors. We (they!) got away with that because the motor feedback loop was incredibly tightly monitored.

In the case of the Deskjet series, the carriage motors all have a pressed toothed wheel on the "business end", which is really difficult to remove without a gas torch and a press, but it can be done.

They also use an Agilent quadrature encoder, which on most of the models I knew about used a single channel, since the motor direction was managed separately by the MCU. But most are 256-step encoders, which could be very useful for many enthusiasts.

I still have a couple (4 or 5) motors, which anyone who's interested is welcome to. They're all 12V, include the encoder and the belt cog, and are all in excellent condition. I'll post a photo if anyone's interested.

17

Similar way to make a rotary encoder (as mentioned earlier in this topic)...

http://yo6pir.files.wordpress.com/2009/04/rotary-encoder.pdf

Keep on innovating!

Paul.

18

I have to make one regular post before I can open a new thread.
I do this regular post here. :smiley:
Sorry for any inconveniece caused.

Feel free to check my tilt compensated compass code...
arne

19

PC Pete,
I was suggesting the HP more for the encoder wheel on the massive end gear on the side of the printer. I forgot the one that was attached to the motor. The one I pulled (with encoder wheel) was not on the front. Kept intact it would be a nice piece because the encoder wheel is attached to the shaft that comes out the back end of the motor leaving front side haft open for whatever. It might make for difficult placement on a robot though. After looking back at the original post here, I realized that the actual encoder was a reflective style vs. the style in the printers which more or less sandwich the encoder wheel.

SoCentral2,
Ha! I did this years ago for a DIY arcade spinner for old school games (ghaw feels weird to call em' old).

And... em... Arne... Really?

20

Hi bought you wheel encoder set. can you help me about how and what the library should have.an easy program to test wheel encoder if works properly.

thank you