View Full Version : Encoders getting different rates
jhellr13
20-02-2012, 13:00
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!!!
are they both consistant (when the fast one reads 3000 does the other read 80)?
jhellr13
20-02-2012, 15:00
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.
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
20-02-2012, 15:11
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?
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
20-02-2012, 15:26
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.
that is right, but how would you get them in sync if the motors aren't turning at the same speed?
jhellr13
20-02-2012, 15:31
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
20-02-2012, 15:50
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
20-02-2012, 15:57
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.
i said to do that if they are consistant, meaning that there isn't a problem, other than different scaling
Kevin Sevcik
20-02-2012, 16:08
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
20-02-2012, 16:10
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.
ok so since they both work, but at different rates, the method i gave above will work.
jhellr13
20-02-2012, 16:29
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?
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
20-02-2012, 16:33
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
what school are you from?
Alan Anderson
20-02-2012, 16:36
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.
The letters don't tell you how many counts per revolution the encoder provides. That's in the numbers. The E4P encoders used on AndyMark gearboxes have a "250" in the part number that refers to the 1/4" shaft they go on, but they have another three-digit number that's the important one here. The KOP encoders have been 250 or 360 counts per revolution.
Find out what the full part numbers are and you'll probably see why one of them is reporting much smaller values.
jhellr13
20-02-2012, 16:41
what school are you from?
Comsewogue
jhellr13
20-02-2012, 16:42
The letters don't tell you how many counts per revolution the encoder provides. That's in the numbers. The E4P encoders used on AndyMark gearboxes have a "250" in the part number that refers to the 1/4" shaft they go on, but they have another three-digit number that's the important one here. The KOP encoders have been 250 or 360 counts per revolution.
Find out what the full part numbers are and you'll probably see why one of them is reporting much smaller values.
That could be it. I'll look into it
jhellr13
20-02-2012, 16:51
ummm....where is that?
Suffolk county...
ok. i'm guessing you know where connetquot is, so see you there
Brandon_L
20-02-2012, 17:46
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.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.