View Single Post
  #14   Spotlight this post!  
Unread 05-12-2010, 10:46
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,754
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Mecanum - use of gyro

Concerning the loops and timing jitter, the normal while loop inherits the priority of the VI it is within. Note that by default, subVIs inherit their caller's priority as well. Initially everything in the FRC framework is set to normal priority. If you decide you want to bump something, you change that subVI's priority in its properties/execution page, and it typically propagates as you intend.

The delay used in the while loop that was shown has a resolution of 1 ms, and is not considered low jitter, though it typically performs fine IMO. The low jitter and higher resolution delays and timing functions are located in the real-time palette.

The timed loop incorporates these timing functions into the loop and performs many of the common calculations for you. The timed loop lets you choose between a 1ms, 1us, or device specific clocks which may be available. It lets you choose between a few different timing policies concerning missed periods. It lets you set priority on each loop without needing to embed it in a subVI. It lets you more easily measure actual start times vs scheduled start time, actual and scheduled finish times, whether the loop met or missed the deadline and by how much, etc.

From what I've seen, common FRC tasks are fine with msec resolution and aren't bothered by a few ms of jitter, so the framework starts simple. Meanwhile, if you find that an arm or other mechanism needs it, the real-time mechanisms are there to lower the jitter. Similarly, the framework uses simple globals to share information between loops and subVIs. To gain determinism, you would trade those for RT FIFOs which are more complex, but can offer jitter or performance benefits and offer more control in corner situations.

Greg McKaskle
Reply With Quote