Please Help Compiled info Teleop Periodic Task need verification

Technical NI LabVIEW
1

Hi All, greatly appreciate LabView FRC experience on timing/errors

After a lot of reading in Chief Delphi (some from LabView Greg M), I am getting closer to understanding how to structure the Robot Code to avoid lag/errors on field. I still need some clarification, help. Below are some bullets I learned compiling many searches, please feel free to comment because I have seen conflicting messages:

  • Teleop is event driven, runs when Data packets are sent, occurs every 20mS
  • If you Have code in teleop that will take more than 20mS, will impact/lag communications to robot
    *Periodic Task best place to put code that require loops, reading sensors, ect…
  • You can have as many timed loops in periodic task as want, LabView will split multiple threads
  • 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
  • periodic task wait time: do not want to have wait time too small, may force labview priority in CPU time sharing and may override task that need more priority?
  • Avoid Local variables (not desirable in parallel sequencing program), Global variables OK, prefer put all in RobotGlobalData.VI
  • Since Teleop runs at 50Hz, updating motors outside teleop may happen faster, Jaguars update at 200Hz, Victors at 100Hz

Hope this is correct, a lot of time went into compiling this info… hopefully it will help others that are trying to get this information little by little, great to have confirmation on correctness

Now, after all this, million dollar question, why put anything in teleop? Why not put all code put in multiple loops periodic task?
How many loops should I use and set them all to 10mS???

Other points I read, based on this question, please correct if needed to try and help answer this
*Joystick values show up when new control packets (Teleop) arrive, every 20mS? So teleop would be great place to catch the latest joystick events.

Questions on this point?
If this is the case, why does the framework have joystick code in periodic task? Also, why does does framework code use shift register for this?
If I make all my periodic loops 10mS, minimizing what is each loop, time on these threads will be closely shared, and should not exceed 20mS (DS packet/teleop), so it does not have to be in teleop?

PLEASE help comment? I need to change my team code, would like input, a lot of work to rewrite all this/debug/ect… all on practice robot. Right now, have no choice, way too much in Teleop. This was/is my plan:

  1. Tank Drive: in Periodic task loop: 10mS Wait: Joystick and motor update, use one button for shifter. None in teleop
  2. Camera Lock, servo Motor: Separate 10mS periodic task loop: Use Target Global, PID to lock and update servo motor, set global target lock booleans
    In this code, instead of using standard 10mS Wait, use 10mS ‘Wait Until Next Multiple’ based on previous bullet in this thread, want smoother
    intervals. Right now this is in Teleop (YES I need to move it), camera/servo is jerky trying to lock, will "Wait Until Next Multiple’ help this?
    The PID set point is always trying to ‘0’, no real dead band?, this may be reason why? Using LabView PID
  3. Ball Sensors: Use in its own periodic Task Loop?
  4. Game Pad for shooting, ect… Was going to put Game Pad in teleop; use Global for every button, in RobotGlobalData.VI Have a separate standard
    10mS periodic loop, update shooter motors, lift belts collect balls, ect…
  5. Gyro: used for tracking where on field, have button reset, also have option to automatically disable camera lock when camera facing opponent
    baskets, do not servo or lock in this case. Can I put in sensor loop, since nothing else in it?

Your professional feedback is appreciated… By the way, I am an Engineer for semi conductor company, not a programmer, just trying to help my sons team.

Last two years my son’s team has run great at the school and had a ton of problems, mainly communications, lag, ect… at competition. I want to optimize there chances of this not happening any more. It is heart breaking to see all the hours and hard work the kids put in, excited have a good Robot at school and at the competition does not run the same.

LAST Question, based on this statement: If running Robot at school, and the drive station diagnostic window not showing errors, why would have errors
at competition? How do you simulate competition communications to know if you have everything correct?

Thank You
Mark…

2
  • 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)

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

  • 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”

  • periodic task wait time: do not want to have wait time too small…

Make it as small as necessary, and as large as tolerable.

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

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.

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

Thank you Ether and Team 358, Great White Paper

Follow up questions if I may:
*After reading white paper, having ‘Wait Until next multiple’ is the better wait VI for using camera/servo PID. Will there be penalties if use this Wait VI in all the periodic loops (vs standard wait VI), just sounds better to use all the time?

  • Comment on wait time periodic task loop: I am not sure what is ‘as small as necessary/large tolerate’, how do I determine this?
    question on ‘need more priority’: What I read or possibly interpreted it wrong, *comment on what what mean by priority: if I make one periodic loop 2mS. and one 10mS, this forces LabView to give more priority (CPU time) on 2Ms loop than 10mS, also may force more critical task at a lower priority (less CPU time allocated for more critical task, say Teleop??)
  • Good explanation on teleop or periodic task… now I believe I fully understand… I think… Based on this: I will move tank drive to teleop, using victors, controlled by joystick, since victors update 100hz and teleop running 50hz (may be longer than 20mS based on expanation of Windows timing), however, I will keep solenoid low gear code in periodic task, not sure how fast solenoid/sol. vi will update, or be fast enough for Teleop 20mS, < 50Hz (does that make sense?)
  • Can you please give me you input on question, do not see errors running Robot wireless at school in diagnostic window, but get them at competition, how can this be evaluated before competition? Is Field communication system part of the problem and not so much the code in this case?

