Control loop timing of various motor controllers?

I was wondering about the control loop timing for handling RPM control of a flywheel with various motor controllers. What is the frequency or period of this control loop running on the motor controller? I’m wondering about the following three controllers and encoders.

Talon SRX with CTRE Mag encoder
Falcon 500 with integrated encoder
SparkMax with Neo with integrated encoder

A deeper part of my question is, on the Falcon 500, it has 2048 counts per revolution right? Is it actually counting all the counts in every revolution even at its maximum speed? Essentially what I’m asking is, what is the absolute shortest duration of time over which any of these controllers can internally measure/sense the motor slowing down, and command a higher output to compensate to help maintain the motor speed?

IIRC, the Talon SRX runs at 1kHz.

1 Like

Is this documented somewhere? And what about the other controllers?

Control Loop Timing regarding CTR Controllers: http://www.ctr-electronics.com/downloads/api/cpp/html/classctre_1_1phoenix_1_1motorcontrol_1_1can_1_1_base_motor_controller.html#a57bc034b7d13aecdeed9b6a3399e1722

TalonSRX, VictorSPX, and TalonFX running on the Falcon 500 both default to a 1kHz frequency, or 1ms loop period for their close loop control. This can be configured using the configClosedLoopPeriod method under the API Documentation to go as slow as 64 ms.

If you’re using a remote sensor, you also have to take into account how often the sensor is updated on the CAN bus, which can be changed using the setStatusFramePeriod method.

Regarding your second question, the TalonFX is able to count every one of the 2048 counts while the Falcon 500 is spinning at top speed. SRX maximum decoding speed is documented in its Users Guide, but you’re more likely to run into the Mag Encoders maximum speed of 15,000 RPM, as documented in its Users Guide

To tack on to the above answer:

To accurately track distance, every count must be registered. Usually this is done in an Interrupt Service Routine or via specialized hardware. The max measurable speed should be well above the motor’s speed. However, closed loop control will only read the speed once control loop.

See here: https://phoenix-documentation.readthedocs.io/en/latest/ch16_ClosedLoop.html Their read-the-docs also goes into more detail on what functions are run in what control loops. The default is 1000Hz.

Another important question is how the motor controller measures velocity.

I believe that CTRE counts the number of ticks per time period (although I don’t see this explicitly mentioned in the docs). For this type of measurement, you’ll get the best results with an encoder with a high CPR (as long as that CPR * speed doesn’t exceed the ability of the reading device to process).

Another way is to measure velocity is to measure the time between encoder pulses. For this method, you’ll get the best results with a low CPR encoder (as long as you get at least 1 pulse per measurement period). This is how the WPILib encoder class works.

You didn’t ask, but the fastest the roboRIO can change a PWM output is 200hz.

All good stuff to know, basically what I’m trying to determine is say you have a shooter wheel going 5000 RPM, or in other words the wheel is rotating about once every 12 milliseconds. Let’s say a ball is in contact with the wheel for only 1/4 of a revolution of the wheel. What I want to know is, as the ball is passing through the shooter and in contact with the wheel, how many “times” can the control loop sense the wheel’s speed and do something to adjust it, in attempts to hold the wheel at constant RPM before, during, and after the shot?

The loop on the Falcon runs at 1 kHz (1 ms loop time), so if you have a 1/4 revolution at 12 ms, that means the ball passes through in just 3 ms, or 3 loop iterations. While theoretically this means it could change the output current before the ball exits the shooter, practically speaking, shooters rely on transfer of momentum during the shot itself, so what you should really be looking at is recovery time between shots to get back to a constant RPM. Increasing inertia of the wheel helps a lot with this, as the more inertia it has, each shot ball reduces it by a smaller percentage, so it slows down less. It’s common in these pulse type scenarios for the control loop to overreact, so you’re better having high inertia to get an overall less dynamically variable system.

1 Like