Quote:
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.