Thanx again
Mark

4

Global variables are preferred over Locals, but Global are just as bad and not desirable in parallel sequencing program the same as Local variables.

Global and Local variables defeat the data flow of LabVIEW. You can have race conditions just as easy with Globals as you can with Locals.

Try to use wires.

Globals are good for global settings that do not change very much, read only in many places, but maybe write only in one location.

5

Omar,

Thanx for reply…

I do not see how Globals can be prevented. Teleop will be using set points for periodic task loops, how else can you do it

Thanx for reminder about race conditions, need to be disciplined and only write to Global in one place

Mark

6

*After reading white paper, having ‘Wait Until next multiple’ is the better wait VI for using camera/servo PID. Will there be penalties if use this Wait VI in all the periodic loops (vs standard wait VI), just sounds better to use all the time?

I was wondering the same thing**:**

If anyone knows the answer would you please post?

  • Comment on wait time periodic task loop: I am not sure what is ‘as small as necessary/large tolerate’, how do I determine this?

It’s your call. If you put your DS command processing/output into a Periodic Task, and use a period of 5 seconds (I’m being ridiculous here to make a point), then that’s obviously not “as small as necessary” to get acceptable response to driver commands. On the other hand, if you use a period of 1 millisecond, that’s certainly not “as large as tolerable”: you could double that period and the driver wouldn’t notice any difference.

if I make one periodic loop 2mS. and one 10mS, this forces LabView to give more priority (CPU time) on 2Ms loop than 10mS,

LabVIEW does not automatically assign rate-monotonic priorities to parallel tasks in the Periodic Tasks vi. By default, all the parallel tasks in the Periodic Tasks vi are the same priority, regardless of their period (LabVIEW gurus please correct me if this is wrong).

…also may force more critical task at a lower priority (less CPU time allocated for more critical task, say Teleop??)

I believe TeleOp runs by default at the same priority as Periodic Tasks vi.
If a parallel task is truly “more critical”, you should assign it a higher priority. But be careful: any parallel tasks of lower priority will not receive any CPU time while a higher priority parallel task is running.

  • Can you please give me you input on question, do not see errors running Robot wireless at school in diagnostic window, but get them at competition, how can this be evaluated before competition? Is Field communication system part of the problem and not so much the code in this case?

Can’t help you there. Maybe someone else can weigh in.
*
*

7

There are many mechanisms for communicating information from one VI to another (e.g. queues and occurrences), but the default code framework doesn’t provide any way to tell both Teleop and Periodic Tasks to use one. Unless you add more input terminals to those predefined VIs, a global variable is a reasonable solution.

There is also a LabVIEW idiom called a “functional global”, which might make dataflow purists happier, but I don’t think that’s an important goal.

8

Just want all to know that you still have to be alert with Globals variables just the same with Locals variables. You do not get a free pass with Globals.

Globals variables are not preferred method in ANY programming language. In school, I had a C prof that would ding us for using globals variables in our C code.

The preferred method in LabVIEW is what you are already using all through out your robot LabVIEW code now!

What we call LV2-Global, Functional Global, Action Engine, etc. Example of these are all the **RefNum Registry Set **and **RefNum Registry Get **that are used for all your devices that you are using on your robot.

You SET the RefNum in your Begin.VI and then GET the RefNum where ever you need them.

That is the preferred method.
But if used wisely, Globals have their place.

9

thank you again Ether, Alan, Omar

STILL some open questions for LAB View gurus, Please help:

*After reading white paper, having ‘Wait Until next multiple’ is the better wait VI for using camera/servo PID. Will there be penalties if use this Wait VI in all the periodic loops (vs standard wait VI), just sounds better to use all the time?

  • What’s the downside of “Wait Until Next Multiple” ? When would you ever want to use “Wait” instead?

*LabVIEW does not automatically assign rate-monotonic priorities to parallel tasks in the Periodic Tasks vi. By default, all the parallel tasks in the Periodic Tasks vi are the same priority, regardless of their period (LabVIEW gurus please correct me if this is wrong).

*Does TeleOp runs by default at the same priority as Periodic Tasks vi. How do we you you find this out, documentation from Lab View?

  • Can you please give me you input on question, do not see errors running Robot wireless at school in diagnostic window, but get them at competition, how can this be evaluated before competition? Is Field communication system part of the problem and not so much the code in this case?
10

My responses are marked with **.

*After reading white paper, having ‘Wait Until next multiple’ is the better wait VI for using camera/servo PID. Will there be penalties if use this Wait VI in all the periodic loops (vs standard wait VI), just sounds better to use all the time?

  • What’s the downside of “Wait Until Next Multiple” ? When would you ever want to use “Wait” instead?

