Almost certainly this issue is due to your code. Either it's driving two different motor values from two different parts of the code, or disabling and driving from two different parts of the code.
This can be a bit subtle to find, as we found out this year when we had a near-identical symptom with our CANTalon use of limit switches. We were resetting our encoder value to 0 when the limit switch was pressed, and the code to do so effectively looked like this:
Code:
if (motor.isFwdLimitSwitchClosed()) {
motor.changeControlMode(ControlMode.Position);
motor.setPosition(0);
}
...
if (driving pid) {
motor.changeControlMode(ControlMode.Position);
motor.set(...);
}
else {
motor.changeControlMode(ControlMode.PercentVbus);
motor.set(...);
}
The issue was with calling changeControlMode() in the first if statement, which calls applyControlMode(), which in the non-pid case results in the motor being disabled until set() is called again (which happens later in the code). The fix was to not call changeControlMode() here--it's not necessary to be in Position Control mode to set the position.
I would recommend carefully examining your code to see if you might have a similar hidden issue. Even if you're not using changeControlMode(), simply calling set() from two different locations would cause the same stuttering issue.
__________________
Author of
cscore - WPILib CameraServer for 2017+
Author of
ntcore - WPILib NetworkTables for 2016+
Creator of
RobotPy - Python for FRC
2010 FRC World Champions (
294, 67, 177)
2007 FTC World Champions (30, 74,
23)
2001 FRC National Champions (71,
294, 125, 365, 279)