RobotPy Swerve API change: comment if you care

Technical Python
1

When updating the Swerve documentation on frc-docs, it was noted that the swerve APIs for RobotPy are currently rather inconsistent. Sometimes we take a list/tuple of things:

class SwerveDrive2KinematicsBase
  def toChassisSpeeds(self, wheelSpeeds: tuple[SwerveModuleState, SwerveModuleState]) -> ChassisSpeeds:

And sometimes we take an expanded set of arguments:

class SwerveDrive4Odometry(SwerveDrive4OdometryBase):
  def update(self, arg0: wpimath.geometry._geometry.Rotation2d, arg1: SwerveModulePosition, arg2: SwerveModulePosition, arg3: SwerveModulePosition, arg4: SwerveModulePosition) -> wpimath.geometry._geometry.Pose2d:

I looked at it, and it seems the only real way to make it truly consistent is to change all of the APIs to use a tuple/list when taking N parameters. This will break some team’s existing code.

Technically we could do both overloads, but I think that might be confusing.

What do you think? Make it consistent using tuples or keep it as is?

4 Likes
2

I’m very ok with code getting broken right now, easy enough to make that tweak.

I’d prefer tuples consistently across the board, even if that is inconsistent with java/c++.

2 Likes
3

Tuples plz :slight_smile:

4

PR at Make swerve API more consistent by virtuald · Pull Request #43 · robotpy/mostrobotpy · GitHub

5

This came up during our training last week and the answer I gave was “I have no clue. You do what you do to make things work and you move on with life.”

Tuples would be appreciated.

6

Current docs with the tuple changes are up at WPILib API — mostrobotpy documentation … if you see any other API that seems inconsistent that should be addressed let me know.

… oh, it doesn’t show the documentation for the constructors correctly, I’m aware of that and need to push a fix for it at some point.

7

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.