Unify Spark motor & encoder classes

[kevinsbarnard]

Hello,

REV significantly refactored REVLib for their 2025 release. To make use of their abstractions, and to help keep the code DRY, this PR unifies the SparkMax/SparkFlex swerve motor & encoder classes under shared parent classes.

swervelib.motors

• SparkSwerve was implemented to use the abstract com.revrobotics.spark.SparkBase and com.revrobotics.spark.config.SparkBaseConfig.
• SparkMaxSwerve and SparkFlexSwerve are now simple helper subclasses that facilitate construction.
• SparkMaxBrushedMotorSwerve was not refactored and remains a direct subclass of SwerveAbsoluteEncoder.

swervelib.encoders

• SparkEncoderSwerve replaces the mostly-duplicate SparkMaxEncoderSwerve and SparkFlexEncoderSwerve classes.
• SparkAnalogEncoderSwerve replaces SparkMaxAnalogEncoderSwerve to work with a generic SparkSwerve. This enables having a Spark Flex with an absolute encoder attached to the analog pin, which is so far unsupported in YAGSL.

swervelib.json.DeviceJson

• Aliases for SparkEncoderSwerve:
  • integrated
  • attached
  • canandmag
  • canandcoder
  • sparkflex_integrated
  • sparkflex_attached
  • sparkflex_canandmag
  • sparkflex_canandcoder
• Aliases for SparkAnalogEncoderSwerve with 3.3V:
  • sparkmax_analog
  • sparkflex_analog
  • spark_analog
• Aliases for SparkAnalogEncoderSwerve with 5V:
  • sparkmax_analog5v
  • sparkflex_analog5v
  • spark_analog5v

Feel free to use any or all of this. These changes still need testing, which Team 5171 will be doing in the coming days.

---

Migrated from BroncBotz3481/YAGSL-Lib#14

[thenetworkgrinch]

The can frames need updated when you use setAbsoluteEncoder or else telemetry will fail. I need some more information on what was removed bc it was type specific. This includes spark specific can frames BECAUSE we do not want to flood the CANBUS any more than we have too

[thenetworkgrinch]

Incomplete, needs can frame optimizations and enabling here.

[thenetworkgrinch]

Incomplete, needs can frame optimizations and enabling here.

[thenetworkgrinch]

I am conflicted on this bc it breaks the pattern we have setup and would require following the same pattern for the TalonFX at the same time. At the same time i do love deduplicating the code.

Could you do the same with the TalonFX and TalonFXS?

[kevinsbarnard]

I need some more information on what was removed bc it was type specific.

I'm not sure what you mean here. The SparkSwerve.setAbsoluteEncoder method is identical to what's in dev currently (SparkMaxSwerve.setAbsoluteEncoder, SparkFlexSwerve.setAbsoluteEncoder); I didn't remove anything on that front. It also appears practically unchanged from what's released in YAGSL 2025.1.2 (SparkMaxSwerve.setAbsoluteEncoder, SparkFlexSwerve.setAbsoluteEncoder), the only differences being the use of Optional for the absoluteEncoder property and the removal of the DriverStation.reportWarning call.

If there are outstanding problems with the CAN bus utilization, perhaps we can address that as a followup issue.

[kevinsbarnard]

I am conflicted on this bc it breaks the pattern we have setup and would require following the same pattern for the TalonFX at the same time. At the same time i do love deduplicating the code.

I hear you. Originally, I dove into this because of what I mentioned before (lacking support for using an external analog encoder with a Spark Flex), but realized there's nothing but abstraction stopping the use of the existing SparkAnalogEncoderSwerve class for this, prompting the refactor.

Could you do the same with the TalonFX and TalonFXS?

Sure, I'll take a look!

[kevinsbarnard]

Re: TalonFX/TalonFXS

Phoenix6 doesn't offer useful abstraction around the motor controller & configuration classes (short of the CommonTalon interface), so I think leaving them as-is is the best option to avoid writing those abstractions for them.