Implement Swerve

[ErikCald]

The recommended tasks involved with programming it yourself are:

• Clone FRC3512's repo onto your machine
• Solve any errors in this repo due to the repo being in 2022 and our robot being a 2023 robot
• Make modifications to Constants.java to match our settings (things like can id's)
• Swap the order of burnFlash() and resetEncodersToAbsolute() in SwerveModule.java (call burnFlash() last)
• Test and get this repo to work on the robot, tune the steer offsets.
• Learn how this repo works then translate it into code on 2023-2706-Fall-Poseidon
• Make modifications to the code to follow merge naming standards and merge's general format for code.

[ErikCald]

Check out the issue #6 where there's a checklist of things to log

[ErikCald]

List of most important tasks:

• Add JavaDocs to all methods in SwerveSubsystem.java and SwerveModule.java
• Publish odometry pose as a DoubleArrayTopic
• Switch drive method to use a ChassisSpeed object as a parameter
• Change SwerveSubsystem into a singleton class
• Remove zeroGyro from SwerveSubsystem
• Create SetHeadingCommand and SetOdometryCommand
• Reduce speed of the wheel based on angle error (talk to Erik and see Advanced Swerve Improvements #24)
• Add the thread sleep before burn flashing (talk to Erik and see Advanced Swerve Improvements #24)
• Wrap sparkmax setting methods in configureSpark method. Import this method statically from the CheckError.java file.
• enable voltage compensation on the sparkmax
• Live update SimpleMotorFeedforward with network tables (Use an object called UpdateSimpleFeedforward which is already in the lib2706 folder of the SwerveBeta2024 branch.
• PoseBuffer (talk to Erik)
• PathPlanner!
• Copy over the ProfiledPidController stuff from last year's code that is currently being used by kiera/samuel (talk to Erik)

Less important goals:

• Switch state optimizing function and use the sparkmax pid wrapping feature
• Live tune swerve module offset with networktables
• Account for coupling ratio (start with just for odometry)
• Account for skew when driving forward and rotating (see Advanced Swerve Improvements #24)
• If robot hasn't moved for 0.3 seconds
• Use a pid to hold the heading stable when commanding no angular velocity
• Add a Command + supporting Subsystem code to lock the wheels in an X pattern

[ErikCald]

• setCANTimeout(150) then after configuring everything set it to 0

[ErikCald]

• Pid wrapping should be 0 to 2pi instead of 0 to 360 because units
• In SwerveModule periodic, only update angleOffset if swerveTuning is true in Config. Also call setDefaultValue(...) on entryAngleOffset.
• Make getYaw() private in SwerveSubsystem. Add a public Rotation2d getHeading() which returns getPose().getRotation()
• Add a getFieldRelativeSpeeds() to SwerveSubsystem which returns ChassisSpeeds.fromRobotRelativeSpeeds(getRobotRelativeSpeeds(), getHeading())
• resetDriveToPose() needs to also account for current velocity (talk to Erik)
• Refactor the code in periodic to check if the robot is moving into a method. Aka move it to a method called isChassisMoving() that returns a boolean. (I think vision could take advantage of this method)
• Make sure to run lastAngle = getAngle() whenever the encoders are synced.
• Switch to using the other version of SwerveDriveKinematics.desaturateWheelSpeeds
• Lock wheels in X will likely be messed up by anti-jitter code. Add a boolean to setDesiredState for disabling anti jitter which can then be used by the X code. Can then do this to make other code work without change:

  public void public void setDesiredState(SwerveModuleState desiredState, boolean isOpenLoop) {
    setDesiredState(desiredState, isOpenLoop, false); // false to not disable the anti-jitter code
  }

[ErikCald]

• mod.periodic() is called in SwerveSubsystem, move it from the isChassisMoving() to the top of the SwerveSubsystem's periodic (because it should only be called once per robot cycle so if someone else calls your isChassisMoving that it would be called an extra time)
• The drive function in SwerveSubsystem should use getHeading() instead of getYaw() (all the other places that getYaw is used are good)
• Make another static command factory method to create a command that drives to a given pose using the driveToPose method (which we can use to test that whole system)
• resetDriveToPose should also reset the pidControlRotation for field relative angular velocity (which we get from getFieldRelativeSpeeds and maybe later we can get it from the gyro instead)

Tasks for later (aka after the initial testing and verification because we have too much untested code right now):

• Put PathPlanner constants and ProfiledPidController constants into config
• Make isChassisMoving method take a parameter for the speed tolerance instead of using a fixed value (so that if vision uses this they could pick a different tolerance potentially)
• Add resetToAbsolute() right before burnFlash() in SwerveModule. We do it automatically if the robot is not moving but would be good to do it once at boot up as a backup.