Breaking loops when switching to tele-op?

[Skammerman0]

Our drivers are worried about the robot getting stuck in a while loop during autonomous, rendering the robot completely unusable for the rest of the match.
Do loops automatically break when the robot is automatically switched to tele-op or is this a legitimate concern? Thanks!

[virtuald]

Originally Posted by Skammerman0

Our drivers are worried about the robot getting stuck in a while loop during autonomous, rendering the robot completely unusable for the rest of the match.
Do loops automatically break when the robot is automatically switched to tele-op or is this a legitimate concern? Thanks!

Your drivers have a legitimate concern. Never use while loops in autonomous, there are better approaches (search the forums, this comes up a lot).

[Greg McKaskle]

You don't mention what language you are using. LabVIEW aborts the autonomous when the period ends. It will break out of loops.

I don't believe the other language frameworks do that.

Greg McKaskle

[elijah1111]

What you could do is look for the Tele start signal in your loop and if it sees it break.

[ollien]

Originally Posted by Greg McKaskle

You don't mention what language you are using. LabVIEW aborts the autonomous when the period ends. It will break out of loops.

I don't believe the other language frameworks do that.

Greg McKaskle

Java does not. The "SampleRobot" base class has the following while loop in its autonomous function, which is only called once.

while(isOperatorControl() && isEnabled()) {

Once teleop starts, this while loop breaks because of the condition of the loop. I HIGHLY recommend using an iterative robot instead of SampleRobot. It handles this nonsense for you.

You can test out if your code breaks by using the "practice" mode in driver station.


As a rule of thumb: while trues are a sin 'round these parts.

[Joe Ross]

Originally Posted by ollien

I HIGHLY recommend using an iterative robot instead of SampleRobot. It handles this nonsense for you.

Iterative robot does not break out of loops for you. Rather it moves the loop into the framework. If you have your own loop in iterative, you'll have the same problem as sample.

[Jaci]

I'm going to assume you're using IterativeRobot, since SampleRobot (or implementations of RobotBase) should really only be used if you're 100% certain you know what you're doing.

You'll notice IterativeRobot has both Init and Periodic functions for Robot, Autonomous, Teleop, Test and Disabled (e.g. AutonomousPeriodic, TeleopPeriodic, RobotInit, etc). The Init functions are called when you enter that mode, and the Periodic functions are called on a regular basis. You can think of the Periodic functions as being inside of the loop, and the Init functions above the loop.

The robot main loop follows a process to ensure you don't end up 'locking up' the program in the loop. It goes like this:

Check state (from driverstation) -> If different from the last, call <state>Init -> Call <state>Periodic -> Repeat

During each iteration, the state is checked, and the appropriate periodic function is called. Because of this, it's important not to lock up the Periodic functions (e.g. don't put in your own loops unless they have a set number of iterations, such as iterating over motors).

"But how can I do motor.set(val); sleep(3); motor.set(0)?"
This is fairly simple. Instead of putting a sleep in the periodic function, check if that time has elapsed. Something like this:

void AutonomousInit() {
   start_time = now();
}
void AutonomousPeriodic() {
   if (now() - start_time < 3) {
      motor.Set(val);
   } else {
      motor.Set(0);
   }
}

This allows you to do time-based functions using the periodic functions. I wouldn't recommend coding these time checks yourself, though. WPILib provides the Command-Based programming system that abstracts this for you, and allows you to code Commands for a discrete action (e.g. DriveForward, LiftArm, etc). I suggest doing some reading on that if you're looking to do autonomous.

[Oblarg]

Originally Posted by Jaci

I'm going to assume you're using IterativeRobot, since SampleRobot (or implementations of RobotBase) should really only be used if you're 100% certain you know what you're doing.

You'll notice IterativeRobot has both Init and Periodic functions for Robot, Autonomous, Teleop, Test and Disabled (e.g. AutonomousPeriodic, TeleopPeriodic, RobotInit, etc). The Init functions are called when you enter that mode, and the Periodic functions are called on a regular basis. You can think of the Periodic functions as being inside of the loop, and the Init functions above the loop.

The robot main loop follows a process to ensure you don't end up 'locking up' the program in the loop. It goes like this:

Check state (from driverstation) -> If different from the last, call <state>Init -> Call <state>Periodic -> Repeat

During each iteration, the state is checked, and the appropriate periodic function is called. Because of this, it's important not to lock up the Periodic functions (e.g. don't put in your own loops unless they have a set number of iterations, such as iterating over motors).

"But how can I do motor.set(val); sleep(3); motor.set(0)?"
This is fairly simple. Instead of putting a sleep in the periodic function, check if that time has elapsed. Something like this:

void AutonomousInit() {
   start_time = now();
}
void AutonomousPeriodic() {
   if (now() - start_time < 3) {
      motor.Set(val);
   } else {
      motor.Set(0);
   }
}

This allows you to do time-based functions using the periodic functions. I wouldn't recommend coding these time checks yourself, though. WPILib provides the Command-Based programming system that abstracts this for you, and allows you to code Commands for a discrete action (e.g. DriveForward, LiftArm, etc). I suggest doing some reading on that if you're looking to do autonomous.

Note that if you do decide to do the time checks yourself, always compare a difference of time stamps against a value (as is done in the above example). Never directly compare two timestamps (e.g. "now < start_time + 3"). The former is robust to clock overflow. The latter is not.

[ollien]

Originally Posted by Joe Ross

Iterative robot does not break out of loops for you. Rather it moves the loop into the framework. If you have your own loop in iterative, you'll have the same problem as sample.

I know. I'm stating that the problem that any fear of a problem that SampleRobot presents with their while loops can be solved with IterativeRobot.

[Skammerman0]

Just tested with practice mode (thanks for the idea). Can confirm that it gets stuck for the rest of teleop.

[BitTwiddler]

Originally Posted by Greg McKaskle

You don't mention what language you are using. LabVIEW aborts the autonomous when the period ends. It will break out of loops.

I don't believe the other language frameworks do that.

Greg McKaskle

We use LabView. Last year we got stuck in a control loop for Autonomous during an entire match. The problem code was a while loop running in Timed Tasks that never completed its task. If the while loops are executing within the Autonomous VI you should be safe but beware of loops running in Timed Tasks because that VI is running in Teleop as well as Autonomous.