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.
Gentle ping: REVLib 2025.0.2 was just released, and this issue still appears to be present (at least, according to the docs on REV's web site, as can be seen below; the release isn't yet available as an online update in VSCode for FRC teams).
Sorry for the delayed response. We acknowledged this issue, but never updated you as we were dealing with some higher priority bug fixes, and I apologize for that. Additionally, I originally thought this report was just about the javadocs being wrong which is why responding was pushed back so much, but upon further reading, I can see your confusion.
For the issue you reported, yes, the javadocs are incorrect and reference methods that have been dropped in the REVLib 2025. However, the feature of setting conversion factors was not completely removed. Rather, the conversion factors are set through SparkMaxConfig (or SparkFlexConfig). An example of migrating this specific setting to REVLib 2025 can be found here.
We will update the javadocs accordingly for the next release. Thank you for submitting an issue and again I apologize for the late response. Let me know if that helps or if there are any other issues.
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: