[JesseK]

We use raw Java on the display and custom network code to get custom packets from the cRIO. The data structure is 200 bytes, and contains every input, sensor, motor output, pneumatic state, and vision targeting parameter we have. Then we use Java reflection to open up the data structure and print it on the screen in a panel for quick debugging -- reflection avoids the need to update the data printer every time the software kids need the data structure change to change. We found that using custom packets is less processing and bandwidth-intensive than the Network Tables since we can control the data rate directly. The display also stores the data to file in a .CSV format for quick telemetry analysis post-match. Avoiding Network Tables also avoids "heavy weight" library dependencies, which has bitten us in the past when we've swapped laptops around.

The kids wrote some code around the data structure for a GUI. We may do touch-screen next year, but not at the expense of our current goals (plus a physical button board is better for the offseason stuff we do).

Our software goals for the display are more along the lines of quick integration debugging, sensor tuning, & match replay rather than live match control. Our drivers rarely take their eyes off the field.

I've never heard of "Processing" until now. Will have to look that one up.