Benefits of "Periodic Tasks VI"?

[JakobLover]

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!

[Greg McKaskle]

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

[CRLS97]

Originally Posted by Greg McKaskle

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.

In our teams code the bulk of our code is in Periodic Tasks.vi However in our Teleop.vi 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...

[Ether]

Originally Posted by CRLS97

In our teams code the bulk of our code is in Periodic Tasks.vi However in our Teleop.vi 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;

doSomething;

sleep(250ms);

doSomethingElse;
}

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.

[Tom Line]

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?

[Ether]

Originally Posted by Tom Line

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?

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.

[Joe Ross]

Originally Posted by Tom Line

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?

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.

[Greg McKaskle]

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

[Tom Line]

Originally Posted by Joe Ross

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.

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.

[CRLS97]

Originally Posted by Ether

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;

doSomething;

sleep(250ms);

doSomethingElse;
}

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.

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?

[Ether]

Originally Posted by CRLS97

Ether, are you implying that if my global variable returns false, then it waits 20ms BEFORE doing whatever else is in that case statement?

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:

http://www.chiefdelphi.com/forums/sh...96&postcount=3

http://www.chiefdelphi.com/forums/sh...21&postcount=6

http://www.chiefdelphi.com/forums/sh...43&postcount=4


* the "continue" statement in C means "go back to the top of the loop"

[Chris_Elston]

Originally Posted by Greg McKaskle

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

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?

thanks.
Chris

[ratdude747]

Originally Posted by Chris_Elston

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?

thanks.
Chris

*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.

[Greg McKaskle]

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

[ratdude747]

Originally Posted by Greg McKaskle

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.