Move code from Robot.java to Submodule classes

[JonathanLindsey]

This is in part preparation for a move to command based.

For now Joystick code should stay in Robot.java and not get moved to the submodule.

If you want to move the submodule classes to their own folder, that should just be a separate commit in order to keep the commit diffs nice.

[JonathanLindsey]

Here's an incomplete list of some more ways to continue moving things into submodule classes. It's possible something I say doesn't work out. Please keep me posted.

• [ ] Remove commented out code.
• [x] Clear up warnings VS Codes lists in the Problems tab.
• [ ] Move LED code to its own class (further commentary below).
• [ ] Make Drive.driveInit() and Drive.NavXInit() private methods and call them from the Drive constructor method.
• [ ] What subsystem does the SmartDashboard "Target" variable have to do with? Put it in that submodule's class.
• [ ] pickerUpper.grabber.periodicGrabber(); and pickerUpper.arm.updatePosition(); are run in robotPeriodic(). They should be moved to a PickerUpper.periodic() method that gets called by robotPeriodic().
• [ ] The rest of robotPeriodic() is pit safety/pit override and LED code. The LED for loop code for setting the LEDs is repetitive and should be refactored into a method in the Leds class. Pit safety/pit override code should be moved to the Tower class.
• [ ] Create a Pid class and use it all the places where we use PID.

LED class structure

Here's what I'm thinking, let me know if this doesn't make since.

1. Have the Pit Safety state handled in the Tower class.
2. Have a separate Leds class.
3. The Tower class creates an instance of Tower and calls a method of Tower when the lights should change color.

[JonathanLindsey]

Please use the checkboxes above as you commit and push.

[JonathanLindsey]

• [ ] NavX should be its own class. The navX object can be owned by the Drive class.
• [ ] Vision should be its own class - not sure yet if Robot or Drive should own its object.

[JonathanLindsey]

• [ ] Do we need the Grabber.holdAuto() method that sets the grabber to -0.3? Couldn't we use the close() method that sets the grabber to -grabberSpeed (which is currently 0.7)?
• [ ] The Grabber.hold() method that sets the grabber to 0 feels misnamed; relax() would make more sense to me.
• [ ] Grabber.closeCube() isn't used and does nothing so should be deleted.