Recent Updates

  • Updated on: Jan 22, 2013

    Support Resources

    In addition to the documentation here, there are a variety of other resources available to FRC teams to help understand the Control System and software.

  • The Robot Preferences class is used to store values in the flash memory on the cRIO. The values might be for remembering preferences on the robot such as calibration settings for potentiometers, PID values, etc. that you would like to change without having to rebuild the program. The values can be viewed on the SmartDashboard and read and written by the robot program.

  • 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.

  • Updated on: Jan 18, 2013

    Accessing and Using the Javadocs

    One of the primary sources of documentation for the WPILibJ code is the Javadoc documentation generated from specially formatted comments embedded throughout the code. This document will explain what it contained in these documents, how to access them and how to connect them to NetBeans when developing code.

  • A common use case is to have a joystick that should drive some actuators that are part of a subsystem. The problem is that the joystick is created in the OI class and the motors to be controlled are in the subsystem. The idea is to create a command that, when scheduled, reads input from the joystick and calls a method that is created on the subsystem that drives the motors.

    In this example a drive base subsystem is shown that is operated in tank drive using a pair of joysticks.

    Manual RobotBuilder
  • More advanced subsystems will use sensors for feedback to get guaranteed results for operations like setting elevator heights or wrist angles. The PIDSubsystem has a built-in PIDController to automatically set the correct setpoints for these types of mechanisms.

    Manual RobotBuilder
  • Subsystem classes get the mechanisms on your robot moving, but to get it to stop at the right time and sequence through more complex operations you write Commands. Previously in Writing the code for a subsystem in Java we developed the code for the Claw subsystem on a robot to start the claw opening, closing, or to stop moving. Now we will write the code for a command that will actually run the Claw motor for the right time to get the claw to open and close. Our claw example is a very simple mechanism where we run the motor for 1 second to open it or 0.9 seconds to close it.

    Manual RobotBuilder
  • Updated on: Jan 17, 2013

    Writing the code for a subsystem in Java

    Adding code to create an actual working subsystem is very straightforward. For simple subsystems that don't use feedback it turns out to be extremely simple. In this section we will look at an example of a Claw subsystem that operates the motor for some amount of time to open or close a claw on the robot arm.

    Manual RobotBuilder
  • Updated on: Jan 17, 2013

    Setting the default autonomous command

    Since a command is simply one or more actions (behaviors) that the robot performs, it makes sense to describe the autonomous operation of a robot as a command. While it could be a single command, it is more likely going to be a command group (a group of commands that happen together).

    Manual RobotBuilder