[apalrd]

I can't say anything about the command structure, but in LabVIEW and C I've done similar things several times. Here is how I did it:

In LV, I created blocks to calculate each of the possible left/right pairs then a Switch to pick the correct one (this is approximately equivalent to an If and Else in C), using a boolean latch to store the chosen state. The code in LV was approximately equivalent to an If and Else in C (actually, I believe you would need 3 Ifs and 1 Else to do the entire thing including boolean latch). Other variations required a single switch to be held to switch modes. All of this would be wrapped into its own block which accepts the HMI data struct and outputs a drivetrain pair struct. I could drop in other blocks at will with minimal issue.

For a similar system of more than two modes, in LV or C, I would likely create an enumerated typedef to store the currently selected mode, calculate all possible pairs (which are stored in a pair struct) and shove them into an array, and index the array by the enum. The enum would be selected using a similar stack of LV Switches per button. The single Switch is slightly more elegant for a 2-choice solution than an array with index.


As for the lack of cRio, I like testing code on my laptop on a software test harness. Usually in LV I just take the core VI and write a computer-target VI to simulate the IO and display the output, it seems like it would be significantly harder to do in C++ or Java, but still doable.

In all cases that I have used, I was simply reversing the drivetrain, to drive backwards with trigger. We don't do that any more with the Halo drive, since you only have to move one thumb stick instead of two full-sized joysticks.

While it's perfectly fine (and highly encouraged) to experiment with multiple interfaces prior to heavy driver training, I highly recommend removing this functionality from the competition code so you don't confuse your drivers more. A well tuned driver input algorithm should not require any additional driver input, or be significantly modal.

As for the command-based implementation, I can't help there. I generally do embedded systems work in Simulink, we use state machines and lookup tables rampantly.