Quad Reads 1/2 of Expected Value

After struggling a bit with PID tuning today, I noticed that I was getting some weird readouts from one of my drive train’s quadrature encoders which had been working just fine since September. The right side encoder was always at a value considerably under its counterpart on the left, despite having both been reset simultaneously and having the robot move in a vertical line. I removed the encoder and plugged in a new one on the same ports. Did not have any issues with the new one so I know it is not the cortex or code.

We took the broken encoder and plugged it in to a test cortex along with another encoder, and did a test where we stuck a marked gear on each and rotated them a full revolution. The broken encoder read nearly 180, the other encoder read near 360 (intended value). Obviously, the small gaps are human error here. This checked with values that I observed while testing earlier too: where after driving forward in a straight line the left encoder read around 1000 and the right one (broken) read about 500. We also verified the functionality of each wire by unplugging one at a time, spinning the encoder, and observing the toggle in state between 1 & 0 or -1 & 0.

What is puzzling to me is that the encoder reads nearly exactly 1/2 of the expected value, regardless of how much it is turned. Thus, leads me to the conclusion that this is not a mere collection of error from a broken encoder, but actually just a loss of resolution from an otherwise functional sensor. Anyone have any ideas on what could be wrong with this encoder? Can I save this encoder and restore it to its 360 tick resolution? Are there any other reasonable debugging steps anyone can suggest?

edit: also worth noting that on the robot’s cortex we run PROS and on the test bench we have RobotC. Probably not a low-level software issue since the same result occurs on both.

Almost every time I’ve had issues like this has been due to debris within the encoder, and it worked fine after I (or my partner) cleaned it. I’m not quite sure what he does, but I take the whole thing apart and spray it with electronics cleaner spray. (Not canned air, but that might work too)

First thing, does it still show direction in the debug window, i.e. can it go from 0 to 1000 and then back to 0?

That would tell you if both phases are correct as a start.

Yes, it does read both ways. Both phases seem to be correct and both wires are reading as I explained with the 0 & 1 indicator.

I will give this a try today, we’ll see how it goes.

You could also try whether this half-speed is consistent - attach the encoder to a motor, start it at constant speed and record the datalog of the reported position - you’ll see whether the value increases linearly at half the expected rate, or whether there are discontinuities and segments of normal, full speed counting…

This was what I was thinking too. Like I mentioned, I sort of did this because I drove it around on my robot for quite some distance and the values stayed at half speed every time I glanced at it.

But yeah, this data would be good to get + graph. I’ll take a look at doing this. Thanks.

A similar suggestion, but a step further, for confirmation: attach two encoders to the same axle, this one and one that seems to be working fine. Record both of their values at essentially the same time. Graphing them simultaneously might well reveal far more than graphing them separately.

Our team had the exact same thing happen with us on a couple of encoders over the last couple of weeks. We plan to open them up and clean them and it is nice to hear that has worked for others.

As I understand it, the way the encoder works is that it has 180 holes. It counts the number of times the hole passes by a set point and the number of times a solid section passes by giving 360 counts per rotation. What seems to be happening is that it is only counting one or the other.

I suspect there may be an issue with wiring. One that was giving us fits was plugged directly into the cortex and it was a tight reach. They added 6" cables in between and that resolved the issue with one of the encoders.

Probably not. We tried it on two different cortexes with two different sets of wires. One of these cortexes is literally a test cortex and the wires were not even pulled taut.

I did clean out the encoder yesterday, I will test that next week. I will also try to get those graphs but that might take a while so it will have to wait till after our competition next weekend. Thanks for all the suggestions.

90 holes in the encoder wheel. So 180 edges that can be detected by each of the two sensors inside.

Thanks for the correction. So is it likely that one of the sensors is either bad or blocked by debris?