Best Practices for Encoders and Control Loops

On the SparkMAX there is an alternate encoder mode that allows for the ability to plug in a quadrature or absolute encoder. However, these encoders can also just be plugged into the DIO ports on the Rio, with 2 inputs for the quadrature and 1 input for a duty cycle absolute encoder.

This year, my team plugged all of our external encoders into our RIO. We also ran all PID control loops on the RIO, not offloading them to the SparkMAX. We did not encounter any visible downsides from this, everything on the programming side went mostly fine.

Is the refresh rate for encoders and control loops ran on the SparkMAX significantly better, and are there any benefits to utilizing it?

yes it is 1000hz on sparkmax vs like 100(?) on roborio, and not really/probably not

While not being that much visibly better, it does help. It removes load from the rio, easier code-wise, and runs 20 times faster (1000hz on the spark compared to 50hz on the rio).
Another advantage is that you can send one request to a motor once (i.e. go to 90 degrees), rather than calculating PID values each loop.
I would consider on-board PID better practice, but both work good enough for FRC needs.

1 Like

I’m a firm believer in doing the PID in the motor controllers for all the reasons stated until it doesn’t work. We got random occasional fatal (to the device under control) errors of the magnet offset being wrong trying to use the TalonFX with a remote CANcoder. After spending way, way too many precious hours troubleshooting and never resolving the problem we use the WPILib PID controller with the same good control and without any weirdness.

We’ve always used the WPILib Swerve PID and ProfiledPID for our drivetrain no matter which motor/motor controller we’ve used .