Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Technical Discussion (http://www.chiefdelphi.com/forums/forumdisplay.php?f=22)
-   -   Optical Sensors Used as Encoders? (http://www.chiefdelphi.com/forums/showthread.php?t=26243)

uvabrad825 29-02-2004 20:53

Optical Sensors Used as Encoders?
 
I'm sure on past robots teams have tried to use their optical sensors as an encoder by placing bits of reflective tape on a wheel/sprocket and counting the number of times a sensor mounted to read the pieces of tape was 'activated' (I'm not a programmer so I don't exactly know the correct terms).

Our team is considering pursuing this idea once we uncrate our robot at regionals, having the programs pre-written. We are planning on putting 8 evenly spaced pieces of reflective tape on the rims of our back wheels, and mounting two optical sensors to appropriately interact with the pieces.

I was wondering if any teams in the past have had success (or lack of) with this procedure, and if so, what the optimal setup(s) are (tape spacing, distance from sensor to wheel, etc..). Our programmers are very good at what they do, so I don't think that will be a problem. Any advice would be greatly appreciated!

jacob_dilles 29-02-2004 21:15

Re: Optical Sensors Used as Encoders?
 
we put 2 pieces of tape on the black couplings between the motor and the gear box, and we have one banner sensor on each side. lol we just need the code, because it works perfctly electricly... the light blink, the osiliscope has a beutifull trace. i was planing on using intrupts to count revolutions, and then every 10 program loops compare counts and adust PWMs accordingly. if you find any good code PLEASE post! thanks

Greg 29-02-2004 21:21

Re: Optical Sensors Used as Encoders?
 
I dont think this use of tape is allowed by the rules. Last year we used some white paint on a black gear. This year we drilled holes in the gear and put an aluminum plate behind the hole opposite the sensor. It works very well (and we took some weight off doing that :))

As for code... Wire the sensors to interrupts (digital pins 1 and 2). You can find some examples in the IR beacon tracker code. Last year I polled the sensors every program cycle and it did not work too well (not fast enough). The interrupt method works perfectly.

And dont forget to use the normally high output of the sensors

jacob_dilles 29-02-2004 21:24

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by Greg
I dont think this use of tape is allowed by the rules.

lets not over interpet the rules here... the "tape" in question is special 3m opto reflective tape that is not making any mechanical connections with anything else. therefore it can be said to be decrotive.

anyway. yeah i get to have fun learning how intrupts work the day we get down to reagonals. what great fun

Greg Needel 29-02-2004 21:25

Re: Optical Sensors Used as Encoders?
 
we are using this method on both wheel units and our lifter....

our sprockets have holes milled in them and the banner senor reads off the alluminum on our wheel units

and for our lifter we have electrical tape on the black connecter for the chip motor and that works fine....


if you need some code i can see what i can do about getting it.......

Joel J 29-02-2004 21:28

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by uvabrad825
I'm sure on past robots teams have tried to use their optical sensors as an encoder by placing bits of reflective tape on a wheel/sprocket and counting the number of times a sensor mounted to read the pieces of tape was 'activated' (I'm not a programmer so I don't exactly know the correct terms).

Our team is considering pursuing this idea once we uncrate our robot at regionals, having the programs pre-written. We are planning on putting 8 evenly spaced pieces of reflective tape on the rims of our back wheels, and mounting two optical sensors to appropriately interact with the pieces.

I was wondering if any teams in the past have had success (or lack of) with this procedure, and if so, what the optimal setup(s) are (tape spacing, distance from sensor to wheel, etc..). Our programmers are very good at what they do, so I don't think that will be a problem. Any advice would be greatly appreciated!

RAGE used optical sensors and retroreflective tape pieces for their autonomous last year and it worked well enough (watch video of 2003 UTC Regional and 2003 Newton Division Elims for a demo).. the optical sensors are very hard to deal with at times (they have random spats during which they don't work).. Good luck with them.

jacob_dilles 29-02-2004 21:28

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by Greg Needel
if you need some code i can see what i can do about getting it.......

any help would be greatly appreciated :ahh:

ErichKeane 29-02-2004 21:36

Re: Optical Sensors Used as Encoders?
 
Really, the code to this is not that hard. I would not use interrupts, only because getting them to interface correctly with the code can sometimes be a problem. Now, i forget whether the Banner sensors Run at full speed or not, but this is how i would code this segment. Note: If banner sensors do run correctly In FAST mode, place this code in the user_routines_fast.c, otherwise, just put it in your regular segment

Assumes banner sensors are wired as Normally Closed, and are wired to rc_dig_in01&02, and pwm01&pwm02 are the left and right wheels respectively. If you got questions, ask away.

FIRST: at the header (for variable data)
Code:

int leftcount=0,rightcount=0;//note, is signed to care for backward variables
unsigned char leftlast=0,rightlast=0,roundcount=0;//only cause we dont have a bool class

Second:(its kinda apparent)

Code:

void Process_Data_From_Local_IO(void)
{
        if(rc_dig_in01==1 &&leftlast==0)//left wheel counter
                if(pwm01>127)
                        leftcount++;
                else if(pwm01<127)
                        leftcount--;
        leftlast=rc_dig_in01;               


        if(rc_dig_in02==1 &&rightlast==0)//right wheel counter
                if(pwm02>127)
                        rightcount++;
                else if(pwm02<127)
                        rightcount--;
        rightlast=rc_dig_in02;

        if(roundcount>12)
        {
                if(leftcount>rightcount)
                        //whatever you want
                else if(rightcount<leftcount)
                        //whatever you want
                else
                        //take a guess?
               
                rightcount=leftcount=roundcount=0;
        }



        roundcount++;

}

Thats the quick, easy, and fun way to do it.



side note, i wrote this just right now, so if you find a problem with it, just post a correction below. Anyone may use this however they want, think of it as a mixture between the OpenSource in me and the Gracious Professionalism. As another side note, if anyone else needs coding help, i have become quite good at it, just send your questions my way.

bigqueue 29-02-2004 23:18

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by uvabrad825
I'm sure on past robots teams have tried to use their optical sensors as an encoder by placing bits of reflective tape on a wheel/sprocket and counting the number of times a sensor mounted to read the pieces of tape was 'activated' (I'm not a programmer so I don't exactly know the correct terms).

Our team is considering pursuing this idea once we uncrate our robot at regionals, having the programs pre-written. We are planning on putting 8 evenly spaced pieces of reflective tape on the rims of our back wheels, and mounting two optical sensors to appropriately interact with the pieces.

I was wondering if any teams in the past have had success (or lack of) with this procedure, and if so, what the optimal setup(s) are (tape spacing, distance from sensor to wheel, etc..). Our programmers are very good at what they do, so I don't think that will be a problem. Any advice would be greatly appreciated!


We did this exact thing last year and ot worked out pretty well. We split the coupling on our motor with tape. (half tape) and then made a quadrature encoder by using two optical Banners at 90 degrees from each other. THis way we knew of the wheel was spinning forward or reverse.

This worked out well, and given the ratio of this motor coupling to the output wheels, we had about a 3" resolution on out drive position.

It all worked out pretty well, but the thing that killed us was momentum when we stopped driving the motor. We had much overshoot at first, and much oscillation when we tried to impliment feedback.

Good luck,
-Quentin

Rickertsen2 29-02-2004 23:23

Re: Optical Sensors Used as Encoders?
 
Just me 2 cents, but if you are going to go through the trouble to do all this, then why not just use encoders or gear tooth counters?

If you use reflective tape and banner sensors, it will work, but i don;t see how you can possibly get much resolution.

uvabrad825 29-02-2004 23:38

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by Rickertsen2
Just me 2 cents, but if you are going to go through the trouble to do all this, then why not just use encoders or gear tooth counters?

Mostly because our team has a serious lack of $$$ and time, and since we have the banner sensors and can easily acquire some tape or white paint to put on our wheels, it's worth the try. And we're hoping that with enough 'markers' we can get it accurate enough for our purposes....

Thank you everyone for all of your help....

Random Dude 29-02-2004 23:42

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by Greg
I dont think this use of tape is allowed by the rules.

Q/A:

ID: 657
Q: I'm looking for clarification on the question about using reflective tape to count wheel revolutions. You said this was OK, but since the rules say electrical tape only, I'm wondering if other kinds of tape would be OK for this same use?
A: Other kinds of tape are okay for this use only.

Greg 01-03-2004 00:44

Re: Optical Sensors Used as Encoders?
 
Personally, I think unless the bot is very slow, the extra resolution wont matter. You still cant stop the bot :) theres just too much inertia. And we are not using the sensor on the actual wheel. We have it on a gear that is in a ratio of about 18:1 to the wheel. So that increases the resolution. And about the tape... The rules say "no adhesive-backed tape on the robot. The only exception is electrical tape, and it can only be used as as insulator". So a "decorative" explanation might not go over with the inspectors too well. White paint works very well, and is completely legal.

Al Skierkiewicz 01-03-2004 07:59

Re: Optical Sensors Used as Encoders?
 
We used Banner sensors last year for wheel encoders and have included them this year as well. We use a custom wheel so when the wheel was being assembled we just slipped a piece of dark papaer between the spokes of the wheel. By using two encoders (outlined above) you can tell direction and distance traveled. Last year we were able to get accurate down to at least an inch which made auto mode pretty easy. You need to couple the wheel sensors with a direction device to really know where you are.

KevinB 01-03-2004 16:41

Re: Optical Sensors Used as Encoders?
 
Last year we used banner sensors and tape marks, but this year we went ahead and spent a whopping $80 for shaft encoders (300 clicks per revolution ... as opposed to the 8 at best we had before). :D

Biff 01-03-2004 17:34

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by Rickertsen2
Just me 2 cents, but if you are going to go through the trouble to do all this, then why not just use encoders or gear tooth counters?

If you use reflective tape and banner sensors, it will work, but i don;t see how you can possibly get much resolution.

Not counting slop in the chains, I'm predicting .3 in resoulition We will be testing and codeing on a drive mock up built with some unused but gorgeous double bearing blocks and last years Cim motors. Hopefully we can make it all work in our "Drive system lab"

Biff 01-03-2004 17:36

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by Greg
Personally, I think unless the bot is very slow, the extra resolution wont matter. You still cant stop the bot :) theres just too much inertia. And we are not using the sensor on the actual wheel. We have it on a gear that is in a ratio of about 18:1 to the wheel. So that increases the resolution. And about the tape... The rules say "no adhesive-backed tape on the robot. The only exception is electrical tape, and it can only be used as as insulator". So a "decorative" explanation might not go over with the inspectors too well. White paint works very well, and is completely legal.

I read all the First Questions and answers last night and they said that reflective tape for pulse generation is legal. As long as they don't change their minds like they did with the yaw rate sensors life will be good.

jacob_dilles 01-03-2004 17:36

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by Rickertsen2
Just me 2 cents, but if you are going to go through the trouble to do all this, then why not just use encoders or gear tooth counters?

If you use reflective tape and banner sensors, it will work, but i don;t see how you can possibly get much resolution.

lol we dont need 1/4 degree resoluton. we need to know GENRALY how many times the wheels have turned...

ErichKeane 01-03-2004 21:44

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by jacob_dilles
lol we dont need 1/4 degree resoluton. we need to know GENRALY how many times the wheels have turned...

Well, it shouldnt be hard to figure out w/ the code example i posted. Let me know if it comes in handy

ECarlson 01-03-2004 23:47

Re: Optical Sensors Used as Encoders?
 
We tested the banner sensors to measure RPM's, and from what I saw it worked quite well, but our team decided to go with shaft encoders.

We also were going to use a potentiometer to measure the position of our arm, but also went with shaft encoders for that since the potentiometers from RadioShack were only responsive over about 180 degrees of their range, and we needed the full 270 degrees. We could have geared down the potentiometer, or gone with higher quality potentiometer, but we already had the shaft encoders.

