The perfect dashboard

[Joe_Widen]

What would the perfect dashboard have on it?
I'll start:

The battery level
Current Draw of each motor
Orientation of any attachment at anytime
Speed (Because its cool to know your going X.x fps)

[Billfred]

Battery level is always handy, as would the sensor readings of anything drastically important (say, current draw on my drive motors, if I had them wired to say as such).

CMUcam information would be ridiculously awesome for aiming purposes; I remember seeing 16's system at Palmetto, and I wish we'd thought of it.

Important alerts (say, loss of the backup battery) should be easily seen (think big red boxes with clear text), but also not block the other data. (Call it the I-know-the-backup-battery-is-on-the-floor-you-stupid-dolt! principle.)

Orientation of attachments I'm not so sure of. For a game like Aim High or Triple Play, it wasn't exactly important--your operator could most likely see what was happening better than he or she could deduce them from a Dashboard. That said, a game with less visibility from the drivers' station like Stack Attack (or perhaps FIRST Frenzy, if you were trying to climb from the other end of the field) might find this useful.

Speed....eh, not really. From my experience behind the glass, you want as few distractions as possible before and during a match--that includes extraneous information on a Dashboard, opposing robots chucking balls right at you, your mother trying to talk to you, and having your cell phone start ringing. Of course, if you wanted to have speed information on there, you could always have a bells-and-whistles dashboard for testing and a streamlined one for on the field.

[Greg Marra]

We had a dashboard this year, and it was really used a lot more for debugging than during a match. The only data we actually would look at -during- a match was our shooter RPM and the camera feedback data. The rest was just nice for testing and before the match. It's always good to make sure the battery votlage is above twelve before a match starts :D .

Make it easy to read. Important/quickreference stuff big, less important stuff small. Design for your user; ask the drivers what they want.

[Astronouth7303]

Something configurable and scriptable! (a la XUL (http://en.wikipedia.org/wiki/XUL))

We also had a dashboard (http://www.chiefdelphi.com/media/photos/24407) this year. The only thing I would add to it (except for above) is to add support for other data streams (TCP/IP, named pipes, etc.) in addition to serial ports.

If I could make it semi-dynamically configurable, I would probably leave the entire bottom pane open, and remove code for sequence detection (something I added after seeing Ypsilanti regional).

[Donut]

Battery level and current draw definitely.

In the case of the shooter wheel, another speed indicator (we had one this year already).

Warning lights with important text on them (these could be read by your secondary driver/coach in the second they're not yelling about something). For example, I would like an "arm elevation failure" light to turn on when the fuse for my pneumatic elevator on the arm blows out.

A few other random nice lights too if they have a good reason.

Robot speed I'd only see as important in testing, not on the field.