Encoders getting different rates

[jhellr13]

Originally Posted by tilky

if, for exampe, for every 800 counts of one of the encoders is 1 count for the other, the slow one you can set 800 for the distance per count, and the other one (the faster one) you can set 1 for that amount. This will make them equal the same.

I see what you mean now. That's probably what I'll end up doing later when I go to work on the bot.

I have another question: The side with the higher reading on the encoder right now spins faster than the other side. Once I tune the encoders to be consistent like you said, is there a way I can get the faster side to spin the same speed as the slower? I assume like a pid system where the encoder on the slower side is the setpoint and the encoder on the faster side is the process variable.
How would I make this work with a tank drive though?

Any help?

[tilky]

you would have to tune them when both motors are running at the same speed. do you have a rpm meter in your shop?

[jhellr13]

Originally Posted by tilky

you would have to tune them when both motors are running at the same speed. do you have a rpm meter in your shop?

I don't believe we have one. Yesterday, I was trying to multiply the faster side by a constant before it is fed into the tank drive block to attempt and get it close to the other side. I didn't get very far as my mentor was telling me that it would be easier to do it when the encoders are in sync.

[tilky]

that is right, but how would you get them in sync if the motors aren't turning at the same speed?

[jhellr13]

Originally Posted by tilky

that is right, but how would you get them in sync if the motors aren't turning at the same speed?

That's exactly what I was thinking. Today when I go to work on the robot, I'll probably work again with that constant to multiply by. Seems like the only way I can really get both sides close to each other.

[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.

[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

[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.

[tilky]

i said to do that if they are consistant, meaning that there isn't a problem, other than different scaling