[Greg McKaskle]

Egg, your process seems pretty adaptable to LabVIEW.

For most good LV users, the design process generally mixes pseudo dataflow and pseudo procedural descriptions. The design is often done at a whiteboard, but paper works fine. You start with where the data starts, and write that on the left, then think about what happens to that data next and draw an arrow from the source to the processing step, ...

The text descriptions will often take on the form of (process array comparing to previous, calculate arm setpoint, etc. ) and that will later turn into a subVI or a loop of code.

For FRC, the teleop would start with a joystick read with specifics of joystick number, axis, button numbers, etc. The next box of description might be about identifying button combos, latching, timeouts, and mapping joystick 0-1 values to other ranges. Next it would either update setpoints on motors, push them to other loops running independently, or store values for the next iteration.

As with pseudocoding in other languages, syntax isn't important, short-hand is good, and the semantic comments, structure info and literals are some of the more important values to hilite. A potential benefit of dataflow languages is their focus on the data being processed, stored, etc. Those transfer mechanisms and flow are a validation that the processing is working on the right values. Finding that in procedural langauges is also important, and often more tedious to locate.

After doing this for awhile, I normally don't go to the whiteboard. I just lay out a big LV diagram and use the comment tool and some of the loops and single frame sequences to describe the structure. And of course I pseudocode less than I used to. These days, it is generally to document or explore an algorithm with others.

Hope this helps to see past the hieroglyphics.
Greg McKaskle