Encoder: Can't Find Consistent Values for One Rotation

[joecapps1127]

Hello,
So my team has been working on our autonomous code. We would like to create timing based on the rotations of the wheels. However, we cannot figure out exactly what number is equal to one full rotation. I read many places that it should be 1440, but it is not for ours. It fluctuates from 1210 to 1240 each time we run the code. We need this to be more accurate. We are using standard Tetrix DC motors with Tetrix Motor Encoders. We are using RobotC and are a first year team.

We also tried doing the same thing with time. I.e. running the motor at 100% power for 500 ms is about one turn, but again, it fluctuates.

Our autonomous code kind of hinges on us getting this to work, so any help would be greatly appreciated.

Thanks!

[Eric Caldwell]

I don't know much about Tetrix motors or DC motors in general, but from experience, physics, and a little bit of research it seems like these fluctuations would be caused by the voltage of the battery. Applying max current for a set time will cause a different amount of rotations based upon the voltage of the battery.

You can see this by just driving the robot around for a while, if you let the battery voltage drop enough you'll notice that the robot feels more "sluggish." A little bit of research on wikipedia and other sites will also provide you with quotations like "Generally, the rotational speed of a DC motor is proportional to the voltage applied to it."

Since the fluctuations appear to be affecting your autonomous I would suggest trying something like PID to control your drive. You already have an encoder so if you have a little bit of time you should be able to get this going. If you need help getting a PID or any other system going feel free to PM me.

[Alan Anderson]

I agree, the documentation says a Tetrix motor encoder provides 1440 counts per revolution. How are you measuring it?

Perhaps more importantly, how are you using it? It's possible that your motor code is letting the wheel spin a teeny bit longer after the encoder reaches the desired value, instead of bringing it to an immediate halt.

[PAR_WIG1350]

Base on anecdotal evidence, the tetrix encoders are (expensive) junk that are nearly impossible to use for anything other than determining if the motor is moving, an if so, the direction in which it is moving. They are often used for detecting motor stall and preventing motor damage.

Welcome to Chief Delphi! I have no actual answer to your question, but since this is your first post, I'm going to assume you're at least somewhat new. Therefore, the Chief Delphi community gives a huge WELCOME to you!

[Alan Anderson]

Originally Posted by PAR_WIG1350

Base on anecdotal evidence,...

Based on more extensive documentation, the Tetrix Motor Encoders appear to be essentially the same thing as the encoders supplied in the FRC Kit of Parts for the past few years. When installed correctly, using the proper spacing of the plastic encoder disk from the circuit board, they work consistently well.

[rudun]

Is it possible to turn the shaft by hand and read the ticks output for one revolution. That is how we do it with the encoders provided with the FRC kit. Then based on wheel size you can figure out the distance per 1 revolution. The formula is floating around CD.

[Ether]

Originally Posted by rudun

Then based on wheel size you can figure out the distance per 1 revolution. The formula is floating around CD.

The distance the wheel travels per revolution is equal to the circumference of the wheel. One circumference is equal to pi times the wheel diameter.

So you can turn the wheel one revolution and count the encoder ticks... or you can count the encoder ticks for one encoder rev, then reduce that by the gearbox (and chain, if present) ratio to get the fractional wheel revs.

[feverittm]

There are also a couple of other possibilities (at least):

1 - The wheel shaft could be slipping in the encoder causing an changing number of ticks per revolution.

2 - The encoder wheel could be damaged (scratched). This can cause ticks to be missed or miscounted. Not at all deterministic.

We had these issues last year with our arm and needed to switch to a pot to measure arm angle. Not that a pot is that much more reliable.