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.
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…
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.
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.
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.”
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.)?
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?
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!
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.