The Controller as a User Interface
Remotely Controlling the Robot
We most often use remote controls to interact with our televisions. We press buttons that make the television display a channel or information/access screen that we want. Technically, your television's remote control is a UI. However, it is a much less sophisticated UI than the one that your smartphone uses.
Programming your IQ Controller is much more sophisticated. During the Driver Controlled matches of a competition, you want your driver/team to have as many advantages as possible. You can program the buttons and joysticks to do more than one simple behavior, and you can program them to do complex behaviors when buttons/joysticks are used in combination - similar to how some gaming controllers work. As the programmer of your Controller, you consider which buttons to use in combination by figuring out how your fingers and hands would need to be placed in order to reach all of the buttons involved.
The image above shows the project from the Controller Buttons example project from VEXcode IQ. Do you see how the [Forever] loop has two [If then else] blocks nested inside of it? It makes the project check whether the R Up or R Down buttons are pressed, and the robot spins the Claw Motor closed or open based on one being pressed. That [Forever] loop is very important. It makes your IQ Controller check repeatedly on which button(s) is being pressed so that the robot performs the appropriate behavior(s).
Consider that you could put two <Controller Pressed> sensing blocks in an <and> operator block. That would have the project check if two buttons were being pressed. You could also put an <and> block inside of another <and> block and have three conditions being checked before a behavior is carried out. This would let you program sequences of behavior that can be started simply by pressing buttons on your controller.
Consider how many more combinations of conditionals you could create with all of the buttons and their combinations on the Controller. Of course, as you program more complex behaviors into the functioning of the Controller, the project gets closer to having the robot be autonomous. A competition team needs to figure out which are the best behaviors to program into their Controllers as complex sequences and which behaviors are best left decomposed into multiple parts so that the Controller lets the driver (user) have more control over the speed and accuracy of the behavior.
Teacher Tips - Modeling
Model how to combine <and> blocks for students if they have a difficult time imagining combining <and> blocks to include more than one condition. Here is an example:
This example only shows the first command block and a half of the next but there could be an entire sequence of behaviors for the robot to carry out when these three buttons (E Down, F Up, and F Down) are all pressed.
Motivate Discussion
Each year, VEX challenges its users with a new game. Teams compete in matches consisting of a one minute (60 second) Autonomous Period (no Controller), followed by a one minute (60 second) Driver Controlled Period (Controller). Some students may have competed in robotics competitions before either as part of a club or team. The questions below ask students to share their experiences and/or interests in competitions.
Q: Has anyone here, or someone you know, competed in a robotics competition?
A: Encourage the students who have competed to share their experiences. Follow up with more questions, such as, 'what robot did you use?' and/or 'what was your favorite part of the experience?'.
Q: Is anyone interested in learning more about this year’s VEX competition/game?
A: When students respond yes, you can direct them to the VEX Competition website and show the video of this year's challenge.