A few days ago, one of our robot’s two optical shaft encoders started reading back some very strange values, bouncing between -1, 0 and 1, resulting in a very messed up autonomous. We witnessed these values both by using the RobotC debugger window, and reading the values live into the LCD. We made sure that the encoder was plugged snugly into the cortex, and then we tried niggling the wires that run out of the encoder. It appeared that after a big of wiggling around, the encoder would start working again, but would inevitably fail after a few more rotations, getting stuck at whatever three values were closest to the value it was on (ex: 245, 246, 247). We removed the encoder and opened it up; both on the sliding cover side, and unscrewing the four screws in the back of the casing. The soldering seemed to be fine, and aside from a bit of dust, there was no visible damage to the sensor. We blew out the dust, and tried it again in the cortex, but still had the same problem.
Has anyone ever experienced this problem?
Are there any known solutions?
Do you have any suggestions for what might be wrong, or what we might be able to try?
from what i remember you need to have the shaft encoder plugged in a certain way as in the rx and rt one of them need to be first. another thing is that it goes into digital im pretty sure. this was all based off of memory so dont expect it to be right.
There can be issues if you use digital port 4 and/or port 10. For example, using port 4 as one encoder input and port 10 for an LED can cause issues with ROBOTC.
I just checked our ports; there is a bump sensor in dgtl4, and nothing in dgtl10. Our two motor encoders are in dgtl6/7 and dgtl8/9. I guess this will be more clear:
dgtl1 led
dgtl2 sonar A
dgtl3 sonar B
dgtl4 bump
dgtl5 bump
dgtl6 right drive encoder A
dgtl7 right drive encoder B
dgtl8 left drive encoder A
dgtl9 left drive encoder B
dgtl10 ---
dgtl11 led
dgtl12 ---
I think I may have heard somewhere that because the encoders and sonar use interrupts, having too many may cause interference from one to another? Might this be related?
Use the good encoder to check the ports where you have the bad encoder to verify the cortex and software are working (use a simple test program to do this, not your competition code).
Next check each wire of the bad encoder, you can do this by setting one digital input to be of type “Encoder (single wire)” rather than a quad encoder. Plug in the first encoder cable, check that the encoder count increases (the encoder count will always increase, there’s no direction information in this mode), then check the second. If one of them does not cause the counter to increase you probably have a broken encoder.