Issue with Color Tracking Example (C/C++) and with Counters, Encoders, and Ultrasonic

Technical Programming
1

A newer version of the two color tracking example was just posted that fixes a bug found by a team. The fixes will be included in the version of WPILib that will be in the next update, but in the mean time the changes are included in this project.

You can get the new version from http://first.wpi.edu/FRC/frcupdates.html.

There is also a problem that was discovered in the FPGA that causes reading the period or rate on an encoder or counter to be incorrect. It also causes unreliable readings from ultrasonic sensors using the Ultrasonic class. We are currently working on a fix for the problem and it will be in the next update. If you are using these features of the library, continue planning on using them but be aware that your results might not be correct until the next update.

Counters and encoders are correctly reporting counts (just not time related values). So using an encoder to measure distance is not a problem.

Since the encoder/counter/ultrasonic problem is in the hardware, it applies to LabVIEW programs as well as C/C++ programs.

2

i can confirm that this problem exists in labview. we spent several hours Sunday trying to understand why the rate occasionally reads zero, when the encoders were spinning at a constant speed.

we did use the distance value from the encoders to create our own speed values. simply remember the time and the distance value using feedback nodes from one reading till the next.

jerry

3

Is there any estimate as to when we should expect this fix?

Thanks

4

I believe we may have been bitten by this FPGA bug too… We have US Digital encoders mounted on our ToughBox gearboxes. Operating in LabView we were able to assign the proper scaling and get a believable distance measurement (checked by rotating a wheel 10 times and confirming that the distance readout was very close to the expected 15.7 feet. The rate measurement is off substantially. The encoder functions are reporting a rate of around 3.6 fps when we know it is more like 6.6 fps. The encoder on the other wheel also yields a good distance, but it’s rate output is extremely erratic. Unclear whether the erratic behavoir could also be related to the FPGA problem.

Can you please elaborate on the precise nature of the FPGA problem, and whether it could yield erratic behavior of just some kind of consistant bias?

-Thanks