Periodic Task (vi) - Thoughts?

[cabbagekid2]

Hi, I was wondering what peoples thoughts were with what code should be put in periodic task. I believe with the old IFI control system you couldn't read driver station values in periodic task (it was just meant for on board sensors, internal calcs, etc). Everything that dealt with driver station input was in teleop.

With the new Crio though since the teleop while loop cycle doesn't finish until the last thing executes, it leads me to think that we should either move the slowest items in teleop to periodic task or the fastest items (so the slow items don't slow down the faster items).

As an example, our lift uses pid and a bunch of other limit checks to keep the driver from killing the lift. However, this is probably the slowest thing in teleop (we used the elapse vi and usually things are under 100ms however there are times when it goes over).

So, what we did was move our minibot deployment code (just a switch from the driver station controlling solenoids) to periodic task since it leads me to believe that if telop does run over 100ms that minibot deployment can be delayed by up to 90ms or so. We also plan to move a bunch of other things that can run faster into periodic task from teleop. Does this seem right? Putting teleop code in periodic tasks seems a little weird to me. Where do you differentiate what should go where?

Any comments would be good. If you could give your own examples of what you put in teleop vs periodic task that would be good. THanks!

[Greg McKaskle]

Periodic tasks is really just a template showing that code can run in parallel with the telelop VI.

The camera code runs independently and publishes results. This is especially good since cameras are somewhat slow sensors. You wouldn't want the camera to limit when the teleop finished, right?

Similarly, any periodic tasks, especially slow ones should be considered for this approach. If you have a PID loop, especially if the teleop loop rate isn't the ideal loop rate for the PID, move the PID into periodic. Update the setpoints from within teleop, but let the sensor reads, the calculations, and the value updates happen within periodic.

By moving things out, and running control loops at the rate they need, rather than the rate of the joysticks, hopefully you can have your teleop running at 20ms instead of 100.

Doug Norman and I will be giving a presentation in St Louis which covers this in a bit more detail. I'm assuming the slides will be available afterwards.

Greg McKaskle

[Ether]

Originally Posted by Greg McKaskle

Doug Norman and I will be giving a presentation in St Louis which covers this in a bit more detail. I'm assuming the slides will be available afterwards.

Thank you Greg. I think there's a real need for this information, especially for teams with no mentors who have experience with realtime control.

[cabbagekid2]

Thanks Greg. I look forward to your presentation. Do you know what the topic of the other tbd NI presentation is?

[Greg McKaskle]

The title is something like -- Making the Most of LabVIEW for FRC : Performance, Debugging, and Architecture.

The performance section covers the performance goals of the different VIs, shows different measurements you can make to determine if you meet those goals, and if not, why not.

Debugging covers understanding errors, determining where they come from, why they are being reported, and what to try to get them to stop.

Architecture covers determining where to put different code elements, and how to coordinate them.

And of course, if you ask other questions, we'll try to answer them. Doug and I will also be in the NI booth in some form of Genius Bar. We'll have computers and robot, so you can drop by and we'll do our best to answer whatever questions you may have.

Greg McKaskle

[Richard100]

Greg - Does this apply to Autonomous as well? Should a while loop in autonomous (say, iterating while waiting for a drive encoder to reach a certain distance) - be moved to periodic tasks? Is there any difference in a loop running within periodic tasks and one running in autonomous?

We're getting performance issues (drive motors stop intermittently) while running this autonomous and the concurrent vision processing loop. We have a 50 ms delay in the autonomous loop and 20 ms delay in the vision loop.

[Greg McKaskle]

The only thing special about the autonomous VI is that it is dynamically launched and aborted after the autonomous is over. If you would like to distribute some of the processing into other loops, that is fine. The parallel loops can be in periodic.vi or even in the autonomous.

Another thing to consider is whether you would like to use the exact same periodic loop code for a mechanism. Use it during tele and during auto. This should allow for more consistent control.

Greg McKaskle