-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternate Encoder Example moves to half the number of revolutions set. #15
Comments
Thanks for running with the example, can you provide a summary of how you have the sensor wired? |
One of the cables that was included with the encoder is plugged into the encoder on one end and an Alternate Encoder Adapter on the other end. The Alternate Encoder Adapter is plugged into the Spark Max such that the zip tie slots on the adapter and the Spark Max line up. I am running the code on a VMX-pi, not a Roborio, but I would not expect that to make a difference. |
Here is the latest code I was running to watch the behavior of the alternate encoder: #include <frc/TimedRobot.h> class Robot : public frc::TimedRobot {
// initialize SPARK MAX with CAN ID /**
public:
} void TeleopInit() override { void TeleopPeriodic() override {
} #ifndef RUNNING_FRC_TESTS Note that the above code sets the position conversion factor of the alternate encoder to 0.5, which gives me one revolution reported per one actual revolution. When I do not make that call, I get two revolutions reported per one actual revolution. |
@willtoth |
When running the Alternate Encoder example using the Rev Through Bore Encoder, the shaft with the Through Bore Encoder moves half the number of revolutions specified by the setpoint.
This appears to be because m_alternateEncoder.GetPosition() returns twice the number of revolutions that the encoder rotates. Strangely enough, changing kCPR from 8192 counts per revolution to 4096 counts per revolution does not seem to have any effect on this.
The text was updated successfully, but these errors were encountered: