Recent Updates

  • Updated on: Jan 02, 2013

    Using Netconsole

    The NetConsole is a way to remotely view the console output of the cRIO from any computer on the same network. This can be used to view debugging output from the cRIO, WPILib libraries, and/or from output statements in the user code (printf in C++, System.out.print in Java or RT Debug String VI in LabVIEW).

    Manual NetConsole
  • Updated on: Jan 02, 2013

    Debugging a Robot Program

    Debugging the robot program is slightly more complex and can't be used during the competition matches, but can be a very helpful technique for troubleshooting issues with a robot program. Debugging allows you to stop, start and step through the execution of a program and view the values of program variables as you do so. To debug an FRC Java program, first the program has to start, and then you must attach the NetBeans debugger to the running program.

  • Updated on: Dec 26, 2012

    Stale data and SmartDashboard

    SmartDashboard uses NetworkTables for communicating values between the robot and the driver station laptop. Network Tables acts as a distributed table of name and value pairs. If a name/value pair is added to either the client (laptop) or server (robot) it is replicated to the other. If a name/value pair is deleted from, say, the robot but the SmartDashboard or TableViewer are still running, then when the robot is restarted, the old values will still appear in the SmartDashboard and TableViewer because they never stopped running and continue to have those values in their tables. When the robot restarts, those old values will be replicated to the robot.

    To ensure that the SmartDashboard and TableViewer are showing exactly the same values, it is necessary to restart all of them at the same time. That way, old values that one is holding won't get replicated to the others.

    This usually isn't a problem if the program isn't constantly changing, but if the program is in development and the set of keys being added to NetworkTables is constantly changing, then it might be necessary to do the restart of everything to accurately see what is current.

  • Updated on: Dec 25, 2012

    SmartDashboard namespace

    SmartDashboard uses NetworkTables to send data between the robot and the Dashboard (Driver Station) computer. NetworkTables sends data as name, value pairs, like a distributed hashtable between the robot and the computer. When a value is changed in one place, its value is automatically updated in the other place. This mechanism and a standard set of name (keys) is how data is displayed on the SmartDashboard.

    There is a hierarchical structure in the name space creating a set of tables and subtables. SmartDashboard data is in the SmartDashboard subtable and LiveWindow data is in the LiveWindow subtable as shown below.

    For informational purposes the names and values can be displayed using the TableViewer application that is installed in the same location as the SmartDashboard. It will display all the NetworkTable keys and values as they are updated.

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

  • Updated on: Dec 24, 2012

    PID Tuning with SmartDashboard

    The PID (Proportional, Integral, Differential) is an algorithm for determining the motor speed based on sensor feedback to reach a setpoint as quickly as possible. For example, a robot with an elevator that moves to a predetermined position should move there as fast as possible then stop without excessive overshoot leading to oscillation. Getting the PID controller to behave this way is called "tuning". The idea is to compute an error value that is the difference between the current value of the mechanismfeedback element and the desired (setpoint) value. In the case of the arm, there might be a potentiometer connected to an analog channel that provides a voltage that is proportional to the position of the arm. The desired value is the voltage that is predetermined for the position the arm should move to, and the current value is the voltage for the actual position of the arm.

  • Updated on: Dec 17, 2012

    PIDSubsystems for built-in PID control

    If a mechanism uses a sensor for feedback then most often a PID controller will be used to control the motor speed or position. Examples of subsystems that might use PID control are: elevators with potentiometers to track the height, shooters with encoders to measure the speed, wrists with potentiometers to measure the joint angle, etc.

    There is a PIDController class built into WPILib, but to simplify its use for command based programs there is a PIDSubsystem. A PIDSubsystem is a normal subsystem with the PIDController built in and exposes the required methods for operation.

  • Often debugging or monitoring the status of a robot envolves writing a number of values to the console and watching them stream by. With SmartDashboard you can put values to a GUI that is automatically constructed based on your program. As values are updated, the corresponding GUI element changes value - there is no need to try to catch numbers streaming by on the screen.

  • Updated on: Dec 12, 2012

    Configuring an Axis Camera

    Three different Axis camera models are supported by the FRC software, the Axis 206, Axis M1011, and Axis M1013. This document provides instructions on how to configure one of these cameras for FRC use. To follow the instructions in this document, an installation of 2014 NI FRC Update is required.

  • Updated on: Dec 07, 2012

    Running the program on the robot

    Once the program is finished and NetBeans is configured the program can be run very easily. There are a few things you should know about running the program immediately after flashing a new image onto the cRIO that are described here.