Quote:
|
* Teleop is event driven, runs when Data packets are sent, occurs every 20mS
|
runs when data packets are
received by your robot. sent by your Driver Station supposedly every 20ms, but may vary due to Windoze not being a realtime OS. therefore don't bank on the 20ms (i.e. don't base timing calculations such as rate computations on a fixed 20ms)
Quote:
|
* If you Have code in teleop that will take more than 20mS, will impact/lag communications to robot
|
...because your code won't start processing the next DS data packet if it is still stuck in TeleOp from the previous packet.
Quote:
* Periodic task wait Xms in loop, example 10mS, loop will run minimum required time 10mS, but each loop may vary in time
*To have periodic task run similar time each loop, use 'Wait Until Next Multiple', this is good for task that need to run very regular intervals
|
See Team 358's whitepaper "
Timing Is Everything"
Quote:
|
* periodic task wait time: do not want to have wait time too small...
|
Make it as small as necessary, and as large as tolerable.
Quote:
|
...may force labview priority in CPU time sharing and may override task that need more priority?
|
Not sure what you mean by "
need more priority". A higher priority task trumps a lower-priority one.
Quote:
|
why put anything in teleop? Why not put all code put in multiple loops periodic task?
|
If you want the minimum latency between between the receipt of a new DS packet (containing updated driver commands) and the cRIO issuing new commands (to the various actuators on the robot) based on those new driver commands, TeleOp would be the place to put that code, since TeleOp is event-driven. Any code in a Periodic task has a latency based on how long its period is. However, for FRC purposes it probably makes little or no practical difference if the Periodic task is running fast enough.
Quote:
|
*Joystick values show up when new control packets (Teleop) arrive, every 20mS? So teleop would be great place to catch the latest joystick events.
|
... and act* on them if you wish; see above
* or initiate action, in the case of an action (such as an action requiring delays) requiring a state machine or a parallel task