eugenebrooks 02-03-2004 01:09

Re: Optical Sensors Used as Encoders?
 
We used the red light narrow beam optical sensors as wheel counters last year with good success, and tried this years "broad beam" IR banner sensors but found them to be less attractive. As a result, we used last year's sensors. It turns out that Banner QS18VN6LV, is not available
from an approved electronics source, while the same sensor with polarized light QS18VN6LP is available. I have posted a question to FIRST to learn if the "V" sensor will be considered equivalent for wheel counter use. Lacking that, we will buy and swap in the "legal" sensors in on the practice day of the competition. Hopefully, we won't have to waste the $122 and the half hour of time...

We used retro-reflective tape on the inside rim of the kit supplied wheel. Pieces of tape about 1/8 inch wide and half an inch long are pasted on the wheel rim at 5 degree intervals. We count transitions, giving us a 2.5 degree resolution. The sensor looks at the wheel through the kit frame tubing, through a slot about 1/8 inch wide, with the inside painted flat black. The sensor is set half way between the "no signal" point in the "-" adjustment direction and the the "+" limit which still produces a signal as the wheel is turned. You can find suitable tape in last years kit of parts, and at most hardware stores. Another source is 3M reflective tape used for boating safety, it has a pattern on it that is perfect for cutting strips about 1/8 inch wide by hand. Last year we put the relfective tape on the output
shaft of the drill motor, but did not get as much resolution as we got this year off the back side of the wheel. We checked with FIRST with regard to using retro-reflective tape to support wheel counters in the QandA and it is explicitly approved for this purpose.

