LabVIEW Encoder not reliably returning Rate

[apalrd]

Hello, all.

Yesterday, I was testing and tuning some code on a test chassis. It has two Toughboxes and US Digital encoders (from AndyMark, 250 count) connected to the last four digital inputs on the Digital Sidecar. In code, I found that Encoder Get does not reliably return Rate: I always get Distance (which I found to be accurate in both forward and reverse, by drawing a line on the wheel and reading the distance both ways. Only one of the encoders returns rate, though, which puzzles me. What puzzles me even more is that when I set the Decoding Type to 4x (Because that uses an FPGA Encoder instead of an FPGA Counter) it works - but only until I reboot (when the problem happens again, and is fixed by switching back to 1x).

I dug into the WPI Encoder Get to see if there was a bug there. WPI Counter Get is returning a time of Inf, which Encoder Get is scaling to 0. I went into WPI Counter Get, but that just talks to the FPGA (meaning I cannot dig deeper). When I first had the issue, I probed the Dev Refs and the non-working encoder was using Cntr 1 while the working encoder was using Cntr 0. I did not probe them using the 4x decoding, but when using 4x decoding, the other side (the one that worked before) now has the issue.

I am sure all of the hardware works. I swapped the encoder wires (Between encoders) and the problem is not the encoder itself. I also know that I am not missing the B-phase, because it counts forwards and backwards. Everything I have looked at points to a bug in the FPGA encoder handling, I am using the latest 2011 image. (I guess I could try the 2010 image to see if it works, but I won't have access to the robot until Monday).

Has anyone seen this issue? How did you solve it?

[lynca]

We had a similar issue in Java.

We had one returning a reasonably rate and a second encoder that was returning essentially garbage. We spent an hour debugging, swapping connectors and twiddling without any success.

We eventually just wrote our own rate functions and moved on.

[ebmonon36]

We also noticed the encoder rate not working when using 4x decoding and also found the problem coming from the counter returning a time of Inf. The rate returned a value of 0. We changed the decoding to 2x and began receiving rate data.

[robotsteve]

Originally Posted by lynca

We had a similar issue in Java.

We had one returning a reasonably rate and a second encoder that was returning essentially garbage. We spent an hour debugging, swapping connectors and twiddling without any success.

We eventually just wrote our own rate functions and moved on.

What do you mean about writing your own rate encoder??

Please explain --

Thanks-
Steve

[jhersh]

Originally Posted by apalrd

Hello, all.

Yesterday, I was testing and tuning some code on a test chassis. It has two Toughboxes and US Digital encoders (from AndyMark, 250 count) connected to the last four digital inputs on the Digital Sidecar. In code, I found that Encoder Get does not reliably return Rate: I always get Distance (which I found to be accurate in both forward and reverse, by drawing a line on the wheel and reading the distance both ways. Only one of the encoders returns rate, though, which puzzles me. What puzzles me even more is that when I set the Decoding Type to 4x (Because that uses an FPGA Encoder instead of an FPGA Counter) it works - but only until I reboot (when the problem happens again, and is fixed by switching back to 1x).

I dug into the WPI Encoder Get to see if there was a bug there. WPI Counter Get is returning a time of Inf, which Encoder Get is scaling to 0. I went into WPI Counter Get, but that just talks to the FPGA (meaning I cannot dig deeper). When I first had the issue, I probed the Dev Refs and the non-working encoder was using Cntr 1 while the working encoder was using Cntr 0. I did not probe them using the 4x decoding, but when using 4x decoding, the other side (the one that worked before) now has the issue.

I am sure all of the hardware works. I swapped the encoder wires (Between encoders) and the problem is not the encoder itself. I also know that I am not missing the B-phase, because it counts forwards and backwards. Everything I have looked at points to a bug in the FPGA encoder handling, I am using the latest 2011 image. (I guess I could try the 2010 image to see if it works, but I won't have access to the robot until Monday).

Has anyone seen this issue? How did you solve it?

I'm really curious if the same issue reproduces in any other language. There have been a few issues with the encoder rates in the past, but I had thought we fixed them all.

Have you tried modifying the averaging settings? How does that setting impact the behavior? Is there any interaction between the 2 resources... i.e. if you make one encoder 4X and the other 2X, does it still do this?

Thanks,
-Joe

<edit>I assume you are using v25 since that is the only non-beta 2011 image</edit>

[lon.bushweiler]

We ran into similar issues in Labview over the weekend. Like others, we wrote our own rate code and moved on.

[nchen99]

Today we tested the 9 possible resolution combinations of our two encoders, which we'll call Left and Right. When still, the encoder rates both return 0.0; when moving, the non-working one returns NaN (Not a Number). Here are the results:
Y = Yes/returned decimal value
N = No/returned NaN
Format:
LeftResolution, RightResolution: LeftResult, RightResult
4, 4: N, Y
2, 4: Y, N
1, 4: Y, N

4, 2: N, Y
2, 2: Y, N
1, 2: Y, N

4, 1: N, Y
2, 1: Y, N
1, 1: Y, N

[apalrd]

I did some testing last night:
I found that, after booting up the robot as flashed (1x, 1x) it worked fine for about 2 hours, only rebooting once to change the battery.

After it stopped working, nothing would fix it. Nothing. I rebooted several times and re-downloaded the code. I set the counter to average 2 samples, as advised in this thread, and it worked.

I didn't spend a whole lot of time testing, so I don't know if the problem will re-appear after use. I will try tonight.

[apalrd]

More testing today (about 3 hours or so):

1. The encoder does not work, even averaging 4 samples (only 1 side dosen't work, the other one is fine).

2. After getting it to work, it worked reliably for about an hour before quitting. Then, after changing some settings (like the decoding type) and rebooting, it worked again (and didn't quit while I was working on it)

3. It seems very random, yet always affects the same side. Has anyone from NI been able to reproduce this problem?

4. I am running image v.25

[Doug Norman]

I have reproduced this and believe it is a bug in our code. I suspect we may document this rather than fix it for this season for two reasons:
1. It would be a risky fix.
2. There is the work around of writing your own rate code.

[kamocat]

Originally Posted by Doug Norman

I have reproduced this and believe it is a bug in our code. I suspect we may document this rather than fix it for this season for two reasons:
1. It would be a risky fix.
2. There is the work around of writing your own rate code.

Do you have a single document describing all the bugs this season?

EDIT:
The Readme describes some of them, but leaves out CAN issues.
Is there a document that shows new issues, BEFORE a fix is created?

[Greg McKaskle]

I do not believe this release has a fix for this bug. I saw a post from Joe stating who would not let him fix it. He also didn't indicate whether he had really really fixed it this time, sorta fixed it, turned it into a feature, or other.

I agree there should be a known issues list along with workarounds. I'm not sure if the support forum has one. That would be the appropriate place to request one.

Greg McKaskle

[billbo911]

Originally Posted by Greg McKaskle

I do not believe this release has a fix for this bug. I saw a post from Joe stating who would not let him fix it. He also didn't indicate whether he had really really fixed it this time, sorta fixed it, turned it into a feature, or other.

I agree there should be a known issues list along with workarounds. I'm not sure if the support forum has one. That would be the appropriate place to request one.

Greg McKaskle

It has NOT been fixed in this update!

From the 3.1 README:

Known Issues:
When you use more than one encoder, the rate indicator does not update for all encoders. To avoid this behavior, write your own encoder rate code.

[cabbagekid2]

We just got started with the encoders that came in the KOP and are running into the same issue as everyone else. Our right side has both rate and distance but the left side only shows distance (rate is 0).

Originally Posted by lon.bushweiler

We ran into similar issues in Labview over the weekend. Like others, we wrote our own rate code and moved on.

We're going to write our own rate code and was wondering...since distance works for both sides if it's as simple as storing the present distance into a variable and subtracting the saved (previous present distance) from the prsent distance. This will be in periodic task...so that you can divide it by the loop time interval to obtain rate.

We tried this for our working side and came up with similar results as the encoder rate output and are hoping to get it working on the left side.

One thing we noticed though (both with our rate and the VI rate) is that it's REALLY noisy. When maxing out the joystick it bounces around anywhere from zero to 250 rpm (low gear). We had to up the sample average (which cleaned it up a little) and then added a point by point median filter. The only thing bad about this is that the filtered rate is only 100 rpm (can you imagine the noise to produce this!).

Anyone else have noise issues? We're still not sure if the rate data will be workable after all this filtering. More testing today...

Might also be the placement of our wires...will test that today too.

[jhersh]

One thing that was discovered is that every other encoder works... so if you allocate one and ignore it and then allocate another one, you can use the built-in rate function. Naturally this means you have half as many that you can use, but if you don't need that many, this may be a good solution for you.

-Joe