Design a command hierarchy for drivetrain commands

[jkleiber]

Summary We currently have an assortment of drivetrain commands with some duplicate functionality. This is mostly due to the rush of build season distracting from good engineering design process. Thus, it would be good for us to figure out a design in pre-season and go through the design exercise now, so we can be in the practice for during build season.

Work to do

• Propose a new set of drivetrain commands that have non-duplicate useful function.
• Do this all in the context of the swerve drive, we can leave the old code how it is for now.

Verification

• Consensus is reached about the new design

FYI: @danielbrownmsm assigned to you for awareness

[danielbrownmsm]

So at a minimum I think we need a Tele-Op drive command and an autonomous drive command. Last year we had:

• drive distance (with an overload for max output)
• drive distance at a given output (seems like basically the same thing)
• turbo mode tele-op (cube inputs, reduce open loop ramp rate, and set max output to 1)
• drive at a given speed for a set time (because something was up with the gyro and encoders so went back to a simple auto)
• slow mode tele-op (divide inputs by 3)
• standard tele-op drive command
• turn to heading auto command

which, especially seeing as I think we’re going to use WPILib’s swerve drive support for pathing and stuff, can probably be reduced to:

• tele-op drive command, with overloads for turbo and slow modes.
• auto drive command, that takes a Translation2D and Rotation2D and then uses WPILib’s stuff to get necessary speeds. Also uses the SwerveOdometry class to figure out if we’re at the setpoint. Probably overloads for max output and open loop ramp rate

[danielbrownmsm]

Also tele-op should have overload for field oriented drive or robot oriented drive