Unify gamepad and sensor control into two seperate super classes

[climathosphere]

After looking at the drive and arm processes, it came to my mind that the ArmProcess and the DriveProcess can extend from a super class because they use similar functions and subscription keys. For good object-oriented programming practice, it makes alot more sense to create a super class for a group of classes that share functionality.

For example, since the DriveProcess and the ArmProcess share functionality they can both inherit the similar functionality from a super class (something like a "JoystickProcess" class that extends the RoverProcess class). The JoystickProcess class can then handle the similar functionality universally of all of its subclasses and then the subclasses can deal with all the methods that can only be distinctly invoked for their own specified processes.

[ottopasuuna]

This is definately a possbility, the DrillProcess would benefit from this as well. The only reason I'm a little bit hesitant, is that all three modules end up using the joysticks in slightly different ways, for example the arm might use joysticks to control motor position, the drive process will select between rpm and current control, and braking, the arm might use two axes (the triggers) instead of one to turn a positive/negative direction, etc. The way I'm envisioning the code right now, we would end up overriding every method of the super class anyway, negating the benefits of the common parent class.

That being said, you might have better ideas of how to structure this change to avoid the problem I listed above.

My proposal is to keep things the way they are for the month of Feburary to make sure everything works for the critical design review. After that, we can refactor the Drive, Arm and Drill processes to take advantage of a common super class.