Subsystems are the parts of your robot that are independently controller like collectors, shooters, drive bases, elevators, arms, wrists, grippers, etc. Each subsystem is coded as an instance of the Subsystem class. Subsystems should have methods that define the operation of the actuators and sensors but not more complex behavior that happens over time.

NetworkTables is an implementation of a distributed "dictionary". That is named values are created either on the robot, driver station, or potentially an attached coprocessor, and the values are automatically distributed to all the other participants. For example, a driver station laptop might receive camera images over the network, perform some vision processing algorithm, and come up with some values to sent back to the robot. The values might be an X, Y, and Distance. By writing these results to NetworkTable values called "X", "Y", and "Distance" they can be read by the robot shortly after being written. Then the robot can act upon them.

NetworkTables can be used by programs on the robot in either C++, Java or LabVIEW and is built into each version of WPILib.

Without feedback the robot is limited to using timing to determine if it's gone far enough, turned enough, or is going fast enough. And for mechanisms, without feedback it's almost impossible to get arms at the right angle, elevators at the right height, or shooters to the right speed. There are a number of ways of getting these mechanisms to operate in a predictable way. The most common is using PID (Proportional, Integral, and Differential) control. The basic idea is that you have a sensor like a potentiometer or encoder that can measure the variable you're trying to control with a motor. In the case of an arm you might want to control the angle - so you use a potentiometer to measure the angle. The potentiometer is an analog device, it returns a voltage that is proportional to the shaft angle of the arm.

To move the arm to a preset position, say for scoring, you predetermine what the potentiometer voltage should be at that preset point, then read the arms current angle (voltage). The different between the current value and the desired value represents how far the arm needs to move and is called the error. The idea is to run the motor in a direction that reduces the error, either clockwise or counterclockwise. And the amount of error (distance from your setpoint) determines how fast the arm should move. As it gets closer to the setpoint, it slows down and finally stops moving when the error is near zero.

The WPILib PIDController class is designed to accept the sensor values and output motor values. Then given a setpoint, it generates a motor speed that is appropriate for its calculated error value.

There are two ways of declaring an object variable: either as an instance of the object or a pointer to an instance of the object. In the former case the variable holds the object and the object is created (“instantiated”) at the same time. In the latter case the variable only has space to hold the address of the object. It takes another step to create the object instance using the new operator and assign its address to the variable.

Using the C++ IDE there are two ways to load programs onto the cRIO

• "Deploy" it onto the cRIO flash and run it on a reboot. This will keep the program in the cRIO's persistent memory and will load it each time the device reboots, but will not allow any of the debugging discussed above. This method is covered in this article
• Attach to the cRIO and run the program using the debugger from your development system directly to the cRIO memory. This method will allow you to set breakpoints, step through code, view variable values and perform other debugging operations, however the code will not persist when the cRIO is rebooted. When the cRIO reboots, no code will be running! This method is covered in the next article, "Debugging a Robot Program".

For tournaments you should always Deploy the program so that it will be there when the robot is restarted and the match is played.