[NotInControl]

I believe the microcontroller on the jag runs at a rate of 50MHz and the encoder is read at 1/4 of that rate. Not clear on how fast the control loop on the jag is running, but I think it is safe to say it is orders of magnitude higher than the software loop.

However you can only command it and read from it as fast as CAN packets are being sent/received.

In your requirement for 90 degrees in 60ms. How much of that is actuation time, and how much of that is settling time?

If you want to be at 90 degrees confirmed in 60ms, then you need the mechanical system (wheel/gear) and anything else that is tied to the motor load including friction between wheel and floor to accelerate and decelerate in that amount of time.

If your target is 60ms, then you should target an actuation time of 40ms, and a settling time of 20ms. Can your mechanical system move that quickly? That is pretty fast by any FRC standard.

If you also plan to run 4 independent loops, they each will settle differently because each motor will react differently. As your speed requirement increases, your engineering tolerances reduce, naturally. You will need very tight tolerances on the manufacture of the assembly, sensor mount, and backlash in order to have reasonable reaction time across all pods. Also take the time to test the motors you are using to ensure their drive characteristics are very similar to each other.

We typically run our control loops at 100ms and give our actuators a settling time of around 100-150ms on top of that because that is a very safe margin, and very achievable with the manufacturing tolerances on our team.

Although we have not done motion planning on FRC(yet) and all of our control loops run in software.

For the motion planning model on my work outside of FRC, a 100ms control loop was more than efficient to follow a waypoint path on a skid steer chassis. Not sure how that equates to the dynamics of a swerve, but I would hope they are somewhat comparable.

Plus, the baggage of CAN error implementation, preventing CANTimeOutErrors and all that other good stuff will need to be user implemented as part of the CAN baggage.

Regards,
Kevin