** Wait and Wait ms Multiple (WMM) are closely related functions that implement different policies for late starts.
** Wait doesn’t attempt to catch up. It sleeps the wired amount every time it is called. The OS may not awaken it on time, but it doesn’t try to outsmart or adapt.
** WMM does some simple calculation to align itself with the system clock. If wired with 10, WMM will look at the remainder of the system clock/10 and will try to awaken on the 10-ticks of the clock. Its policy is that short sleeps are an acceptable way get the schedule back in phase. An odd side-effect of this is that the first sleep may be 1ms. If something causes it to miss entire periods, it doesn’t not try to recover those, only partial misses.
** Your diagram can do your own scheduling math if you like, and then simply call the Wait function. That would be equivalent to the WMM.
** By the way, the uber-scheduler is the timed-loop. If you double-click, or right click and configure, the lower right corner includes policy for what to do with missed periods, phase alignment, offset, and even the clocking source.
** Note that I’m answering the questions more for informational purposes. I doubt this is contributing to the lag of the robot. Clearly timing errors can impact control, but none of this will make up for code that is far-far off schedule.

*LabVIEW does not automatically assign rate-monotonic priorities to parallel tasks in the Periodic Tasks vi. By default, all the parallel tasks in the Periodic Tasks vi are the same priority, regardless of their period (LabVIEW gurus please correct me if this is wrong).

** This is correct. All regular loops within a VI inherit the VI’s priority, and the VI typically inherits the caller’s priority. Each subVI can specify a priority if you go to VI Properties >> Execution tab. The timed loop also has a priority specification.

*Does TeleOp runs by default at the same priority as Periodic Tasks vi. How do we you you find this out, documentation from Lab View?

** Inspect the VI Properties to verify. By default, all team code is at normal priority, as priorities were considered an advanced topic that we didn’t want to require teams to understand in order to get started.

  • Can you please give me you input on question, do not see errors running Robot wireless at school in diagnostic window, but get them at competition, how can this be evaluated before competition? Is Field communication system part of the problem and not so much the code in this case?

** I may be able to help if I knew what the errors were. I was at San Antonio regional on Thursday, and the “it worked fine in our shop” phrase is very common. That is often due to insufficient testing. Many of those robots had wiring issues, coding issues, etc. One thing I’ll suggest again is to run the robot through a DS practice match. Teams using only the Teleop and Auto modes of the DS are often surprised by the field as it transitions them from auto to disabled to tele. The robots that don’t leave auto, or no longer have resources open in tele are usually ferreted out by a single practice mode test. I’ll be happy to answer more questions if you have details of the errors that cropped up.

Greg McKaskle

11

Thanx Greg M, very helpful

  • some errors were TCP errors which the field people indicated they saw when we had communication problems… we did not know why or how to correct

  • BASIC Operation Errors: after moving a lot of code around, we were getting Left - Right Motors not fast enough in diagnostic window Using Left - Right motors for tank drive. Interesting enough, we get as soon as we enable teleop from driver station without running… again when started driving… So I stated a new project: Only put tank drive in Teleop & used no other code, still got same errors… then started new project, put tank driver code in periodic task, try 5mS and 10mS wait, got same errors when first started, clear messages, drove a while without errors, then received same errors… after 6 hours to middle of night, gave up and totally confused… did so much research, many hours rewriting code to minimize what is in teleop, still was getting Left Right motors not fast enough with only tank drive in code… BTW: When drove without errors for a while, still had errors on start up, then cleared messages, never was able to get that error message without start up, never even driving robot gives errors not fast enough???

Greatly appreciate support…

Mark

12

What I’d suggest is to instrument the drive code to note each timestamp when you call update for the drive. Once the robot is started, the robotDrive safety mechanism considers 100ms to be the update period. If this only happens once at the beginning of teleop, it could simply be because the disabled wasn’t updating the robotDrive, or it could be some init code that you didn’t consider. Anyway, instrumenting it is pretty easy.

The first thing to do is to open the support folder in the project window. The VI called Elapsed Times can be dropped into teleop, into periodic loops, autonomous loops, vision loops, or wherever you want to measure the elapsed time between subsequent calls. If you wire up a string, that is the identifier it will use, otherwise it will use the calling VI’s name.

Once inserted, run the robot code and open the panel. Each unique name will be on a new row of the table, and the number to the right is the last deltaT.

If the typical time seems good – around 20ms, it may be useful to modify the Elapsed Times VI to keep some statistical data such as the largest delta you’ve seen since startup.

Please post back with details on what you find.

Also keep in mind that the safety mechanism is on for the RobotDrive by default, but if you are comfortable with the typical times, you can disable it in Begin, teleop, or anywhere else in your app. It is there to help with breakpoints and the like, but isn’t mandatory.

Greg McKaskle

13

Thanx Greg, great tool

Will be able to try later today