Please Help Compiled info Teleop Periodic Task need verification

[Greg McKaskle]

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

[mbone206]

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

[Greg McKaskle]

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

[mbone206]

Thanx Greg, great tool

Will be able to try later today