A state machine is an abstract machine which represents a certain number of states and can only be in one at a time. The state at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition; this is called a transition. We use finite state machines on our robots, which contain a finite set of states. Typically, code is executed when first transitioning to a state. While in that state, some code is executed to effect the system towards the next state. Also, a condition is checked for state transition. If a transition occurs, code may be executed when leaving a state. See the state machine labs for more. Our 2015 robot code had a state machine class to manage state machines and a state class to contain lambdas of code to perform the aforementioned actions.
State machines can be used to automate a sequence of actions. We use these predominantly for the autonomous period of our robot code, but this functionality can prove useful for performing user actions as well. For example, we used a state machine in our 2015 robot code to control the auto-stacking process. As goals where reached by the elevator system, the software would advance through the various states defined in the state machine until the idle state was reached. The elevator subsystem used a PID controller to travel to the various goals required for state transitions (see the state machine lab).
As a side note, WPILib's Command-Based programming paradigm, which involves creating and scheduling commands and command groups, is essentially a verbose way of allowing teams to make and use state machines. This verbosity is why our 2015 robot used custom state machine management classes; we only had to assign a few lambdas instead of writing boilerplate classes, like this.