Improve drive tuning process

[aidnem]

Currently there are a couple huge issues with drive, as it appears in the drive state machine branch:

• No tuning modes for PID
• All gains are taken from TunerConstants, which means that, if we ever have to regenerate tuner constants, we lose all gains

Fixes:

• Duplicate all gains out of TunerConstants and into drivetrainconstants. We can let the gains in tuner constants exist, but they should never be used. TunerConstants should basically only provide us with CAN IDs and module positions. We should also try syncing it with JSON, even if the file ends up huge and ugly, simply to be able to configure different drivebase sizes between the real and test drivebase
• Add tuning modes that let you tune drive and steer PID and feedforwards.

[aidnem]

Here are the changes from shop tonight: it was still quite poorly tuned:

(this max speed is very scary, I don't know if actually using it is a good idea)

[godmar]

May I ask a question for my understanding that is somewhat related to robot testing, but may affect how we structure the code.

When the robot is in test mode, does that mean that the entire robot (all subsystems) are in test mode, or does it mean that only one subsystem is in test mode at a time? When one subsystem is tested, are the others expected to perform as normally (not in test mode?)

The reason I ask is the current structure of TestModeManager which appears to require that each subsystem check if one of its test modes is activated, and then switches into a state that runs testPeriodic. I find this cumbersome. If it were the case that in each test mode only one subsystem is tested, the test mode manager could itself start running this subsystem's testPeriodic (via interface, for instance). Then the subsystem wouldn't have to have a test state, and it wouldn't have to constantly check if test mode is enabled (which under the current system happens even under deployment.)

[aidnem]

When the robot is in test mode, does that mean that the entire robot (all subsystems) are in test mode, or does it mean that only one subsystem is in test mode at a time? When one subsystem is tested, are the others expected to perform as normally (not in test mode?)

It depends on the test mode. Most are "tuning" modes, where we change the behavior of just one subsystem to let us test/tune PID gains, while the other subsystems behave normally.
However, others let us tune more complicated actions, such as linear drive. This will likely mean that drive should behave as normal, except that it will also be reading gains from network tables at the same time.

The final type of mode is when two subsystems can damage each other. This likely won't happen on our robot this year, but last year, our wrist was mounted on an elevator. As such, any wrist tuning mode would also command the elevator to lift up so that the wrist wouldn't crush itself if it went too far down during tuning.

The reason I ask is the current structure of TestModeManager which appears to require that each subsystem check if one of its test modes is activated, and then switches into a state that runs testPeriodic. I find this cumbersome. If it were the case that in each test mode only one subsystem is tested, the test mode manager could itself start running this subsystem's testPeriodic (via interface, for instance). Then the subsystem wouldn't have to have a test state, and it wouldn't have to constantly check if test mode is enabled (which under the current system happens even under deployment.)

This is a valid point. Assuming that TestModeManager is in charge of deciding on which subsystems to run testPeriodic, how would those subsystems know not to run their normal state functions when it was test mode? Normal periodic runs all the time as far as I'm aware, even when the robot is disabled.

[aidnem]

Closed in #25