Encoders getting different rates

[jhellr13]

Originally Posted by Kevin Sevcik

This seems like a very bad idea. You currently have two encoders that aren't functioning at all the same, and you're thinking of fixing the problem by scaling the outputs? You don't even know if you're getting good reliable values from the encoders. I would very much recommend that you first verify that the values from your encoders at least somewhat correspond with reality.

If you get the wheels off the ground and give your drive train a full forward command, the motors will be turning pretty darn close to their no-load speed. That'd be 5200 RPM. You should be able to calculate what the rate reading of your encoder should be based on that and the gear ratio of your transmission. Hopefully one of your readings gets close to this number. Then you know which encoder is wrong and you can start looking at that one to figure out what's wrong. It might be bad wiring, a bad code wheel, a different code wheel, an incorrectly installed code wheel, bad programming.... What ever it is, you're better off figuring out why these encoders are so different and fixing that problem instead of making a workaround based off assumptions you haven't verified. For all you know, the encoder that's reading 50 counts isn't actually plugged in and you're reading noise on the digital IO lines.

I know for a fact both are plugged in. The wheels have been off the ground since we put the encoders on (2 days ago). I plan on calculating the distance per count by pushing the robot 10 feet and taking the readout from Labview and going from there. A much simpler approach then what you said. I'm NOT trying to make a workaround based off assumptions. We already switched the slower encoder once and don't have anymore left.

[Kevin Sevcik]

Originally Posted by jhellr13

I know for a fact both are plugged in. The wheels have been off the ground since we put the encoders on (2 days ago). I plan on calculating the distance per count by pushing the robot 10 feet and taking the readout from Labview and going from there. A much simpler approach then what you said. I'm NOT trying to make a workaround based off assumptions. We already switched the slower encoder once and don't have anymore left.

If you switched out all the parts of the slower encoder with another one and it stayed the same, that points to a software problem. In that case, I'd try replacing your "fast" encoder with the original "slow" encoder. If your formerly "slow" reads fast, then try swapping the cables. If it still reads fast, then it's a software thing or a really weird DSC problem. If it reads slow, then the problem is following the cable and you need a new cable. If you end up with two "slow" encoders back there at the beginning, then atleast you have two encoders that seem to be performing the same.

[jhellr13]

Originally Posted by Kevin Sevcik

If you switched out all the parts of the slower encoder with another one and it stayed the same, that points to a software problem. In that case, I'd try replacing your "fast" encoder with the original "slow" encoder. If your formerly "slow" reads fast, then try swapping the cables. If it still reads fast, then it's a software thing or a really weird DSC problem. If it reads slow, then the problem is following the cable and you need a new cable. If you end up with two "slow" encoders back there at the beginning, then atleast you have two encoders that seem to be performing the same.

That's not exactly how it worked. We had 2 encoders that were never used or if they were very slightly. We put those on, and only one was getting a reading. We replaced the one that wasn't working with an encoder from 2010 that we knew worked from that year. That is the one getting the slower reading.

[tilky]

ok so since they both work, but at different rates, the method i gave above will work.

[jhellr13]

Originally Posted by tilky

ok so since they both work, but at different rates, the method i gave above will work.

Exactly. In my code right now I just have the distance per count set at 1 for both and they are both at 1X. I'm just going to lay out 10ft, push the robot, get the readouts for both, divide 10ft * 12 inches by the count for each side. Then I will have the distance per count for both. If that goes the way I think, both encoders will be in sync with each other afterwards. What do you think?

[tilky]

it sounds perfect. and this test will kill 2 birds with one stone; you will be able to find the counts per foot at the same time

[jhellr13]

Originally Posted by tilky

it sounds perfect. and this test will kill 2 birds with one stone; you will be able to find the counts per foot at the same time

Great! Thanks for the help. See you guys next month at Hofstra

[tilky]

what school are you from?

[jhellr13]

Originally Posted by tilky

what school are you from?

Comsewogue

[tilky]

ummm....where is that?

[jhellr13]

Originally Posted by tilky

ummm....where is that?

Suffolk county...

[tilky]

ok. i'm guessing you know where connetquot is, so see you there

[Brandon_L]

We had the same problem with ours. One side was giving reliable readings everytime, the other would give us some random garbage. We figured it out by manually rotating the axis the encoder was on by 1 revolution, and looking at the output, several times. They were very consistent, compared to the other side that would give us garbage. We looked at our wiring and found that the plastic clip the wires plug into was cracked and one of the signal wires was pretty much not connected. Pull it out and just check on it. After we replaced it, its been working fine.

If you rotate them one revolution and both sides are giving similar readings every time, then you can go ahead and scale them. For example if side A was giving you 140 and B was 360, you know that 140X=360. 360/140=~2.6. So you multiply the one side by ~2.6 to get them equal.