Designing Teleop Controls
How to design controls in teleop so that they are functional and intuitive

Driver Controls
Basic Rules 

 These arent absolute rules but you should really think about it when you break them. When in doubt listen to the driver's preference. 

 

 The driver shouldn't be doing more than driving and alligning the robot. Adding more mental load makes it so that the driver cannot focus as much on avoiding collisions and getting the robot around quickly. 

 The Driver should have a camera that allows for good visibility when picking up game objects (Fisheye cameras are really good here) 

 Make boolean conditions--things like is there a game piece in the robot-- a large box that turns green when it is ready or better yet use leds on the robot. 

 If using tankdrive don't use arcade drive, use curvature drive. Curvature drive behaves much better while turning, arcade drive frequently causes oversteer and overall poor handling. 

 If the driver does need to control something other than the drivetrain make their controls simple.

 

 If the system makes sense to toggle(eg. deploying an intake) have one button that sends it out and then retracts it. when released. 

 If the system needs precise manual control, rethink the driver doing it. 

 a command that does something until some goal state is reached should only execute while a button is held. For example, an alignment command should terminate when the robot is aligned or when the driver lets go of the button. 

 

 

 If you need more than one camera use a raspberry pi with the WPILIB image and use network tables or equivalent.(it is possible to do this many ways so keep the idea in mind.) 

 

 Not necessarily programming but still good to consider 

 

 

 Use alignment indicators on the robot as much as possible. For example 2 pieces of orange tape on an elevator or climber can indicate when the robot is in climbing position. 

 Place the camera in a good spot with clear visibility of the intake of the robot.

Operator Controls
General Rules 

 Once again the operators preferences are key but following these rules first will give a good start. 

 

 Any automated command needs to have a way for a manual backup. Adding a button to the controller that switches everything to manual is a good idea. 

 Automate things as much as possible

 

 Even if a sequence is triggered by a button it is better than fully manual control. For example a command that causes the intake to take in something and then move it inside of the robot is better than 2 or more buttons that do the same thing. 

 HAVE A MANUAL BACKUP 

 

 

 Buttons should automatically execute a task

 

 if you need the operator to control something precisely and can't automate it try to make sure they only need to do one thing at a time, otherwise their performance is going to suffer, For example if the operator is climbing and the arms have to be controlled manually do not make them also have to simultaniously operate a scoring mechanism. Figure out something to reduce the load 

 If the operator lets go of the button have it stop the command, unexpected things happen on the field and this can prevent robot damage or penalties. 

 

 

 If a subsystem has a lot of states don't make a button scroll through them. This can be confusing while operating and you frequently can't see the robot. Instead make each state a different button.

 

 for example a robot arm may need to go from the ground to a variety of scoring positions. It may seem like a good idea to bind these to gamepad up and down but if you cannot see clearly what the robot is doing you may force the robot into the wrong state. Having separate buttons solves this.