You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In prior versions of the REV libraries for FRC, the RelativeEncoder interface has supported "setPositionConversionFactor" and "setVelocityConversionFactor" functions, to be used in allowing the encoder to automatically convert from native rotations/RPMs to specific units of distance/velocity (e.g., converting encoder ticks to meters/meters per second, based on gearing, wheel diameter, etc.) when reading data back from the encoders.
The current 2025 version of the RelativeEncoder interface appears to have dropped these functions. However, the documentation comments for the com.revrobotics.RelativeEncoder in the Java library still reference them on the "getPosition()", "setPosition()", and "getVelocity()" function comments, as can be seen in the screenshot below:
As these functions are extremely useful in simplifying the handling of encoder values (vs. forcing teams to explicitly convert rotation-based numbers to "unitized values" every time), having these restored to the RelativeEncoder interface would be very helpful.
The text was updated successfully, but these errors were encountered:
Note: these functions still seem to be present in the various *EncoderSim classes, based on the current docs, but aren't exposed through the RelativeEncoder interface, or for the real encoders.
In prior versions of the REV libraries for FRC, the
RelativeEncoder
interface has supported "setPositionConversionFactor
" and "setVelocityConversionFactor
" functions, to be used in allowing the encoder to automatically convert from native rotations/RPMs to specific units of distance/velocity (e.g., converting encoder ticks to meters/meters per second, based on gearing, wheel diameter, etc.) when reading data back from the encoders.The current 2025 version of the
RelativeEncoder
interface appears to have dropped these functions. However, the documentation comments for thecom.revrobotics.RelativeEncoder
in the Java library still reference them on the "getPosition()
", "setPosition()
", and "getVelocity()
" function comments, as can be seen in the screenshot below:As these functions are extremely useful in simplifying the handling of encoder values (vs. forcing teams to explicitly convert rotation-based numbers to "unitized values" every time), having these restored to the
RelativeEncoder
interface would be very helpful.The text was updated successfully, but these errors were encountered: