Hey, our team is creating a custom dashboard in LabView for the classmate. This pretty much overhauls the old standard dashboard program by making bigger video screens and providing other dials and whatnot. Does anyone have any ideas of what we can put into our program? Like for example, some indicators of some sort?
Our team kept the basic design of the dashboard. We added a new tab to the info in the top right so we could monitor air pressure, battery voltage, and the piston position in our kicker. In competition, we didn’t use it much, but for robot testing, the extra data was very helpful.
I suggest having a larger video screen, and having a space were messages from the programmer can show up. For example, you are now cocked at position three. Having a pressure gauge is also a good idea.
On a side note: were did you find a gauge that can send the air pressure as an analog signal to the control system?
Edit: More about what we did.
Last year my team didn’t use the classmate for the dashboard, we sent it to another computer so we could have a larger screen and it seemed to run the feed better.
Any attempt at creating a dashboard should reflect the robot, and thus you would either have to write it for last year’s robot as a learning experience or wait until you write the robot-end code next year.
I have a tabbed interface that automatically switches between disabled, auto, and teleop, plus some tabs for subsystem debugging. (I included the source code in my recent CD-paper of my 2010 robot code). The camera view is not used by the drivers, but the coach can see if there are hidden balls. We never look at the dashboard, except the camera image, unless something is wrong and we need feedback information NOW. We also have an indicator of which autonomous program will run when enabled, so the operator can set it from her controls before the beginning of the match. We tried placing a yellow circle where the target should be for 3rd zone auto to assist with line up since we run 3rd zone basically all the time, but then the camera got hit by a ball and un-aligned.
You cannot send data back to the robot. Dashboard packets are one-way, going from the user code on the cRio to the dashboard application on the Classmate, but not back.
If you are planning on using the Dashboard for debugging (And are using LabVIEW), you can just put controls on your VI’s (any of them) and adjust them at runtime, if you run Robot Main.vi instead of doing a full build. You can probe wires, look at graphs, and edit tuning constants in real time. When you are done, you can (after stopping execution of robot main) right-click on the control and say “Data Operations -> Make Current value default” to save it, even when you do a full build.
tutkows1:
I need to clarify. We didn’t actually measure the air pressure. We just used the same sensor the air compressor uses to determine full vs. not full. If I remember right, the sensor was already one of our digital inputs, so we made a boolean indicator on the dashboard.
This can be crucial. Having the ability to put the raw sensor values on screen is an important part of defensive programming. If the robot is misbehaving, it’s nice to be able to quickly pinpoint a disconnected gyro or limit switch.
There were ideas for an additional tab that we never got around to implementing: a “preflight checklist” with appropriate indicators.
@DKt01
Oh, i has hoping you could help me in the quest to find one for a personal project. 
I like the tabs for debugging.
Our Robot has an analog pressure sensor on it hooked into one of the analog imputs on cRios. We played around with the data communication and have a guage on our large video screen with the air pressure. I think that the while loop on the dashboard has a slow iteration rate however, because it is quite slow responding, about 1-1.5 seconds per responce, hardly real-time… But we might consider putting dashboard onto another computer. Did the program run faster on a different laptop than it did on classmate?
The default dashboard is really slow. Apparently this is because of the graphs.
The iteration time is not set directly. The main loop iterates every time it gets a data packet from the robot. (Those data packets should be sent by the robot every time its main loop runs, and those runs are triggered by the packets coming from the driver station, etc.)
I noticed during testing that it takes around 10 seconds for the inputs to update while disabled (I have no idea why this is), and around 1.5 seconds while enabled, using the default dashboard. My custom dashboard is about 1 second, all the time. This is because of the default handling of the crio end, only updating the low priority dashboard data every 25 iterations (the high priority data, which in the default code is the tracking data, is updated every iteration).
The default dashboard setup attempts to read most of the I/O channels, and send them to the ds and dashboard about twice a second. Reading that many channels through the Apis could place quite a load on the CRIO if done at 50 hz. If wou trim the channels being read to just the ones you are using or interested in, wou could easily up the rate. It is your CPU, so use as much as you like.
Greg McKaskle