I’ve been recently trying to learn how to use encoders. From the documentation, it seems that the only method that is useful for setup is the setDistancePerPulse method and maybe the setSamplesToAverage method. However, the documentation isn’t very clear on how to determine the value to pass in. I looked over various CD threads and there seemed confusion on what calculation to use. Some said to use: 1 / encoder’s pulse per revolution (ppr). Others seemed to say to use: the circumference of the wheel (wheel diameter * Pi) / encoder’s ppr. I would like to know which calculation to use and some insight into why the other one wouldn’t work.
A lot of threads also seemed to be using the E4T optical encoder, but I would like to use the AMT103-V encoder with a resolution of 1024 ppr.
If you are using setDistancePerPulse, then what you pass it needs to be a distance value equal to the travel associated with a single encoder pulse.
This means inches have to be included in your calculation somewhere.
(wheel diameter * Pi) (inches) / encoder’s ppr
breaks down to inches (or centimeters if you’d rather) per encoder pulse.
Perhaps think of it as the distance traveled by the wheel during one full rotation of the encoder (wherever it is mounted), say 6 inches, divided by the number of pulses you are using (for instance 1x vs 4x returns different ppr for the same encoder). In your case that might be 6 inches of wheel travel divided by 1024 counts per one full revolution of the encoder.
A sanity check would be to:
lay out a tape measure on the floor
zero your encoder readings (display them somehow)
push the robot a fixed distance
*]Divide the distance pushed by the encoder counts
There is no “correct” value to pass, it is determined by your use case. You must make a decision about the units you want the encoder to read in (for a drive encoder, this might be inches, feet, or rotations - there’s no “correct” choice), and then determine the value to pass from the encoder’s PPR and the geometry/mechanics of the mechanism.
As a rule, you should always seek to understand the concept behind a calculation, rather than simply to memorize the calculation itself. Think about the two suggested calculations you mentioned. What would each of those return after one full turn of the encoder? Dimensional analysis is your friend here.
Thanks, it’s starting to make sense now. Essentially, the numerator represents one unit of distance, right? For instance, if you use the circumference of the wheel, the returned distance would be measured in rotations of the wheel.
I am still confused on the ppr. How does the decoding factor (1x, 2x, 4x) change the encoder’s ppr? With the E4T encoder, the ppr is 1440 but with 4x, I saw many treating the ppr like it was 360. The AMT103-V encoder can have different ppr based on what you set its switches, so I assume this encoder works more or less the same as the E4T one asides from the different resolution. Also, what does it mean by an encoder’s cycles per revolution (cpr)?
You’re almost there, but not quite. “Distance per pulse” is the conversion factor between displacement measured in encoder pulses, and displacement measured in an arbitrary unit of your choosing. That is to say,
You suggest that setting the numerator to the circumference of the wheel will yield displacement measured in rotations. Does this hold up if we go through the dimensional analysis? Imagine turning the wheel one rotation (assuming the encoder is mounted to the wheel shaft). The resulting displacement in pulses will be (by definition) the PPR of the encoder. What do you get when you multiply PPR by (wheel circumference)/PPR? How might this value relate to the corresponding movement of the robot?
I am still confused on the ppr. How does the decoding factor (1x, 2x, 4x) change the encoder’s ppr? With the E4T encoder, the ppr is 1440 but with 4x, I saw many treating the ppr like it was 360. The AMT103-V encoder can have different ppr based on what you set its switches, so I assume this encoder works more or less the same as the E4T one asides from the different resolution. Also, what does it mean by an encoder’s cycles per revolution (cpr)?
As per the documentation, the decoding factor changes nothing for WPILIB’s handling of encoder distance conversions, so you should always use the full PPR.
Encoder resolution is sometimes given in CPR, which is simply PPR/4. The reason for this is that the encoders we use are “quadrature” encoders, which means the signal they generate is periodic with each period containing four pulses. This is done so that the encoder can distinguish movement in different directions, and the details of how it works can be found on wikipedia.
The AMT-103 is great, but if you want more precision you’ll need to put an encoder on your wheel shafts. This can be done with the AMT or with a shafted encoder. If you have a Talon SRX, the Mag Encoders are pretty good too.
The units you use are arbitrary. For linear distance converting to inches may make sense, but the easiest way is to just do as Mark suggested and directly measure it.
Now, say you would like to mount the encoder onto the gearbox instead of the wheel shaft. Then, using dimensional analysis, how would you factor in the teeth on the gears or, for instance, if the output shaft rotates 1 time for every 1/4 turn of the input shaft.
Well, let’s think through it. If our encoder is on our motor shaft, and there’s a 4:1 reduction between the motor and our robot’s wheels (what you described would actually be 1:4, but you’re never going to gear up for an actual drive), then if we turn the robot’s wheel one full rotation, the motor shaft turns 4 times. Thus, the number of encoder pulses for one wheel turn becomes 4*PPR, rather than PPR. So, what do we have to do to the conversion factor to account for this?