For more information, see: http://wpilib.screenstepslive.com/s/3120/m/7912/l/79730-using-the-motor-safety-feature

In RobotMap.java, enable safety and set safety timeout to 0.1 secs for both motors (similar to our drive train motors.) Watch for the auto generated code blocks for our custom code.

Validate that driver station's test mode can be used to calibrate talon motor controller. Note, instead of using the joystick, test mode's motor controls would be used.

From the manual: http://www.crosstheroadelectronics.com/Talon_User_Manual_1_1.pdf
6) Calibration
The calibration procedure takes the minimum, maximum and center values of the PWM input signal and scales the output based on these values. Calibrating the Talon will allow full range of control with PWM signals that are not within the default range. Calibrating will also correct any non-center issues with input devices such as gamepads or joysticks.
To calibrate the Talon:

1. Press and hold the button labeled “CAL” with a paper clip. The LED should begin to blink red/green.
2. Continue to keep the button pressed while moving the joystick full forward and full reverse. You may do this as many times as you like.
3. Center the joystick and then release the CAL button.
4. If calibration was successful, the LED will blink green several
   times. If the LED blinks red several times, the calibration was not valid. If this happens, the Talon will use the last valid calibration values.
   All calibration values are retained after power cycle or reset.

Identify the requirements, design and code autonomous robot functionality.

Brainstorm and list driver controls and map to specific joystick buttons/movements.

Looks like we have issues accessing our static members correctly, which are declared in Harvester.java but used in HarvesterWheelsBack and HarvesterWheelsForward and few other places as well.

public static final int INTAKE = 1;
public static final int EXPEL = 2;

// code below refers to the harvester instance of static member - generates warning Robot.harvester.setWheelSpeed(Robot.harvester.getHarvesterSpeed(Robot.harvester.INTAKE));

// code should be referring to the class static member

import org.usfirst.frc4915.ArcadeDriveRobot.subsystems.Harvester; Robot.harvester.setWheelSpeed(Robot.harvester.getHarvesterSpeed(Harvester.INTAKE));

Coding Practices -- Done
IP listings -- Done
Robot builder information -- Done

Need higher precision possibly by varying the speed of the turn.

RetractGearboxPneumatics and LoosenGearboxPneumatics.java do not have current functionality in their execute methods. Will want to change around how the commands work.

We must check to make sure that the harvester is fully extended with the latest magnetic switch and the launcher is cocked back before loosening the gearbox and firing the launcher w/ ball.

It will be good to have a permanent link to the cRIO's debug outputs. Lets use the backup classmate for this. I would like to see this done first thing in the morning (2/17) as we are setting up our system.

See: http://wpilib.screenstepslive.com/s/3120/m/8851/l/79731-using-netconsole

If there is no gyro, 180 turn will not work. Driver should be notified via the driver station messages to know they should be doing manual turn instead.

Joystick neutral position applies power to motors, causing them to hum and waste power.

We need to breakdown how we will make the winding motor work with our limit switch, running it until the limit switch returns a true value (launcher is fully cocked back) and then kill the motors.

Code in DriveStraight.java includes a (short) delay in execute(). This seems unnecessary.

protected void execute() {
    double angle = Robot.gyroscope.getAngle(); // get current heading
    Robot.driveTrain.drive(1.0, (angle) * (KP)); // drive towards heading 0
    Timer.delay(0.004);
}

The delay is for 4ms. Note that execute() is called by the scheduler every 20ms, so there is already a 20ms delay between iterations.

If the issue is jitter in the gyroscope reading, it may be better to average the angle over a series of execute() calls, or maybe implement a PID.

At the very least, I'd remove the Timer.delay() call from the code...