"Output not updated often enough" Error

package edu.wpi.first.wpilibj.templates;

import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.Joystick;
import edu.wpi.first.wpilibj.RobotDrive;
import edu.wpi.first.wpilibj.Relay;
import edu.wpi.first.wpilibj.Jaguar;
import edu.wpi.first.wpilibj.Joystick.AxisType;
import edu.wpi.first.wpilibj.Watchdog;
import edu.wpi.first.wpilibj.Timer;
import java.lang.Math;

public class RobotTemplate extends IterativeRobot {

         RobotDrive drive;

         Joystick leftStick;
         Joystick rightStick;

         // Left and Right Drive Motors
         Jaguar leftMotor1;
	 Jaguar leftMotor2;
         Jaguar rightMotor1;
         Jaguar rightMotor2;
         // Channels for Left and Right mobility motors.
         static final int leftMotorChannel1 = 1;
         static final int leftMotorChannel2 = 2;
         static final int rightMotorChannel1 = 3;
         static final int rightMotorChannel2 = 4;

         // Deadzone Variables
         static final double deadzonePercent = .05;

    public void robotInit() {
         //Initialize Drive Motors
	 leftMotor1=new Jaguar(leftMotorChannel1);
	 leftMotor2=new Jaguar(leftMotorChannel2);
	 rightMotor1=new Jaguar(rightMotorChannel1);
	 rightMotor2=new Jaguar(rightMotorChannel2); 

         drive = new RobotDrive(leftMotor2,leftMotor1,rightMotor2,rightMotor1);
         leftStick = new Joystick(1);
         rightStick = new Joystick(2);

    public void teleopPeriodic() {

    public double deadzone(double joyVal) {
       if (joyVal < deadzonePercent && joyVal > -deadzonePercent)
           return 0;
       else if(joyVal > deadzonePercent)
           return (joyVal/(1-deadzonePercent) - (1/(1-deadzonePercent)*deadzonePercent));
           return (joyVal/(1-deadzonePercent) + (1/(1-deadzonePercent)*deadzonePercent));

We are experiencing this problem. Our motors are running fine, though we continue to get this error, we’re wondering if it’s because iterative robot is checking for output and we are not giving it Joystick output fast enough.

Is there a way we can modify the delay time it requires or is the only option to set setSafteyEnabled to false?

Our team is having the same error. Does anyone have a solution?

We are also seeing this same message. Any suggestions?

First of all create a DriverStationLCD object then to lcd.updateDisplay(); or something like that but when you are going to be running the code not in live debugging, its not going to show any of those messages.

And even though your not printing anything to the driver station they still like it when you update the display…

I have seen the same error. We no longer have the problem for now. Try checking your network settings, firewall is OFF, electronics is plugged in correctly, battery is charged enough, cRIO slots are in standard order.

Try setting your watchdog to enabled and stop feeding it. The problem could be that the watchdog has nothing to feed off of. Tell me if my suggestions have helped or not.

I wish you all of the best of luck and reply if this helped or not.

Happy competition!

Your code looks fine to me, but a few comments:

  • Using Iterative robot, there is no need to intentionally feed the watchdog in your own code, as it is done in the IterativeRobot class.

  • Turning off motor safety is probably not in your team’s best interests.

  • Are you seeing this message once at start of teleop, at a certain point (like after moving the joystick), or constantly?

I experimented with this some more this afternoon and see a good workaround without compromising safety.

Edit WPILIB MotorSafety.java line 15 to be

public static final double DEFAULT_SAFETY_EXPIRATION = 0.5;

And then rebuild the WPILIB project.

The slight increase in time won’t compromise the built in safety. This timeout can cause motor output to pulse, which will increase the motor temperature and you won’t be running at top speeds.

You could also just do setSafetyEnabled to false…

While this is an approach, given that the teams have not yet understood some of the inner workings of WPILIB (I don’t know it all myself either), I don’t think disabling safety code is the right thing to do for these teams.

What makes the RobotDrive potentially dangerous is that under some programming circumstances, the robot can drive uncontrollably from lack of providing new driving instructions. I believe its goal was to help teams avoid recreating the wheel on implementing a tank or arcade drive, but the developers threw in some safety considerations also.