Problem with quadrature encoder

[Steve Compton]

I just got his from one of my programmers who is playing with encoders. Can anyone provide some guidance after reading the description below?

Gotta problem... We have used encoders for various things this year.
In each of these cases we have used the encoders to measure position. Just the angle of something.
The encoders also have a "rate" pin on them. It tells us how fast something
is spinning which is what we need for traction control.

We have noted that that the encoder, when measuring "rate", measures
zero after a short time of working correctly. In other words, we spin
the wheel, the rate pin shows a velocity, and then after a short
distance, the rate pin no longer measures velocity (it shows zero).
Then once we stop the wheel, and start spinning it again, the rate will
be measured correctly again for a short distance before falling to zero.

We found a usfirst thread on this that is a month or so old. It says
that an encoder in quadrature (4x) mode (which is what we have), will do
this but if you use the "averaging option" of 1x or 2x it will be fine.
We don't see this. It breaks reliably no mater what averaging we use.
It also says this will be fixed in the next cRIO update. It's not.

Thanks in advance!

[Mike Betts]

Steve,

Your post is confusing as to when you are referencing the physical encoder and when you are referencing the encoder vi, yada, yada...

That being said, I assume that you are referencing the LabVIEW software...

I would suggest that your programming team load the "encoder example" project and look at how the "minimum rate" control to the "encoder: config timer" vi affects the functionality...

Regards,

Mike

[Steve Compton]

Thanks, Mike! I. I'll see if I can get your suggestion worked on, as well as trying to get more precise language in case I need to send something back out to you all. Appreciate the help.

[Greg McKaskle]

Definitely compare to the example. The bug by the way is only present with 4x encoding with no averaging. 4x works with as little as 2 pts of averaging and 1x and 2x work with or without. Work of course has to include the behavior of the minimum rate parameter, and for that the docs help and the example should drive it home.

Greg McKaskle

[Joe Ross]

I think you found this bug: http://forums.usfirst.org/showpost.p...5&postcount=34

[Steve Compton]

Thanks Mike, Greg and Joe. My programmers think it's something to do with the FPGA counters. We're using 128 bit grayhills, but we've seen the same results when we were using ultrasonics earlier in the season:

quote from progammer
"With the Ultrasonics in particular I used several methods. Whenever I used the
FPGA counters, things broke. These are the same counters the encoders use and we are getting similar dysfunction."

Also, we loaded the out of the box 'encoder example' and this is the result:

"so I just loaded up the example out of the box. It broke the same way,
no matter what the averaging and minimum sample settings."

any thoughts?

[Jared Russell]

Does the 4x bug affect C++ code as well, or is this strictly a LabView issue?

[Steve Compton]

Both. Seems to be the timer, I think, in the FPGA

[Greg McKaskle]

Does the 4x bug affect C++ ?

I can't say definitively that there was never a bug with encoders on C++ development, but the 4x encoding bug we are describing is specific to LV.

Greg McKaskle

[Steve Compton]

Thanks, Greg. I did all that research too to discover the same in these threads, so was surprised to have my programmer say it could happen in both. How about the fact that we also got 'zeroing' when playing with ultrasonics? Does that tell you anything? I'm wondering if we aren't getting a battery voltage number as a divisor (like in the analog input issues discussed in a thread for WPI libs.)?

[Greg McKaskle]

I'm not going to be much help until Monday as I'm at a regional. The latest head slap with C++ libs and unique to those had to do with synchronization that wasn't enabled. I believe that was what caused the analogs to mix channels and confuse channel data if polled too often. I think it would occasionally cause other symptoms.

Is anyone else able to reproduce the issue, and do you have any insight into a workaround or root cause?

Greg McKaskle

[Steve Compton]

Thanks, Greg. Hope you get a chance to breather once in a while at the competition - I know our NI guy at Trenton (I'm embarrassed to say I forget his name) was instrumental in helping tons of teams deconstruct and solve all kinds of challenges.

Do you think the issue that arose with analog could possible also happen similarly with the digital inputs? I'm afraid I know too little about this part of our work to really be able to think as critically as would be useful here!

[Ken Streeter]

Originally Posted by Jared341

Does the 4x bug affect C++ code as well, or is this strictly a LabView issue?

The problem with incorrect rates was present in both the C++ and the LabVIEW code. A workaround for this was released in the most recent official update to WPILib (for both C++ and LabVIEW). For C++, I know this was addressed in "C/C++ Update 3.0.1718". (See http://first.wpi.edu/FRC/frcupdates.html ) Discussion on this matter can be found at http://forums.usfirst.org/showpost.php?p=26395 as Joe Ross mentioned.

However, due to the manner in which the length of the "most recent" pulse is used to determine the rate, the fact that the encoder pulse widths are asymmetric leads to significant rate errors when using 2x and 4x pulse decoding. Accordingly, I personally would suggest using 1x decoding when using the encoders for rate measurement.

A few people are working on a software workaround to the pulse asymmetry issue by averaging a greater number of periods, which has achieved some improvement, but not as much as expected. (See http://forums.usfirst.org/showthread.php?t=12218 for further discussion.)

[Jared Russell]

Originally Posted by Ken Streeter

The problem with incorrect rates was present in both the C++ and the LabVIEW code. A workaround for this was released in the most recent official update to WPILib (for both C++ and LabVIEW). For C++, I know this was addressed in "C/C++ Update 3.0.1718". (See http://first.wpi.edu/FRC/frcupdates.html ) Discussion on this matter can be found at http://forums.usfirst.org/showpost.php?p=26395 as Joe Ross mentioned.

However, due to the manner in which the length of the "most recent" pulse is used to determine the rate, the fact that the encoder pulse widths are asymmetric leads to significant rate errors when using 2x and 4x pulse decoding. Accordingly, I personally would suggest using 1x decoding when using the encoders for rate measurement.

A few people are working on a software workaround to the pulse asymmetry issue by averaging a greater number of periods, which has achieved some improvement, but not as much as expected. (See http://forums.usfirst.org/showthread.php?t=12218 for further discussion.)

Great info. I have definitely noticed the "noise" in the rate signal from our encoders at 4x as well, and got around the problem by low pass filtering. But asymmetry coming into play makes perfect sense.