Benefits of "Periodic Tasks VI"?

What are the benefits of running while loops and all in the Periodic Tasks VI rather than Teleop? Does it help the code run faster? Do you run things in Periodic Tasks just like you would in Teleop? Any kind of summary to the pros, cons, and operation of Periodic Tasks would be very much appreciated!

TeleOp is called every 20ms in response to a message from the DS. Your code will not process messages from the driver station and field management system until the code returns. So, if you want to start a motor, wait while it cranks for 250ms, and then release a solenoid, that means it will stall out the normal execution of the code that allows the driver to control the robot. It will execute with the last motor command, and then if the watchdog or safety mechanisms are enabled, the motor will probably shut down because your code is not sending updates.

By comparison, Periodic tasks run in parallel. The loops initially share data with TeleOp via globals, but are not otherwise intertwined. The do not hold up teleop, and they do not wait for a message to arrive. They are a great place to have code that waits for sensors or timers and triggers because of a driver action or environmental action.

Does that help?

Greg McKaskle

In our teams code the bulk of our code is in Periodic However in our code I’m having the robot read a digital input and a global data so we have a couple different ways of controlling the robot. Could this be causing our -44601 error? I can actually notice a significant lag (like half a second) between a joystick movement and the robot movement and it’s somewhat annoying while we’re testing. I even tried having both periodic tasks and vision disabled and the error remained…

I can’t give an example in LabVIEW because I don’t have it installed here, but here’s a skeletal pseudo-C code:

while (1) {

if (!run_me) {sleep(20ms); continue;}

run_me= false;




The global boolean “run_me” tells the task to run once.

Notice the “sleep(20ms)” which prevents the task from chewing up an undue amount of CPU time.

So, if we were to put a motor set-speed in periodic tasks, we could update the motor speed far more quickly and control that motor more precisely, correct?

Or are the motor set-speeds tied to the control station packets somehow?

I’m not sure I follow you, Tom: more quickly and more precisely compared to what?

Or are the motor set-speeds tied to the control station packets somehow?

TeleOp is not strictly speaking periodic; it’s event-driven: It runs whenever data packets are sent, which occurs about every 20ms. You can then read that new data within TeleOp and act on it immediately within TeleOp, as long as you can do so well within 20ms. If your TeleOp code takes longer than 20ms to execute, you’ll miss the next data packet.

Reading joystick values in a 10ms periodic task doesn’t get new joystick data any faster.

Reading sensors on your robot faster than 20ms gets new sensor data that can be used to alter motor commands if you think you need to do that.

Jaguars are updated at 200hz, and Victors at 100hz, so yes you could update the motors much faster then telop (50hz). Whether that translates into better control depends on the mechanical time constant of the system.

When a robot has lag, the first thing I’d check is errors being displayed in the Diagnostics tab. The errors indicate and issue, and catching the unhanded errors is quite expensive and adds the lag.

Once the errors are clean, I’d check on the CPU usage in the Charts tab of the DS.

Greg McKaskle

Thanks Joe. I understand the concept of a mechanical time constant regarding motors and magnetic fields, but how would someone even begin to estimate such a thing for an FRC robot?

I think I’m going to go do some online reading as well.

Ether, are you implying that if my global variable returns false, then it waits 20ms BEFORE doing whatever else is in that case statement? If so, wouldn’t that cause the error since the Teleop code is taking >20ms to complete one cycle?

No, it releases the processor for 20ms before looping back* to the top of the while loop and checking the “run_me” boolean again. There is no case statement in the pseudo-code I posted so I’m not sure what you were referring to.

If so, wouldn’t that cause the error since the Teleop code is taking >20ms to complete one cycle?

No. The while loop goes into the periodic tasks vi. The while loop runs in parallel with TeleOp.

Read the posts linked below. Seriously, read and study them. You will be glad you did:

  • the “continue” statement in C means “go back to the top of the loop”

Greg, so I don’t wanna hi-jack but I sort of have the same question here because the period tasks are new in the 2012 framework compared to the 2011, 2010 and 2009 framework.

If there is a button on a joystick that is pressed to turn on a motor setting, you’re saying it’s best to place this in periodic tasks? Rather than place the motor set output in telop?

Should we only put robot drive code or joystick to robot drive in teleop and let’s say all other components in period tasks?


I have not actually seen the 2012 framework and I am going off of my programming work in 2011

What I would do is put the motor setting in periodic and the control for it in teleop. you connect the two with a global variable. (teleop writes to it, periodic reads it)

Likewise, you write to the global variable in autonomous as well.

Hope that helps.

I’m pretty sure the Periodic tasks have been there since the beginning. The Vision task is basically the same thing, but specialized to be throttled by camera images showing up.

Joystick values show up when new control packets arrive. So the teleop is designed to be a great place to catch the latest joystick “events” and respond to them with the least latency. For some operations, where the joystick is the most important trigger and the response is quick, teleop is a great place to put the code.

If the code is also triggered by time, takes more than 20ms to complete the operation, or includes sensor measurement to complete a control loop, Periodic may be a better place. As ratdude said, using teleop joystick data to update set points and time to run the control algorithm is a pretty common situation. That naturally minimizes the latency of both inputs. Note that it is pretty easy to read the joystick wherever you like, so this can often simplify some of the communication between Periodic and teleop and not require using a global just to hold the joystick state.

Greg McKaskle

The Main reason I always used global variables was to keep teleop things in teleop. This does two things; it means that if you ever want to change that value during autonomous, it is an easy switch; it also means that if a random act of god caused a controller issue during autonomous, no problems would occur (like if a ball being tossed in the stands randomly bounced and hit a joystick).

Consider it a matter of programmer’s preference… its how I learned to write code and it has always worked for me.

Ok, this brings up another question I’ve been thinking about.

Greg, if a speed has not changed from the last loop, is there any reason to call the set speed command? Will not calling it result in a watchdog?

yes, it would if the delay was long enough. it used to be 100ms last I checked.

(safety measure to prevent runaway robots)

The motor safety will trigger if it isn’t updated every 100ms (assuming that you didn’t disable the motor safety or change the timeout limit). It will not affect the watchdog.

Shouldn’t be 10ms, since setspeed commands in teleop aren’t called that often.

yeah, it is 100ms. typo. fixing original