One of the "scarier" parts of developing your robot code is the Autonomous period of the game. During this time, you can't actively control your robot so you need to write code that you trust will do what you'd like. As a result, quite a few teams avoid adding autonomous code to avoid making mistakes. Let's take a walk into those murky waters and see if we can make them a little less intimidating. We'll start with this VI snippet:
Start by dragging this picture onto the Block Diagram of your Autonomous VI. This is a special type of image. The hand dragging the code to LabVIEW, as displayed by the beautiful arrow in the upper left corner, means this is a "snippet." Snippets are designed to take the code you see in the picture and add it to your Block Diagram for you. Once the code is in your Block Diagram, let's explore it first at a high level and then break it apart so we can get a full understanding of what the code is doing.
At a high level, we get the reference for our drive motors, turn left for a second, sit still for half a second, drive straight for a second, and then turn right for a second. Let's start by saying this is a pretty silly autonomous sequence. You'll definitely want to adapt this to suit the game being played and your team's strategy. You'll see the code for each step is pretty similar. The only difference is in the speeds we feed into the drive VI and the value we wire into the Count Terminal (the N in the upper left corner). Everything else remains the same.
The first question you likely have is "Why do I wait for 50ms twenty times instead of 1000ms one time?" The 2011 FRC season introduced Safety Config VIs to make your robot a bit safer. When the safety feature is enabled, motors require continuous input or they turn off. If your code becomes unresponsive, this ensures your robot will stop running rather than wildly run all over the field. This is safer for the human players, the field elements, and your robot. This impacts RobotDrive, MotorControl, PWM, Relay, and Solenoids. Typically, you need to update within 100ms. By using 50ms, we're accomplishing two things. We're obviously giving the motor values more frequently than 100ms. We're also giving ourselves a bit more control over how long things happen. We can make things happen for as little as 50ms instead of being forced to take at least 100ms for every action. With only 15 seconds to work, it can be very helpful to move the motors a little faster and work in less time. You'll want to tweak the wait time to fit your specific autonomous strategy.
Now, let's look at each loop. We can tell the duration the loop will run by solving the equation: wait time (in ms) * desired iterations. We get the wait time from the constant wired into the Wait (ms) function and the desired iterations by looking at the Count Terminal. In most of these cases, we see 50*20=1000ms, or one second. In one case, we see 50*10=500ms, or half a second. This is how we control the timing of each step. Inside the step, we provide desired left and right motor control values. This lets us determine which direction the robot will travel during the loop. You'll want to spend some time testing your robot to make sure all of the values work for your desired path. But, we now have control over how long each step takes and which direction the robot will move in each step. To get the basic autonomous points in many games, you can remove the first and last step. You'll wait for half a second and move forward at half speed for one second. Could you set up your robot in a way that will allow this to get you across the base line? If so, you've already found a way to use this code to improve your autonomous performance.
Have a blast at your competition.