IanSzalai / SuperSwerve

Swerve template project which uses the SuperCORE library
Other
0 stars 1 forks source link

`maxSpeedFPS` preference does not work as intended #8

Closed IanSzalai closed 1 year ago

IanSzalai commented 1 year ago

While using open loop drive, if the maxSpeedFPS preference is changed the behavior is unintended. This issue is a bit complicated, since maxSpeedFPS is used in several places. The root cause of this issue is that the code that uses maxSpeedFPS was not written with the intention that maxSpeedFPS could change, and instead was just a constant that is that maximum physical speed the robot could go. (note: entire robot, not module free speed). Another issue is that it is used for max module speed and max robot speed

I wrote a bunch to try and understand this but im just dumb and its 2:45am Here is every place that `maxSpeedFPS` is used while using `DriveSimple`: `DriveSimple`, used to scale joystick inputs. periodically called `Drivetrain`, used in `desaturateWheelSpeeds`, periodically called `SN_SwerveModule`, used to determine percent output, periodically called Based on this information alone it would seem that changing `maxSpeedFPS` should work as intended. Something is not being accounted for. At a higher level, the way the drive code works is as follows: 1. Joystick inputs are polled, deadzoned, slewed, and scaled in `DriveSimple`. These are packaged in a `Pose2d` object and passed to `subDrivetrain.drive()` 2. `drive()` takes this Pose2d and splits it back up in to it's components and creates a `ChassisSpeeds` object with them. For robot relative driving the new `ChassisSpeeds` object and old `Pose2d` object are basically identical, both containing an x and y translation, and rotation component of the robot. For field relative driving `ChassisSpeeds` does some math and converts these velocities to field relative. 3. Still in `drive()`, the `ChassisSpeeds` object is passed into `SwerveDriveKinematics.toSwerveModuleStates()`, returning an array of `SwerveModuleState`s. This creates 4 states for each swerve module. A state contains a speed and an rotation. This is where the real magic happens, and the joystick inputs are really turned in to commands for the individual motors. These states are then optimized. 4. To end `drive()` each of these states are passed in to their respective `SN_SwerveModule.setDesiredState()` method. Ideally, there is a preference that dictates the maximum speed the robot can travel.

What we need to do is have a constant that is the MODULE's maximum speed, then a preference that is the robot's max translational speed. These can be used in different places and everything should work fine.