Robots don't quit

[dystopic]

Hi,

I have been getting the error "robots don't quit" in my code and am confused as to what it means? I have found other people here having the error but could not find a clear reason/solution. I also think that because of this my robot does not drive or allow controls. Help would be appreciated on how to reach a solution. Thanks!

[otherguy]

Most common reason I have seen causing this is code that takes a long time to execute. For example, loops or thread.sleep calls in an iterative robot project are a no go. All code in the periodic methods must be able to complete in 20ms or less (the period at which the periodic methods are called).

If you can share your code, we can probably help out a little better.

[dystopic]

Well our robot isn't iterative it's command based, so what would it mean then? I'll try to post the code as soon as possible.

[fovea1959]

frequently, it's because code threw an Exception. What are the lines on the console preceding the "Robots don't quit"?

[otherguy]

Originally Posted by dystopic

Well our robot isn't iterative it's command based, so what would it mean then? I'll try to post the code as soon as possible.

Command base is just the IterativeRobot class using the Command and Scheduler classes.

Look at your code, the main robot class probably has a line like this...

public class Robot extends IterativeRobot {

Note the "extends IterativeRobot" part.

Same goes for command base as I said before, no loops or thread.sleeps unless you understand the consequences and know it will not affect execution of the rest of the robot code. This is especially true for the code within a command - since the code in a command shares the 20ms execution period with all other active commands.

[dystopic]

Currently I don't have the robot to see and don't remember specifically. I'l try to post that as soon as I can, probably tomorrow night...

[dystopic]

Originally Posted by otherguy

Command base is just the IterativeRobot class using the Command and Scheduler classes.

Look at your code, the main robot class probably has a line like this...

public class Robot extends IterativeRobot {

Note the "extends IterativeRobot" part.

Same goes for command base as I said before, no loops or thread.sleeps unless you understand the consequences and know it will not affect execution of the rest of the robot code. This is especially true for the code within a command - since the code in a command shares the 20ms execution period with all other active commands.

wait so would this be fine:

timer = new Timer();
intake_b.set(true);
timer.start();
while(timer.get() < Constants.solenoid_timing.getDouble()){

}
if(timer.get() >= Constants.solenoid_timing.getDouble()){
intake_b.set(false);
}

the timing value is 2000ms

[otherguy]

wait so would this be fine

No.

If you're using commands, I would suggest the following implementation. Assuming the code you wrote is inside a command.

• Create and start the timer in the initialize method of a command.
• Inside the execute method run the intake
• inside isFinished() have your check to see if you've waited long enough:
  

  return timer.get() >= Constants.solenoid_timing.getDouble()

• inside the end method, stop running the intake

Alternatively, you could create the following commands

• RunIntake - a command which just runs the intake then immediately finishes (isFinished returns true) - leaving the intake running
• Delay command. This is an empty command that does nothing and never finishes. See how it is useful below.
• StopIntake - a command that just stops the intake and immediately finishes (isFinished returns true).

You could then make a command group that looked something like this:

public class RunIntakeThenStop extends CommandGroup {
  public RunIntakeThenStop() {
    addSequential(new RunIntake());
    addSequential(new Delay(), 2.0); //the 2nd parameter is a timeout period in seconds.
    addSequential(new StopIntake());
  }
}

See the javadoc for help using command groups and info on timeout periods for commands.

[RufflesRidge]

The "Robots don't quit" text means your code threw an uncaught exception and crashed.

Post the code and the full text from the output window (the stack trace should point to the issue) and we can be of more help.

[dystopic]

I think I solved the error thanks for your help guys. I had an AnalogAccumulator being initialized on port 5 but it can only be initialized on channels 1 or 2 apparently...

[BradAMiller]

This is the code in the RobotBase base class for Iterative and SimpleRobot. When an exception happens that isn't caught, it goes up the stack frame (from one method to the one that called it) looking for a handler. In RobotBase there is a handler for any uncaught exceptions and it prints "Robots don't quit".

    protected final void startApp() throws MIDletStateChangeException {
        boolean errorOnExit = false;

        Watchdog.getInstance().setExpiration(0.1);
        Watchdog.getInstance().setEnabled(false);
        FRCControl.observeUserProgramStarting();
        UsageReporting.report(UsageReporting.kResourceType_Language, UsageReporting.kLanguage_Java);

        try {
            this.startCompetition();
        } catch (Throwable t) {
            t.printStackTrace();
            errorOnExit = true;
        } finally {
            // startCompetition never returns unless exception occurs....
            System.err.println("WARNING: Robots don't quit!");
            if (errorOnExit) {
                System.err.println("---> The startCompetition() method (or methods called by it) should have handled the exception above.");
            } else {
                System.err.println("---> Unexpected return from startCompetition() method.");
            }
        }
    }