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]

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]

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]

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]

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]

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]

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]

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/showpost.php?p=1094796&postcount=3

http://www.chiefdelphi.com/forums/showpost.php?p=1094821&postcount=6

http://www.chiefdelphi.com/forums/showpost.php?p=1120343&postcount=4


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

[Chris_Elston]

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]

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]

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.

[Tom Line]

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?

[ratdude747]

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)

[Joe Ross]

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?

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.

[Tom Line]

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

(safety measure to prevent runaway robots)

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

[ratdude747]

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

yeah, it is 100ms. typo. fixing original

[Tom Line]

Thanks Joe. So - if you've disabled the motor safeties, what happens if set speed is not called for say, 2 or 3 seconds. Does the motor stay at the last set point?

I ask because some of the Beta teams saw a noticeable improvement in CPU usage by putting a simple if/then around their set speed and only calling it on a change.

[Alan Anderson]

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?

I'm not Greg, but I know the answer. If a motor has its Motor Safety watchpup enabled, you must continue to set it at least as often as the safety configuration requires. Drive motors have the safety period set at 100 milliseconds. Other motors have the safety disabled by default. If you let a motor's safety timeout elapse without setting its output, that motor will be shut off.

If a motor's safety feature is not enabled, it will keep its last commanded output value indefinitely. That includes switching from autonomous to teleoperated mode (or vice versa, which can happen during testing), so you should make sure your motors are initialized to something reasonable when such things happen.

[Greg McKaskle]

There are several watchdog and safety mechanisms in effect.

The system watchdog will shutdown the robot outputs when the DS communications is interrupted or an estop takes place. The 100ms timeout is controlled by the Robot Safety mechanism and it automatically zeroes configured robotDrive motors after 100ms. Not setting RobotDrive every 20ms will lower CPU usage, but I'm curious as to how much.

Greg McKaskle

[Pirate programe]

The system watchdog will shutdown the robot outputs when the DS communications is interrupted or an estop takes place.

What could cause Driver Station communications to be interrupted?

our team is using UDP to transmit between the Dashboard and the cRIO, which appears to be delaying the watchdog being fed, and interrupting robot communications. the port we're using for the socket isn't being used anywhere else in the code, from what we can see, so what could it be?

[ratdude747]

What could cause Driver Station communications to be interrupted?

our team is using UDP to transmit between the Dashboard and the cRIO, which appears to be delaying the watchdog being fed, and interrupting robot communications. the port we're using for the socket isn't being used anywhere else in the code, from what we can see, so what could it be?

wireless failure on the robot, wireless failure of the field, loose cable at the robot, loose able on the field, loose cable at the driver's station, software/hardware glitch on the robot/field/driver's station, random acts of god, solar flares :D , etc.

[Greg McKaskle]

Can you describe more? Perhaps post some code?

Greg Mckaskle