`SwerveModule` shouldn't replace torque current limits with slip current

[jonahsnider]

We're huge fans of the swerve builder API, and have really enjoyed how quickly we are able to get robots working using the robust driving features it provides. Unfortunately, we've recently experienced one pain point related to how current limits are configured for drive motors. Specifically, the SwerveModule class from the swerve builder API contains the following code in the constructor:

TalonFXConfiguration driveConfigs = constants.DriveMotorInitialConfigs;
driveConfigs.MotorOutput.NeutralMode = NeutralModeValue.Brake;

driveConfigs.Slot0 = constants.DriveMotorGains;
driveConfigs.TorqueCurrent.PeakForwardTorqueCurrent = constants.SlipCurrent;
driveConfigs.TorqueCurrent.PeakReverseTorqueCurrent = -constants.SlipCurrent;
driveConfigs.CurrentLimits.StatorCurrentLimit = constants.SlipCurrent;
driveConfigs.CurrentLimits.StatorCurrentLimitEnable = true;

This reads the configured slip current, and overwrites the configured torque current limits & the configured stator current limit with it.

After observing unusual current draw from the swerve subsystem, we took a closer look and realized the current limits we'd been setting with the drive motor initial configs were being overwritten. This behavior seems confusing, since I'd expect that the current limits we provide to the initial configs would be used, or take precedence over the slip current number (which seems to be documented a value only relevant for configuring odometry, with no effect on motor output).

Would it be possible to remove the code which overwrites configured current limits with the slip current value? Or maybe some way to opt into this behavior only when no other current limits are provided?

As a workaround we've started applying the CurrentLimitsConfigs and TorqueCurrentConfigs separately, after the SwerveModule class has done its init code, but it'd be great if the Phoenix Framework made it simpler than that.

Thanks,
Jonah
Team 581 coach

[CoryNessCTR]

Just to explain why the behavior is the way it is right now, the initial 2024 API release didn't have the initial drive/steer configs in the swerve constants, but it did have the SlipCurrent config. When we added the initial configs, we didn't want to back-break existing code, so the SlipCurrent took priority over the initial configs, which we have documented in the API documentation
https://api.ctr-electronics.com/phoenix6/release/java/com/ctre/phoenix6/mechanisms/swerve/SwerveModuleConstants.html#DriveMotorInitialConfigs

This doesn't mean the behavior has to be this way in 2025, however.
But, we want to keep items like SlipCurrent explicit in the constants, to let the user know that it's a setting they should be aware of and potentially change as it's very relevant to their swerve performance (compared to something like DutyCycleConfigs where it has basically no impact or VoltageConfigs which have an impact but is reduced with defaults making sense).
We could wrap Slip Current into an optional, but I worry that wouldn't fix your initial problem because we'd still want to set it to a default value, so you'd need to know to remove the config.

Is there a reason why you're overriding the slip current with your own torquecurrent/currentlimit values instead of just setting the slip current?
If you use the Slip Current config I think that removes your need for the workaround, and if you want to set supply current limits you can do so with the initial configs.

[jonahsnider]

Is there a reason why you're overriding the slip current with your own torquecurrent/currentlimit values instead of just setting the slip current?

We use torque current FOC output during auto/closed loop, and voltage FOC during teleop/open loop. This lets us use the torque current limits as auto-specific current limits, which we configure to be looser than the teleop current limits. This lets us get higher drive performance during auto, but use stricter current limits in teleop to avoid brownouts.

So for us, the root issue is that just using slip current to configure both current limits together doesn't let us achieve that level of precise configuration.

We could wrap Slip Current into an optional, but I worry that wouldn't fix your initial problem because we'd still want to set it to a default value, so you'd need to know to remove the config.

All the reasoning around wanting to avoid changing the API for configuring the slip current makes sense. IMO the best option is to look at the provided initial motor configs, and if the values provided aren't the defaults (ex. 800A for torque current limit), then use those instead of the slip current value.

This lets users continue to rely on the swerve builder API to configure everything necessary to get a robot driving, but gives power users the ability to override default behavior/configuration with their own values.

[bhall-ctre]

Something to note, with the release of our 2025 beta API, all current limits now apply in TorqueCurrentFOC control: https://v6.docs.ctr-electronics.com/en/latest/docs/yearly-changes/yearly-changelog.html#current-limiting-improvements. So setting different peak forward/reverse limits and stator current limits now only makes a difference if the peak forward/reverse limits are lower than your stator current limit.

At the same time, as is mentioned in that link, our supply current limiter has been significantly improved to prevent brownouts. So we recommend using the stator current limit to prevent wheel slip (using our slip current field) and configuring supply current limits to further prevent brownout. Note that both supply and stator current limit are now enabled with reasonable defaults (tuned for swerve drive motors).