Recent Updates

  • Updated on: Jan 09, 2013

    Simple subsystems

    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.

  • Updated on: Jan 09, 2013

    Operating a compressor for pneumatics

    The Compressor class is designed to operate any FRC supplied compressor on the robot. A Compressor object is constructed with 2 input/output ports:

    • The Digital Relay output port connected to the Spike relay that controls the power to the compressor. (A digital output or Solenoid module port alone doesn’t supply enough current to operate the compressor.)

    • The Digital input port connected to the pressure switch that monitors the accumulator pressure.

    The Compressor class will automatically create a task that runs in the background and twice a second turns the compressor on or off based on the pressure switch value. If the system pressure is above the high set point of the switch, the compressor turns off. If the pressure is below the low set point, the compressor turns on.

  • TableViewer is a program to help debug NetworkTables applications. It acts as a NetworkTables client and allows the viewing of all the keys and associated values in a tabular format. You can use this to quickly see the value of a variable or set a value for a variable. This is a java program making it platform independent - it can run anywhere that the java runtime is installed.

  • Often you will want to run multiple commands, one after another to enable more complex behaviors in your program. Once each of the individual commands have been debugged, you can create a CommandGroup. A CommandGroup is a named set of commands that may be executed sequentially or in parallel.

    Manual RobotBuilder
  • Updated on: Jan 08, 2013

    Getting Started with the SmartDashboard

    The SmartDashboard typically runs on the Driver Station computer and will do two functions:

    1. View robot data that is displayed as program status as your program is running.
    2. View sensor data and operate actuators in Test mode for robot subsystems to verify correct operation.

    The switch between program status and test modes are done on the Driver Station.

  • Updated on: Jan 04, 2013

    Using test mode

    It is important to verify the operation of the robot before using it for a match, demonstration or other task. So often wires can be pulled lose, circuit breakers are left out, or other issues that might cause the robot to not operate as expected. There are a number of strategies for testing your robot code. You might have a checklist where each subsystem is manually verified using the operator controls. You can also test the autonomous operation this way when the robot is off the ground can the operation can be observed.

    Test mode is designed to enable programmers to have a place to put code to verify that all systems on the robot are functioning. In each of the robot program templates there is a place to add test code to the robot. If you use the IterativeRobot template, or use command-based programming you can easily see the operation of all the motors and sensors through the LiveWindow.

  • ScreenStepsLive is a new tool that FRC/WPI are using to create and present documentation. This document is a brief introduction to the ScreenStepsLive site and the documentation contained here.

  • Every sensor, actuator and operator interface component is an object in either C++ or Java programs. To use one of these you must create an instance of it using the class name. Any references to the objects such as reading values, setting values, or setting parameters is done through the reference. There are a number of utility objects in WPILib such as the RobotDrive and Compressor that don't represent a single sensor or actuator, but a larger subsystem.

    Another convention used throughout the library is the case of the method names. In C++ all methods start with an upper case letter, then are camel case (intermediate words capitalized). In Java all methods start with lower case letters then camel case for the remainder of the name.

  • Updated on: Jan 03, 2013

    Using the Classmate with your cRIO

    This document details the basics of connecting your Classmate Computer to a cRIO.