×

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 - State Machine

Table of Contents

Using a State Machine For Sequences of Actions

When programming a robot, or programming in general, it is often convenient to specify a sequence of steps, but sometimes the program must be able to exit that sequence or start another when instructed to. A good architecture for this is the State Machine (NI documentation here).

The following example implements a state machine for a device that utilizes limit switches wired into the DI\O ports of the RoboRIO. The objective is for a button press to signal the motor to go up until the top limit switch is pressed, then go back down to the bottom limit switch; this will happen un altered unless either a button to go down is pressed sending the actuator down immediately or the up button is pressed again (in which case the sequence is restarted).

Initialization

Just a formality, but below is the code used to initialize (open) the devices needed for this example.

Initialization

Periodic Tasks

Due to the constructs of this data structure, it can be implemented in Periodic Tasks or in Teleop, for simplicity's sake, and to prevent inadvertently causing lag to the drive motion of the robot, this example will show implementation in Periodic Tasks, although it could be done in Teleop.

To start, create a enum control on the front panel, and right click on it. From the menu, select "Make Type Def."

Creating the TypeDef

Right click again and select "Open Type Def"

Open the TypeDef

Once the Type Def is open, we can set the items of the enum. For this example the Up, Down, Initialize, and Get Input have been entered.

Set states

Back in Periodic Tasks, we use this Type Def to setup the state machine.

A while loop is created for the main body, but some of the more cpu intensive maneuvers are taken care of before entering the loop in this example. In the initialize case, we configure the motor to be stopped, and for the next state to be Get Input

Initializing the state machine

Switching to Up mode next, we configure the motor to go up unless the limit switch is pressed, then stop the motor. Also, the next state is set for Get Input, unless the limit switch is pressed, in which case it is set to Down.

Up case of the state machine

In Down mode, basically the same is accomplished, stopping the motor at the bottom, and constantly checking back for input.

Down case of the state machine

And Finally, the Get Input Mode, here it is realized that we need to return to the previous mode if a button is not pressed, so a second element is added to the state shift register. We also realize that here we want the motor to continue momentarily while we check the joystick, so its value is placed in a shift register. And finally we read the joystick to see if we want to change the direction, otherwise we send out the value of the last iteration (the one before the get value).

Get Input case of the state machine

Cleanup

This will work, but we realize that we have little bit of over complication. We decided to check for user input between every command to the motor, so we could move that to being a part of the loop and not a state. This change allows us to make the possible state merely: up, down, and stopped. It also simplifies some of the logic and the memory (shift registers) required.

Cleaning it all up.

This tutorial is meant to be suggestive of how one might use a state machine architecture in the FIRST Robotics Competition. It will likely need to be modified to fit your specific application.

Possible Improvements

  • Add a global, or functional global, variable so that this loop can also be controlled in autonomous.

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

Google Form to request details