![]() |
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!
|
Re: Benefits of "Periodic Tasks VI"?
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 |
Re: Benefits of "Periodic Tasks VI"?
Quote:
|
Re: Benefits of "Periodic Tasks VI"?
Quote:
Code:
while (1) {Notice the "sleep(20ms)" which prevents the task from chewing up an undue amount of CPU time. |
Re: Benefits of "Periodic Tasks VI"?
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? |
Re: Benefits of "Periodic Tasks VI"?
Quote:
Quote:
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. |
Re: Benefits of "Periodic Tasks VI"?
Quote:
|
Re: Benefits of "Periodic Tasks VI"?
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 |
Re: Benefits of "Periodic Tasks VI"?
Quote:
I think I'm going to go do some online reading as well. |
Re: Benefits of "Periodic Tasks VI"?
Quote:
|
Re: Benefits of "Periodic Tasks VI"?
Quote:
Quote:
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" |
Re: Benefits of "Periodic Tasks VI"?
Quote:
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 |
Re: Benefits of "Periodic Tasks VI"?
Quote:
*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. |
Re: Benefits of "Periodic Tasks VI"?
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 |
Re: Benefits of "Periodic Tasks VI"?
Quote:
Consider it a matter of programmer's preference... its how I learned to write code and it has always worked for me. |
| All times are GMT -5. The time now is 01:42. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi