Encoders getting different rates

[jhellr13]

Hey guys
Been working with encoders the past few days on the drive train. Both encoders are e4p models, though one has an H in the model while the other has all Ds. I'm not exactly sure of the entire model number as I don't have them in front of me, but I definitely know one is all Ds and the other has Ds and a H.

Our Problem: The one with the H is reading the values way slower than the other. The robot could be on full throttle for 5 seconds and this encoder would be at 40 while the other would be at 1500. Major difference. I figure you could just scale the faster one way down to match the slower...?

Any ideas?

please help!!!

[tilky]

are they both consistant (when the fast one reads 3000 does the other read 80)?

[jhellr13]

Originally Posted by tilky

are they both consistant (when the fast one reads 3000 does the other read 80)?

what do you mean by consistent? I haven't really looked at the numbers like that if they are consistent with one another.

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

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

[tilky]

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

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