Ethan's ideas for making simple, concise, yet effective, Drive commands

[edf42001]

Drive code is suuuuper important. I feel strongly about drive code because I have memories from my team, where our joystick was too sensitive, and it took us 10s to pick up a game piece instead of 2s.

Sorry for the long post, I wanted to get it into writing in case we have two groups and I am helping the motion profiling elevator group, for example.

I think following the reset and start from scratch approach is best. Also, let's make both arcadedrive and curvaturedrive beautiful and neat and clean, so it is easy to make a perfect drive code.

P.S. Read through all these points fully before doing anything, because sometimes something I say is wrong and it's important to find that out first.

ArcadeDrive:

• Following the reset idea, let's delete

  • https://github.com/frc2399/2023-Season/blob/9768d68738c5f396d168504ef74129fb92395c1d/src/main/java/frc/robot/commands/drivetrain/ArcadeDriveCmd.java#L22
  • https://github.com/frc2399/2023-Season/blob/9768d68738c5f396d168504ef74129fb92395c1d/src/main/java/frc/robot/commands/drivetrain/ArcadeDriveCmd.java#L64-L65
  • The SmartDashboard.putNumbers? I don't know if anyone has used them? If you delete them all, you can put back only the ones you need/want.
  • And the now-unused Constants in Drive Constants, and anything else not being used

• Create a utility function for deadband. Maybe in our util folder? Then you can replace all of deadband if statements. The method would take in a value x and a deadband, and return 0 if the value is in the deadband zone, otherwise, just return x. https://github.com/frc2399/2023-Season/blob/9768d68738c5f396d168504ef74129fb92395c1d/src/main/java/frc/robot/commands/drivetrain/ArcadeDriveCmd.java#L49-L51

• Maybe remove the isSlow assignment from the end() function? It might conflict with the next idea, which is to

• SmartDashboard.put?() can be used to put Commands onto shuffleboard, which you can run. So, if you put the ArcadeDrive command and the CurvatureDrive command onto shuffleboard, you can switch between them for testing.

• Something to consider is if we want a slew rate on turn, and if the slew rate on drive is a good value: https://github.com/frc2399/2023-Season/blob/9768d68738c5f396d168504ef74129fb92395c1d/src/main/java/frc/robot/commands/drivetrain/ArcadeDriveCmd.java#L23-L24

CurvatureDrive

• Is currently on a new branch, should merge that in before it diverges too much: https://github.com/frc2399/2023-Season/tree/curvature-drive-update. I see there are other changes on this branch, we probably just want the changes in CurvatureDrive. It might even be easier to just copy the code from github and paste it into a new branch.
• Check out the Debouncer for the quickTurn timing problem https://docs.wpilib.org/en/stable/docs/software/advanced-controls/filters/debouncer.html. P.S. I think it would be fine to not have any timing at all to start with and see how it works.

That'll be good to start with. Here are some other things to do in the future:

• Square, or cube, speed inputs, to give more control over lower speeds. Maybe same for turning.
• Multiple turn speed by a constant in quickturn. Turning is real fast when it's in place, but that's when you need the most accurate turning, as that's usually when you're lining up with something. (like this: https://github.com/Team254/FRC-2019-Public/blob/576b25d15cb51aebbc73d0b95b49d762bb96ebe1/src/main/java/com/team254/lib/util/CheesyDriveHelper.java#L110)
• Static friction compensation: Rescale and raise the input, so that at low joystick values the robot can overcome friction. For example, x- -> (0.95*x + 0.05)