Configure CAN Frequency

Managing CAN bus bandwidth is crucial as you add more devices to your robot. CAN 2.0 has a finite amount of bandwidth available, and each message takes up space on the bus. At 1Mbps (typical for FRC), you can theoretically transmit about 1000 frames per second under perfect conditions, but you'll want to stay well below this to avoid bus congestion.

One key way to reduce unnecessary traffic is to disable polling for sensors you aren't using. If you're not using the internal encoder, set setSensor to zero. Similarly, if you're not using an external encoder, setQuadSensor should be zero. There's no reason to waste bus bandwidth requesting data from sensors that aren't connected!

Remember that control loops (position and velocity PID) run directly on the motor controller itself at 1kHz - you don't need super fast feedback just for the control to work. However, if other mechanisms on your robot are sequencing based on position or velocity values from this motor, you'll want to set appropriate feedback rates to ensure smooth coordination. Just remember - there's rarely a reason to set any feedback faster than 10ms (100Hz).

Similarly, current limiting runs directly on the motor controller - you don't need frequent current feedback just for the limiting to work. If you're not actively monitoring current draw for debugging or logging, you can set this to a much lower frequency (like 0.2s) or even zero. The controller will still protect your motors, but you'll free up valuable bus bandwidth.

When you're first testing a mechanism, it can be helpful to temporarily increase these frequencies for debugging. But once you've verified everything works, dial those frequencies back down for competition. Think about what data you actually need and when. Position feedback for coordinated mechanisms? Keep that at 100Hz. Fault data? That can probably run at 4Hz or even slower.

Remember that every motor controller on your CAN bus adds up. If you've got six motors each sending five different types of frames, that's 30 potential messages fighting for bandwidth! And that's before counting other devices like the PDP/PDH, pneumatics hub, or other sensors. Being smart about your CAN frequencies isn't just good practice - it can mean the difference between smooth operation and weird timing hiccups in the middle of a match.

Remember: All these values represent the period in seconds between transmissions. Smaller numbers mean more frequent updates but more CAN bus utilization.

The Thrifty Nova provides functionality to modify the frequency at which each of the five categories of CAN frames are transmitted at.

These configurations can be set by accessing the motors canFreq configuration object, and by calling the appropriate method by providing the period, or the time between consecutive transmissions, in seconds.

The following example demonstrates how to modify these values.

motor.canFreq           // Access the canFreq object
    .setFault(.25)      // transmit faults every .25s (250ms) (4hz)
    .setSensor(.01)     // transmit encoder feedback every .01s (10ms) (100hz)
    .setQuadSensor(.01) // same for external encoder feedback
    .setControl(.02)    // transmit control frames every .02s (20ms) (50hz)
    .setCurrent(.20);   // transmit current feedback every .2s (200ms) (5hz)

Specific Frame Configuration Documentation

Set Fault

Set CAN frame frequency for faults.

setFault(double per)

Parameters:

• per The period in seconds.

Set Sensor

Set CAN frame frequency for encoder feedback.

setSensor(double per)

Parameters:

• per The period in seconds.

Set Quad Sensor

Set CAN frame frequency for quadrature encoder feedback.

setQuadSensor(double per)

Parameters:

• per The period in seconds.

Set Control

Set CAN frame frequency for control commands.

setControl(double per)

Parameters:

• per The period in seconds.

Set Current

Set CAN frame frequency for current measurements.

setCurrent(double per)

Parameters:

• per The period in seconds.