![]() |
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! |
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
|
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 |
Re: Optical Sensors Used as Encoders?
Quote:
anyway. yeah i get to have fun learning how intrupts work the day we get down to reagonals. what great fun |
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....... |
Re: Optical Sensors Used as Encoders?
Quote:
|
Re: Optical Sensors Used as Encoders?
Quote:
|
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 variablesCode:
void Process_Data_From_Local_IO(void)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. |
Re: Optical Sensors Used as Encoders?
Quote:
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 |
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. |
Re: Optical Sensors Used as Encoders?
Quote:
Thank you everyone for all of your help.... |
Re: Optical Sensors Used as Encoders?
Quote:
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. |
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.
|
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.
|
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
|
Re: Optical Sensors Used as Encoders?
Quote:
|
Re: Optical Sensors Used as Encoders?
Quote:
|
Re: Optical Sensors Used as Encoders?
Quote:
|
Re: Optical Sensors Used as Encoders?
Quote:
|
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. |
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 |
Re: Optical Sensors Used as Encoders?
Quote:
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 |
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