Debug and tune smooth driving code for teleop

[dawilson9]

Continue work on the driving code we were working on during the off-season to ensure that we can drive the new robot smoothly during teleop.

-- Owen G. --

TODO:

• Switch all inputs and outputs to meters/second
• Plot inputs and outputs
• Test left and right motors

[dmkorten]

To do on Friday:

• Switch all inputs and outputs to meters/second
• Plot inputs and outputs
• Test left and right motors

[Capyblapy]

I'm going to start looking at the units for the code today before the meeting. The issue I foresee is us converting the controller input of -1 --> 1 to M/S. To fix this we could have two set functions, one based off a decimal % (-1.0 --> 1.0) and one based off of MPS.

This will require us to move the smartdashboard update's but thats pretty easy if we follow what we did in previous years.

[Capyblapy]

I have read the code and these are the units that we are currently using:

A -1 --> 1 decimal percentage representing the % of max speed: Sourced from the controller

Meters Per Second (MPS): The speed the robot is going in meters per second, only used on outputs from what I can tell. Although it is claimed to be used in "setDifferentialSpeeds" but it only takes a -1 --> 1 decimal float.

Rotations Per Second (RPS): The unit that the motors actually take and output with the velocity control.

Im going to splitting the "SetDifferentialSpeeds" function into "setDifferentialSpeeds_Percentage" and "setDifferentialSpeeds_MPS".
I am also going to be adding two convertsion functions that convert MPS to RPS and RPS to MPS.

[dawilson9]

I'm a bit concerned that this is getting over-complicated. As a general rule of thumb, never offer multiple different ways to do the same thing. Have one setDifferentialSpeeds function and document the expected input units then add other methods as needed to convert from original units (say the joystick raw values) to whichever units are needed in the drivetrain. This is a documentation and consistency problem as much as anything else. If we're not consistent with our units, things go badly wrong (as we've seen from the SysID tuning parameters which are obviously very out-of-whack because, I suspect, we didn't define all units before taking the measurements and the code wasn't consistent).

In the context of a drivetrain and drive subsystem, the following are important:

1. Velocity - should be m/s throughout our code. Convert at the bottom before calling any function that requires some other units (for example rotations per second for the Talon velocity controller if we don't find a way to apply a scaling factor automatically in the CTRE code).
2. Direction - which axis points forward?
3. Rotation - degrees or radians? Which rotation direction causes the rotation angle increase?
4. Distance - should be metres throughout.

[Capyblapy]

This is already done, I misread part of the code and started to overcomplicate it. Below is a comment I was about to post when you sent this:

Nvm on the -1 --> 1 percentage decimal thing, I did not notice that the controller drive command scales it to a max MPS before setting it. The reason that it was putting -1 --> 1 is because the value is scales off of is set to 1.0.