The sensors are polled in the "fast loop" using the code below. Each time a light-dark, or dark-light, transition is seen the wheel counter for the corresponding wheel is incremented. The additional code tracks the minimum run length of ones or zeros, so that you can make sure that the RC computer is not missing any transitions when you turn up the speed. It also tracks any "glitches" that might confuse the counter code, if they happen. We found that maximum freewheel speed was easily accomodated with the drills set in low gear. About half maximum free wheel speed was accomodated in high gear. If you want to handle higher speed in high gear you need to sacrifice your measurement resolution and go with wider relfective strips spaced at larger intervals. It could be that there is no issue at all when the robot is driving itself on the carpet, as the wheels might not get going as fast as when running with the wheels off the ground. Your mileage will vary with your gear ratio.

Why such fine resoution, you might ask. You can measure a turn quite accurately with it, and you can dynamically correct motor power using feed back in order to track a very straight path if you feel the need to do this. It is also the case, with fine resolution, that you don't have to carefully set the wheels in the starting position.

The code in the fast loop follows, you have to put a call to it in the autonomous routine because it is not called in the default code. Calling it in the non-autonomous code is not that useful, unless you want to do clever things with the user controls.

Code Follows:

At the end of user_routines.h:
extern int left, oldleft, leftcounter;
extern long leftstringlength, minleftstringlength;
extern int right, oldright, rightcounter;
extern long rightstringlength, minrightstringlength;

In user_routines_fast.c:

Add the call:
Process_Data_From_Local_IO();
at the end of the while(autonomous_mode) loop so that
the wheel counters are updated while in the autonomous code.

Add, right above the Process_Data_From_Local_IO() definition:
int left, oldleft, leftcounter;
long leftstringlength, minleftstringlength;
int right, oldright, rightcounter;
long rightstringlength, minrightstringlength;

Here is the Process_Data_From_Local_IO() code:

void Process_Data_From_Local_IO(void) {
if((left = ((int)rc_dig_in10)) != oldleft) { /* Left counter is dig in 10 */
oldleft = left;
leftcounter += 1;
if(leftstringlength < minleftstringlength) {
minleftstringlength = leftstringlength;
}
leftstringlength = 1;
}
else {
leftstringlength += 1;
}

/* Repeat the code above for the "right wheel"
*/
}


Now, the minimum string length variable and the counter
values can be printed
out every time it gets smaller, running the wheels with the
joysticks, so that you can be sure that the counters are working
and not missing any transitions. Once you know all is well,
you can delete the tracking of the minimum string length. It is
taking time to execute, after all, and contributes to the possibility
of missing a transition.

The variables need to be suitably initialized, when the RC
comes on line. Do this in the user initialization routine,
after all of the RC controller IO hardware is set up.

#define MINSTRINGLENGTH 1000
oldleft = left = ((int)rc_dig_in10);
leftcounter = 0;
leftstringlength = 1;
minleftstringlength = MINSTRINGLENGTH;
/* Similar for the right wheel counter.
*/

We put this in just before the User_Proc_IS_Ready() call.

I'll leave the state machine code that uses the wheel counters,
packet counter for time, soft starts, soft stops, turns, and so forth,
to do your particular autonomous task as an excersise for the reader.
Any bugs/typos in the above are an excersise for the reader also,
I retyped it reading our code from the PC laptop and may not have
gotten it all, or gotten it all correct.

With good high resolution wheel counters, properly programmed,
you can "dead recon" to fractions of an inch on the floor and get
accurate repeatable turns.

Have Fun,
Eugene

Mark McLeod 02-03-2004 10:12

Re: Optical Sensors Used as Encoders?
 
Quote:

Originally Posted by eugenebrooks
...It turns out that Banner QS18VN6LV, is not available
from an approved electronics source, while the same sensor with polarized light QS18VN6LP is available.

Here's some good news...

Newark InOne Part No.:
21H6014
Manufacturer Part No.:
QS18VN6LV
Manufacturer Name:
Banner Engineering
Product Category:
Sensors
Part Description:
QS18VN6LV CABLE RETRO NPN
Cost:
$61

Zil709 03-05-2004 13:22

Re: Optical Sensors Used as Encoders?
 
Our team had a hole milled into the side plate of the gearbox such that we have a banner sensor on each gearbox. There's a single piece of retroreflective tape on one gear in each gearbox. The program (which I don't know that much about, sorry.) counts the number of times that the banner sensor views the tape. This works really well for autonomous and is really easy to adjust. Good luck!


All times are GMT -5. The time now is 05:59.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi