encoder for cam-driven kicker?

[Alan Anderson]

Originally Posted by AustinSchuh

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.

[Mark McLeod]

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]

Originally Posted by Mark McLeod

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.

[Ether]

Originally Posted by Mark McLeod

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]

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]

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.

[Ether]

Originally Posted by Chris Hibner

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]

Originally Posted by Ether

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.

[Ether]

Originally Posted by Chris Hibner

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]

Originally Posted by Ether

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.

[Ether]

Originally Posted by Chris Hibner

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.


~

[JGurnow]

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]

Originally Posted by Ether

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.

[Ether]

Originally Posted by Chris Hibner

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 ?


~