View Full Version : encoder for cam-driven kicker?
As part of a feasibility study, our team has just prototyped a cam-driven kicker.
A motor-driven cam pushes a cam follower at the end of a lever arm which forces the kicking arm back, stretching the latex tubing. When the cam reaches its largest radius, we want to motor to stop. Then to fire, the motor continues rotating in the same direction, and the cam-follower falls off the edge of the cam (down to the lowest cam radius, that is), allowing the kicking arm to kick, and the cycle repeats.
I'm seeking suggestions as to what type of sensor to use. I'm thinking an absolute encoder would be what I need, but the one in the kit of parts is a relative encoder (as far as I can tell). Is there a way to make that work for this application?
~
What about the magnetic encoder that was supplied in the kit? It measures a full rotation and, since it needs no contact, that's one less thing dragging down your mechanism when it is unwinding.
pfreivald
15-03-2010, 23:10
What about the magnetic encoder that was supplied in the kit? It measures a full rotation and, since it needs no contact, that's one less thing dragging down your mechanism when it is unwinding.
What about a simple limit switch? We have a cam-driven spring kicker. It is programmed so that when the trigger is pulled, the limit switch is ignored and the cam motors are run until the limit switch deactivates and then reactivates. It works great for us.
Stephen Kowski
15-03-2010, 23:15
What about a simple limit switch? We have a cam-driven spring kicker. It is programmed so that when the trigger is pulled, the limit switch is ignored and the cam motors are run until the limit switch deactivates and then reactivates. It works great for us.
limit switch is what we are using for ours too.
What about a simple limit switch? We have a cam-driven spring kicker. It is programmed so that when the trigger is pulled, the limit switch is ignored and the cam motors are run until the limit switch deactivates and then reactivates. It works great for us.
Yes, that would work as well and would probably better for this application. I'm a bit biased because in our kicker, three limit switches would actually be more complex than the magnetic sensor. ;)
We do have the exact same setup as yours to release the kicker's dog gear.
AustinSchuh
16-03-2010, 04:29
We are using a continuous rotation potentiometer for a similar purpose. We wired it up like you would wire up any other pot, and it works well. And it is a lot cheaper than an absolute encoder or something like that.
Alan Anderson
16-03-2010, 09:01
We are using a continuous rotation potentiometer for a similar purpose. We wired it up like you would wire up any other pot, and it works well. And it is a lot cheaper than an absolute encoder or something like that.
A "free" component from the Kit of Parts (e.g. the magnetic encoder) is cheaper than any potentiometer. :p
Mark McLeod
16-03-2010, 10:21
We are also using a limit switch on our cam, and it usually works quite well.
One problem we ran into is that our kicker is adjustable and at high energy the whole robot shakes enough that the limit switch vibrates and can give a false reading that has to be programmed around.
pfreivald
16-03-2010, 10:34
One problem we ran into is that our kicker is adjustable and at high energy the whole robot shakes enough that the limit switch vibrates and can give a false reading that has to be programmed around.
Hmm... We haven't had that problem. Our limit switch triggers off of the kicker itself -- if it's 'ready to fire', the motor stops the cam until the trigger is pulled, and then runs it until the switch is triggered again.
Thus far, it's been super-solid.
the limit switch vibrates and can give a false reading
You've piqued my curiosity. Would you mind giving a bit more detail how the switch is mounted?
I can't picture how this might happen; certainly no amount of vibration of the switch itself (that could occur on the robot) could cause the switch to give a false reading... unless the vibration is causing the switch lever to bump against something?
~
The Lucas
17-03-2010, 10:09
We also use a cam driven kicker. We put a simple 1 turn pot on the shaft for the kicker (not the cam where you need continuous turns). This works well for us because we have multiple positions we want the kicker to be in: one position (middle of travel) for ball collection to stop balls from going under the frame, the other to give us clearance (close to kicking) to go over the bump. It is also easier to detect a pot failure than a limit switch failure.
Chris Hibner
17-03-2010, 10:32
Continuous pots work pretty well, but there are two "gotcha's::
1) The pot can shift over time due to shaft slippage. Usually not that big of a deal, but keep an eye on it.
2) (Potentially BIG) There is a gap in the pot at the wrap-around point where the voltage will float. That will give you false position readings in the gap. The gap may seem insignificant at first, but it grows over time as the pot mechanically wears.
There are two ways to cure #2. The first is to wire in a pull-down resistor so the voltage doesn't float. The second method is to put the gap at an angle that you don't need to stop the motor, stop reading the pot near the gap, do a timed motor command to get through the gap, then start reading the pot again. You may consider doing both. We were using a continuous pot at Kettering and we somehow lost the pull-down resistor. We had trouble kicking for a few matches until we figured out what happened.
If you want to use a relative encoder, your cam actually makes that quite easy. Start each match by driving the kicker motor backward with a small enough PWM so you don't damage anything. Montior the rate of the encoder. Once the encoder stops moving, you know you hit the edge of your cam. Reset the encoder position and then start using the kicker as you normally would. By doing this, you will get a very accurate zero point of the encoder every match.
If you want to use a relative encoder, your cam actually makes that quite easy. Start each match by driving the kicker motor backward with a small enough PWM so you don't damage anything. Montior the rate of the encoder. Once the encoder stops moving, you know you hit the edge of your cam. Reset the encoder position and then start using the kicker as you normally would. By doing this, you will get a very accurate zero point of the encoder every match.
Great suggestion, but may not be robust for our configuration. We'd have to thread the needle between going slow enough not to damage the motor/cam, and going fast enough not to get a penalty for having the end of the kicker outside the frame perimeter for more than two seconds. Also, it would chew up valuable time in autonomous.
What I envisioned doing instead was to pre-configure the cam in the "armed" ready-to-kick position when the robot is placed on the field. Then at the start of autonomous, zero the encoder counter.
What is the data type of the encoder counter in the FPGA? Is it large enough to just let it run free without overflowing during a match ?
~
Chris Hibner
17-03-2010, 14:24
What is the data type of the encoder counter in the FPGA? Is it large enough to just let it run free without overflowing during a match ?
~
The data type is double, at least in LabVIEW.
You can always convert the encoder output into degrees and do:
if (encoderDeg > 360)
{
encoderDeg -= 360;
}
or the LabVIEW equivalent so you don't have to worry about overflow. Then you can always stop the motor at the same angle.
The data type is double, at least in LabVIEW.
Yeah, but I doubt that the counter in the FPGA is floating-point.
I want to know if the FPGA counter will not overflow during a match.
You can always convert the encoder output into degrees and do:
if (encoderDeg > 360)
{
encoderDeg -= 360;
}
Does the above code actually write a new value to the FPGA counter itself? Or just zero the associated RAM variable in cRIO?
~
Chris Hibner
17-03-2010, 15:57
Yeah, but I doubt that the counter in the FPGA is floating-point.
I want to know if the FPGA counter will not overflow during a match.
Does the above code actually write a new value to the FPGA counter itself? Or just zero the associated RAM variable in cRIO?
~
If WPI and NI did things properly, it really doesn't matter if the FPGA counter overflows or not.
Let's assume they did things correctly. One possible implementation is that the FPGA services the encoder interrupts and keeps track of the counter in a signed 16-bit register. Then the WPI interface samples that register at a given time interval. The WPI code would be like the following:
// variable declarations
s16 encoderCnt = 0;
s16 encoderCntPrev;
s16 encoderDiff;
double encoderOut;
// ...
// in the loop
encoderCntPrev = encoderCnt;
encoderCnt = getFPGAencoderCnt();
encoderDiff = encoderCnt - encoderCntPrev;
encoderOut = encoderOut + encoderDiff*inchesPerCount;
// etc.
(by the way, s16 is a typdef'd variable type for a signed 16 bit integer variable. The actual declaration will depend on your micro)
With the above code, it does not matter if the FPGA encoder counter overflows. If you don't believe me, try the following code:
s16 counter1, counter2, counter3;
counter1 = 32765;
counter2 = counter1 + 5;
cout << "counter1 = " << counter1 << "\n";
cout << "counter2 = " << counter2 << "\n";
counter3 = counter2 - counter1;
cout << "counter3 = " << counter3 << "\n";
If you don't like C/C++, you can do the same thing in LabVIEW. You'll notice that the two's compliment math handles the wraparound flawlessly and counter3 will equal 5. With the subtraction, you'll never know an overflow occurred - and it doesn't really matter.
This is actually a very slick way of handling angles to avoid having to do a lot of wrap-around math and checking. If you always scale your angles such that 360 degrees is equal to the overflow point, the two's compliment math automatically takes care of all of the wrapping for you.
If WPI and NI did things properly, it really doesn't matter if the FPGA counter overflows or not.
Let's assume they did things correctly. One possible implementation is that the FPGA services the encoder interrupts and keeps track of the counter in a signed 16-bit register. Then the WPI interface samples that register at a given time interval. The WPI code would be like the following:
// variable declarations
s16 encoderCnt = 0;
s16 encoderCntPrev;
s16 encoderDiff;
double encoderOut;
// ...
// in the loop
encoderCntPrev = encoderCnt;
encoderCnt = getFPGAencoderCnt();
encoderDiff = encoderCnt - encoderCntPrev;
encoderOut = encoderOut + encoderDiff*inchesPerCount;
// etc.
(by the way, s16 is a typdef'd variable type for a signed 16 bit integer variable. The actual declaration will depend on your micro)
With the above code, it does not matter if the FPGA encoder counter overflows. If you don't believe me, try the following code:
s16 counter1, counter2, counter3;
counter1 = 32765;
counter2 = counter1 + 5;
cout << "counter1 = " << counter1 << "\n";
cout << "counter2 = " << counter2 << "\n";
counter3 = counter2 - counter1;
cout << "counter3 = " << counter3 << "\n";
If you don't like C/C++, you can do the same thing in LabVIEW. You'll notice that the two's compliment math handles the wraparound flawlessly and counter3 will equal 5. With the subtraction, you'll never know an overflow occurred - and it doesn't really matter.
This is actually a very slick way of handling angles to avoid having to do a lot of wrap-around math and checking. If you always scale your angles such that 360 degrees is equal to the overflow point, the two's compliment math automatically takes care of all of the wrapping for you.
What you suggest will likely work for this non-critical application whose running time is less than three minutes.
However, for the benefit of those reading this thread who are just learning about realtime control, and who may go on to program other realtime applications, the following caveat should be pointed out:
The 2010 FRC LabVIEW framework is most definitely NOT hard-real-time. Using code running in cRIO to re-set the FPGA counter is not a robust solution if high accuracy is required and you do not want to introduce errors that may accumulate over time.
At the very least, the reading and re-setting of the FPGA counter should probably be protected by a critical section to minimize the occurrence of accumulated errors.
~
On our kicker's cam we don't use an encoder, we use a hall effect sensor.
How it works is you place two magnets on your robot in the cam at a certain point. When you see an edge that means you crossed over a magnet, depending on how you arrange your magnets. At the top of our cam is a flat region where it sits when the sensor reads it. When it goes over the edge you see the edge again and can recock it easily.
We are going to change to an encoder though, they aren't quadrature or magnetic, they are analog encoders. Essentially an infinite potentiometer. Its setup in a 1:1 ratio so the same value is always cocked. You still need to calibrate when replacing the encoder though.
Chris Hibner
17-03-2010, 22:48
What you suggest will likely work for this non-critical application whose running time is less than three minutes.
However, for the benefit of those reading this thread who are just learning about realtime control, and who may go on to program other realtime applications, the following caveat should be pointed out:
The 2010 FRC LabVIEW framework is most definitely NOT hard-real-time. Using code running in cRIO to re-set the FPGA counter is not a robust solution if high accuracy is required and you do not want to introduce errors that may accumulate over time.
At the very least, the reading and re-setting of the FPGA counter should probably be protected by a critical section to minimize the occurrence of accumulated errors.
~
I'm not sure what you're saying here.
As far as I know, there is no cRIO code resetting the FPGA counter. My point was as follows (I didn't state it very clearly):
As long as:
1) the encoders are decoded by an interrupt handler in the FPGA
and
2) the cRIO samples the FPGA counter fast enough such that it cannot do a complete overflow cycle (e.g. the encoder cannot rotate more than 65536 counts (if 16-bit counter is used) in one cRIO sample).
and
3) The WPI code uses the difference between the current FPGA count and the previous FPGA count (instead of the absolute FPGA).
THEN
FPGA overflow does not matter, since the two's compliment math in the subtraction in step 3 above will work even in an overflow situation. You can run the cRIO for three years (not 3 minutes) and you will not see an issue from the FPGA counter. You will, however, eventually overflow the double-precision distance calculation from the WPI code, but that has nothing to do with the FPGA overflowing.
I'm not sure what you're saying here.
As far as I know, there is no cRIO code resetting the FPGA counter. My point was as follows (I didn't state it very clearly):
As long as:
1) the encoders are decoded by an interrupt handler in the FPGA
and
2) the cRIO samples the FPGA counter fast enough such that it cannot do a complete overflow cycle (e.g. the encoder cannot rotate more than 65536 counts (if 16-bit counter is used) in one cRIO sample).
and
3) The WPI code uses the difference between the current FPGA count and the previous FPGA count (instead of the absolute FPGA).
THEN
FPGA overflow does not matter, since the two's compliment math in the subtraction in step 3 above will work even in an overflow situation. You can run the cRIO for three years (not 3 minutes) and you will not see an issue from the FPGA counter. You will, however, eventually overflow the double-precision distance calculation from the WPI code, but that has nothing to do with the FPGA overflowing.
OK, my bad, in my haste I didn't look at your code carefully enough.
By the way, I love your sig line. Very clever. Is that an original ?
~
Chris Hibner
17-03-2010, 23:29
OK, my bad, in my haste I didn't look at your code carefully enough.
By the way, I love your sig line. Very clever. Is that an original ?
~
Cool. I'm glad I was clear the second time. I typed that first explanation as I was rushing to get away from my desk on my way to our fix-it window before the Detroit district event. It could have been better, but I was in a hurry.
My signature line is from a Rush lyric from the song "Vital Signs" (from the Moving Pictures album). It's a great line - good pun, yet so true.
The Lucas
18-03-2010, 00:09
A quick look at the C++ WPILib Encoder class source code suggests that it uses a 32-bit register (INT32) in the FPGA. There is no accounting for overflow that I see (but you might have a tough time overflowing 32 bits in a match with a reasonable application). You can reset the count with the Reset Function (it actually strobes a reset line). Since you probably will not overflow it you might as well just mod the encoder count by the number of ticks in a full cam revolution (plus whatever offset you need to find your stoping spot).
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.