Hello all, our team is in the process of improving our swerve code and thus we began to wonder if there was a way to implement (on the roborio’s side) functionality similar to the “Continuous input” feature of WPILib’s PID controllers so that we can use it with the built in PID of the TalonFX motor controller?

There is no way to do it directly on the falcon but you can calculate what it would be on the rio if you have the current encoder reading and the desired setpoint. This is our (probably unoptimal) solution for the rotation motor on our swerve drive.

/**
* @param currentAngle what the controller currently reads (radians)
* @param targetAngleSetpoint the desired angle (radians)
* @return the target angle in controller's scope (radians)
*/
public static double calculateContinuousInputSetpoint(double currentAngle, double targetAngleSetpoint) {
targetAngleSetpoint = Math.IEEEremainder(targetAngleSetpoint, Math.PI * 2);
double remainder = currentAngle % (Math.PI * 2);
double adjustedAngleSetpoint = targetAngleSetpoint + (currentAngle - remainder);
// We don't want to rotate over 180 degrees, so just rotate the other way (add a
// full rotation)
if (adjustedAngleSetpoint - currentAngle > Math.PI) {
adjustedAngleSetpoint -= Math.PI * 2;
} else if (adjustedAngleSetpoint - currentAngle < -Math.PI) {
adjustedAngleSetpoint += Math.PI * 2;
}
return adjustedAngleSetpoint;
}

Are you referring to this type of continuous?
No way to optimize for shortest turn and reverse motor direction if that’s what you want thus the comment.

I picked a bad example to try to understand what you meant by continuous.

You do mean that as the encoder makes one revolution it jumps from the maximum value back to the minimum value?

The TalonXXX supports that mode with the jump being between 360 to 0 or +180 to -180. If you don’t like the jump in either of those locations you can specify your own. I don’t think this applies to you, though; I should have picked a better example.

But that illustrated the limit of what a Talon can do as far as I can tell. It’s not going to calculate which way to turn; you have to do that. It does know that 0 follows 360 as the encoder turns.

Thanks for the correction. I lose track of what I’m doing sometimes and especially with the time zone change last Sunday (yawn). You’re here like me - learn from what others are doing.