×

Our Future . . .

When I initially created this site in 2014, it was to serve two primary purposes.

  1. To document the tips, tricks, and other higher level development practices that make programming for FRC in LabVIEW easier.
  2. Provide a common place for LabVIEW teams to find resources.

At first, this meant documenting the architectural and similar tools that I had learned on my way to becoming a Certified LabVIEW Developer, that had been put to use by the team I was currently mentoring (#3937, Breakaway). (This had the added bonus of helping the senior programmer that had been soaking all this up document it for his successor.)

Since then, this site has had a few additions and updates (mostly by me).

While I have often invited other teams (I am no longer in the AR area and have pretty much lost contact with Breakaway) on CD and at the regionals I've been at to write tutorials for specific topics that they had solved, I was rarely met with a response (specifically once - shout out to the Huskie Robotics 3061 for actually following through, but they were the only ones).

 

In recent years, I have found myself going through some family changes and needing to dial back my commitment to other activities.

This leaves this site both:

  1. Looking for a new champion/curator, that is willing to:
    • maintain the back end,
    • make sure material that becomes obsolete is either updated, or moved to the archives section of the menu,
    • and either write content or get other teams to write content to help this site remain relevant.
  2. Looking for a new source of funding/hosting. (I have been personall providing the $36/yr that it costs to maintain it using Google Domains for the domain name - and email - and Hosting24 for the hosting; I have thought about using some sort of a Donate button, but have not been able to find a platform that allows for *only* raising the target amount).

 

If you have any interest in seeing the continuation of this site, please let me know.

FRC LabVIEW Tutorials - Autonomous

Table of Contents

Clarification

This optimization is not for the robot, rather it is for the developer. What is presented below is a methodology that - when combined with certain architectures, can minimize the amount of code necessary - thereby reducing the time to write it and the effort to debug/enhance it.

Setup

For the duration of this tutorial, it is assumed that the motors and joysticks have already been opened in Begin.vi, and that this robot has a wheeled shooter.

Architecture

This configuration utilizes the producer-consumer architecture. This allows the code for controlling the actuators to be in one single place (periodic tasks) and the code to control it to be in either Teleop or Autonomous - depending on which mode the robot is in.

Caveat

This setup has both a major advantage and disadvantage. The advantage is that the code for moving is reused, and does not need to be repeated in addition to the fact that if a control is changed in autonomous, the robot only needs to be re-enabled to use the updated variation.
The disadvantage is because the movements are stored in a control, one must go to edit > make current values default in order to make the changes be saved to the vi.

Setting the current values

Autonomous.vi

We start by adding a shooter speed to the default array of motor movements.

Adding the shooter speed to the array

In the block diagram, we enable the for loop that uses the array, and update the current movement indicator (delete and recreate).

enable the for loop to use the array.

This loop will perform each instruction for the specified amount of time, then move onto the next instruction in the array. By adding what the shooter's speed should be, it now controls the whole robot with this set of instructions.

Using an fgv to pass the shooter speed to periodic tasks, the autonomous.vi is finished.

finishing up

Periodic Tasks.vi

In periodic tasks, the fgv is read and the motor is set.

setting the motor

Summary

By using the array of movements and the fgv, no code is unnecessarily repeated (assuming that the drive code used in teleop is slightly different), and by using the fgv, data checking can be performed that values that are input for the shooter speed are valid.

Possible Improvements

If this tutorial inadvertently leaves some details out, please tell us about it and we will update it.

Google Form to request details