paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)

[apalrd]

We use a lot of finite state machines for things that we sequence. We also use other control strategies for other things, including feedback controls, and lookup tables.

Our software modules are very large. They usually line up with the physical subsystem teams, although I threw the gun in with Roller because the integration between them was very critical and I wanted them to be designed together (there were 4 mechanical teams and 3 software modules).

We then design up a high-level design of the software (what each module is responsible for, what sensors and actuators it has command of, and what the interactions with other modules including HMI/Auton are). From that, we design each module.

The modules are split up into blocks, usually based on control of specific actuators or related groups of actuators. For example, drivetrain is split between drive motors and shift. Drive motors handles the drive motors, and shift handles the shifting. Drive motors is a passthrough function (control is unique to HMI/Auton, this is the only feature that is not implemented in it's module) and shifting is a lookup table. With servos in 2012, shifting was a finite-state machine that would peak and hold the servos for better shift quality and servo reliability (we melted servo or two before doing that).

So it dosen't make sense to design everything as an FSM. We really use a lot of small FSMs when we need to sequence actions at a high level (like the gun feed state machine or 2011 arm state machine), or deal with intermediate states at a medium to low level (like the peak-and-hold state machine).

All of the code runs in parallel (it all shares a single task, the software design strictly prevents blocking execution). The execution order is specified by how data is used by other modules.

I am not sure what NI's intentions are with the Statechart module.