New in WPILib this year is a little thing we call the Smart Dashboard. This dashboard aims to simplify visualizing data sent back from your robot.
With this dashboard, no laptop-side programming is required. Simply add a call to SmartDashboard.log() on the robot and the cross-platform GUI is automatically informed of the data and puts it on the screen for you. The GUI can then be customized by dragging widgets around and changing how they look (text boxes, dials, and progress bars are included; each have a handful of adjustable preferences).
I had an initial look at SmartDashboard yesterday and I really like the simplicity and ease of configuration, especially from the robot side. The static log() method makes it exceptionally easy to get data out of the robot and onto a dashboard, and I also really like the fact that the client needs no configuration changes when new inputs are added.
We don’t have anyone on our team with labview experience, so we were leery about attempting to customize the default dashboard, and our attempts to run the zomB dashboard failed. Now that I’ve seen SmartDashboard, I am really hopeful that it will meet our needs - and I expect that it will work out quite well.
I don’t have any bugs to report, but after first glance I can think of some feature requests.
-Data logging: Store all the incoming data points and write them to a log file for later analysis.
-Plotting/graphing of data points, especially time-based running plots. Maybe use something like JChart2D for this task.
-More widget types (compass pointer dials especially) would always be nice, and the ability to add static elements (labels, targeting overlays on video feed, etc.) to the dashboard would also be useful.
If I feel brave (my Java is rudimentary) I may see if I can add any of this stuff myself and send you a patch.
On the whole, SmartDashboard is a nice piece of work, and I’m excited to make full use of it this year.
Can you use the smart dashboard to create a “template” that you can then edit to add your own cool stuff then? From your report it sounds like you can. I did not try using the Smart Dashboard yet.
I was planning on possibly creating a dashboard for Analyst or Coach to glance at and tell the drivers what they need to know since drivers usually keep their eyes on the field. This year I plan on using sensors heavily for detecting situations that would require a certain programmed mode. This would mean the driver-station need to be looked at more.
sorry to hear this, did you set your team number in the team number box at the bottom, and did you install the .out file on the robot?
I must admit, I often forget to set the team number on new installs
If more GUI-like functionality is available for this (my team really really wants a compass like interface) then this shall be our new Dashboard. Really excited
I used it earlier today and it worked pretty well. It’s nice not to have to deal with labview. It’s also way nicer than println statements.
Few problems I ran into:
It seemed that there was a maximum number of fields to log, afterwards they were ignored. It’s not really a big problem, it would just be nice to see the capabilities documented somewhere. (i.e. does type of data affect? does length of field name?)
Documentation could also be elaborated a bit more. Although I figured it out soon enough, it would have been nice if “SimpleDashboard.init();” was mentioned in the readme. Example code is always good, especially for people who aren’t experienced with Java.
Sometimes, when the robot was reprogrammed, a second copy of the fields would show up on the dashboard. Only the new ones were updated.
Aesthetically, it might be good to set up “snapping” for moving the controls on the page around. It could make the dashboard look more professional & as though more than 5 minutes effort was put into it
Overall though, I really like this project. It’s so awesome. You have no idea how thankful I am
Sorry, no templating functionality at this point; the GUI is relatively basic. I was suggesting that I might try and contribute to the project by writing the code for the additional widget types. (But no promises on that front…)
When we tried to boot the cRIO with the zomB plugin (.out file) installed, the plugin threw 30+ lines of missing symbol exceptions and then crashed during the startup process.
However, I don’t want to hijack this thread into a discussion about zomB, so you can expect me to start a new thread or PM you if I want to attempt to run zomB again. No offense intended if I choose to stick with SmartDash though…
Thanks for the feedback everyone. I have noted down all of your requests and will implement them when I can. For those of you with FirstForge accounts, feel free to submit bugs tickets (under the “Tracker” tab) or feature requests (under the “Tasks” tab) at the SmartDashboard project page and I will keep track of them.
To clarify a few things that were discussed:
Maximum number of fields, etc… Due to the structure of the network code, up to 127 fields may be created. This is not affected by data type. Name strings may be of any length (within reason), but value data of type String are restricted to 127 characters in length.
If you encounter one of these limitations or any other strange behavior, I encourage you to send the return value of SmartDashboard.log() to
SmartDashboard.diagnoseErrorCode(). It will return to a string suggesting what went wrong. A value of SmartDashboard.SUCCESS will be returned when the call succeeds.
SmartDashboard.init(). Calling this function is now optional; if the SmartDashboard class is not already initialized, it will do so immediately upon the first call to log().
Widgets are redundantly re-created and their predecessors are orphaned occasionally on a reboot. I noticed this as well earlier today; it is being tracked as a bug.
Thanks for all of your suggestions! A graph widget and logging to a file are very popular requests, so they are my top priority. I will also investigate adding a compass or other “directional” widget and optional “snap to grid” behavior.
Also, if any of you are interested in submitting patches to the client side code, I just posted a zip of the source code Net Beans project. Unfortunately, anonymous version control access is not available on FirstForge, but I would be happy to look at patches.
As far as SmartDashboard.init(), goes: good to know! Man, that makes using it even easier.
As far as missing fields go, I’ll play around with it. (I was no where near 127 fields, so that’s not the issue…) It might be a problem with my specific code. If reproducible I’ll get back to you on it Monday.
We are going to switch our Dashboard over to this tonight, hopefully without any issues.
We are not planning on using the camera this year, but if we change our mind and decide to add the camera, is it as simple to add the camera feed as it is variables. I am guessing the .log feature probably doesn’t handle the camera?
I think the smart dashboard is great. It was easy to setup and show data. This is a great idea for teams with limited LabView experience. But our programming team still decided to use the LabView dashboard because of the extra widgets and toys.
I haven’t had a chance to try this out yet (our cRIO should have gotten here yesterday ) but it looks like it’ll be really useful! So much simpler than re-compiling a LV program every time the dashboard data changes.
Have you thought at all about implementing a dashboard-robot system for communication? I’d love being able to call SmartDashboard.update(pid_i) and have a edit box appear on the screen that lets me edit the value on the robot. If not, I may brush up on my java ::rtm::
You can sort of do this with ZomB ( you have to a tad more though), if you have AllTCP set, you can send stuff back to the robot via all the controls that support it (All that are obvious, drag the value meter for example)
We got it installed and working this evening, and I am already in love. Simple to add variables and when I heard the camera will show up too it was over. Bye bye Labview finally.
I haven’t figured out the save mechanism yet. I rearranged the variables the way I liked them and saved them, but when I rebooted the robot after updating code, the variables all popped up again over my other ones. I assume I have to rearrange them every time I add another variable? Does it save the config between shutdowns? Also, how do you delete a variable on the screen that isn’t being updated anymore?
Overall, I’ll deal with “pretty” config issues anyday for how easy this was.
I’m pleased to announce that a new version of the Smart Dashboard client has been posted, version 0.6.0. Here are the release notes:
Smart Dashboard Client 0.6.0
============================
* Added Compass widget. This may be selected for use with any numerical
data type.
* Added LinePlot widget. This may be selected for use with any numerical
data type. It may be resized by changing its widget-specific preferences.
* Added snap-to-grid view option. When enabled via the "View" drop down menu,
all subsequent widget dragging will "snap" to a grid to ease placement.
* Added logging to a CSV (Comma Separated Values) file support.
- This may be enabled via the GUI preferences dialog ("File" -> "Preferences").
- Three values are logged: The time in milliseconds since the logging began, the name
of the field being logged, and the string representation of the field's value.
- All timestamps are tallied according to the client computer's local clock (not the robot's
clock). Maximum sample time resolution is approximately 20 milliseconds. Samples sent more
frequently than this will be queued for transmission to the client and will therefore
be marked with very similar timestamps.
- Logging is automatically restarted when the dashboard is opened if it was previously
enabled. It will continue to record all key-value pairs until it is disabled
or the dashboard is closed.
- When logging is enabled, the target file will be overwritten whenever the GUI
is restarted. If a particular log is important to you, copy it to somewhere
safe before restarting the dashboard!
* Fixed crash when video display is enabled when the robot camera is configured for high
resolution video.
* Fixed bug where redundant fields are displayed on the dashboard GUI when a robot is
restarted.
* Fixed bug where changing a widget to another widget type (such as TextBox to SimpleDial) would
often cause it to be moved when it shouldn't have been.
* Reduced memory usage of robot video display feature.
*********************************************************
Note: Save Files from Prior Versions are Incompatible
*********************************************************
Unfortunately, due to the current architecture of the profile saving and loading
routines, save files generated by a prior version of the dashboard are not compatible with
this version. We apologize for the inconvenience and plan to avoid this restriction in the
future. For the time being, however, please re-create any/all profiles with the newer
version of the client.
Radical Pi, I was just recently discussing that idea with some of my colleagues the other day. We will investigate that feature; it sounds quite promising.
Thanks for all of your feedback everyone! I’m pleased to have a release for you which delivers as many of your requested features as it does.
Anonymous, no, but you can access it just by logging in to FIRST Forge (i.e. not a member of the project) if you configure the permissions of the project as such. That is the state of the SVN server in the WPILib project.
) but it looks like it’ll be really useful! So much simpler than re-compiling a LV program every time the dashboard data changes.