encoder for cam-driven kicker?

[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 ?


~

[Chris Hibner]

Originally Posted by Ether

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]

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