Hello there, how would I convert encoder values to inches? My team uses 4-inch Omni wheels. Motors are H.S directly connected to the wheels. And the encoder has a 1:1 ratio with the 4-inch wheel. My apologies if there is already a thread on this.
Thanks
Look at “Basic Autonomous Movement” in this article:
https://renegaderobotics.org/vex-sensors-shaft-encoders/#auton
what you need to do is calculate/find out how many RPMs your wheels+motors will be running at, for example the Torque variation has 100 RPM, and the High Speed has 140 RPM, while Turbo has 240 RPM. Next you find out what the circumference of your wheel is (the distance all the way around it). That formula is 2(pi)(Radius), however I prefer to use Pi*diameter, as its simpler to do in my head. The diameter of the 4" omnis is 12.566", and the 3.25" is 10.21". Now after you found this out you have to know that there are 360 ticks in a rotation for an optical encoder, so all you have to do is divide the number of ticks per revolution, by the circumference of your wheel. So for a 4" omni wheel you’d have 360/12.566=28.65 ticks per inch. For a 3.25" omni wheel it’d be 360/10.21=35.21 ticks per inch. This is all in theory, and as we all know other things will come into play like wheel slippage, and other variables, however this should get you a fairly accurate reading of ticks to inches, hoped I helped!
Um, @9065_Parker , there is no need to know the RPM of the motors. The encoder is 1:1 with the wheel rotation. All you need to know is the ratio to the wheel rotation. The motor speed is absolutely irrelevant. Now, if these were integrated motor encoders (which they must not be), that would change things.
Otherwise, what @9065_Parker said is pretty good, but it’s easier if you do inches per tick instead of ticks per inch (both for coding and for code efficiency) for what you asked for. pi*diameter for 1 rotation, which is 360 ticks. So each tick is theoretically pi/90 inches. Just multiply your encoder value by pi/90. However, more likely you want to know ticks to go a certain distance instead of the distance covered per tick, so @9065_Parker 's method would generally be a better approach. Multiply the distance in inches by 90/pi to get the number of ticks you want.
Yes, slippage and the like become issues. The bigger issue will come with deformation if you’re moving around on the competition pads. What you really want to do is start with that 90/pi. Run it for a significant distance (like 8’-10’), measure the actual distance it went in that number of ticks, take the ratio between the those distances, and scale the 90/pi by that ratio.
Thank you all very much
I realized that after finishing writing it, and then realized i actually calculated the slippage in my code based on the ratio/speed of the motors.