So, who has a custom dashboard?

[Radical Pi]

I'm curious to see how many teams have been able to successfully get their own customized dashboard working.

So far, the Classmate side of the dashboard for our team is almost 100% done. From C++ the code works in theory. I was able to send some static data as a test but our debug code has never tried sending live data to the dashboard (and won't until competition now). Camera feed works like a charm though. Our drivers absolutely love it (and it really helps with aiming)!

I'll try to get a picture of it up when I can

[Alan Anderson]

Our custom Dashboard works great. We're using LabVIEW on the robot, so it was easy to make the data match up.

One wrinkle we added was to split the display into two tabs. One is for use during a match and the other has a lot of diagnostic information (like raw encoder counts and other sensor input).

[EHaskins]

Our dashboard is written in C#/WPF, and it's talking to Java.

Other than a few issues due to poor documentation it has been relativily painless.

[Tanner]

Right now we've just got a few important things to make sure nothing is broken (which is always good to check for). Might add a overheard view of the view for drivers to make sure that the autonomous switches are in the right place.

The dashboard is really nice for some debugging stuff as well, just so you don't have to pull up the programming computer to check one teeny thing.

-Tanner

[ideasrule]

We have a custom dashboard. It's the only thing that made a live camera feed possible.

[sloteera]

Our dashboard just shows the camera image, an feedback for "ball in position to kick" and three possibles range for the kick!!

At the moment it's work very well!

We'll make a USB network using and "USB bridged cable" between Classmate and an Laptop to expand the camera image, but we don't try it yet!!

PS: we're using LV!

[Ziaholic]

We have a custom dashboard and a programmer that's diving into some more of the advanced features like animating shapes and creating custom indicators.

One thing that we haven't figured out completely yet is if it is possible to access the Teleop Elapsed Time without sending it from the 'bot. We're going to use this data to flash an indicator when we are approaching the final 20 seconds of the match.

Do I have to send that time from the 'bot, or is it already available via some local Dashboard/DriverStation variable that we haven't found yet?

[umangv620]

tried to make a custom dashboard, but got so confused on how to. i looked up some videos on frcmastery.com but they jump around from one series to the next, so i didnt get it.

[PIDman]

Ours isn't really custom, we just tweaked it a bit. We have an indicator to convert psi into kicking distance, it's really neat.:D

[pSYeNCe]

We have a (non-tested) custom dashboard for extra feedback, mostly. I wish I had more time with the robot, I would customize it a lot more than I did... Ah well. There's always the practice day before competition! :p

[PranavSathy]

We have a custom dashboard in C#, and it reciees packets via TCP/IP to display certain values like voltage, it shows a live camera feed AND it even records whatever images we got after a certain record packet is sent. It also has audio playback capability to play cool music during certian points of the match like a victory and game over music.

Below is the picture of our dashboard at startup :D

[Robototes2412]

can someone please send me a link to the protocol notes that FRC/WPI used to make the dashboard? I want to make my own dashboard in python/pyGtk, I am programming the robot in java.

[Boydean]

As of Tuesday we do not have a dashboard. But between now and Palmetto we could very easy have one(maybe even required).

One wrinkle we added was to split the display into two tabs. One is for use during a match and the other has a lot of diagnostic information (like raw encoder counts and other sensor input).

I really like this idea, I'll be really looking into making this happen on our dashboard.

[apalrd]

I just finished writing the Killer Bees dashboard. I made the camera as large as possible with the small screen (full dashboard height at same aspect ratio),gave status information about the robot, made the background black, and grouped all of the controls into the cells of honeycomb. All of the text is 33pt yellow, default font. All of the indicator lights are brightly colored (purple, pink, yellow, blue, and green for on and red and black for off) so the drivers can see. Since we don't like to look down at the controls, the indicators are primarily aimed at the coach. For a final touch, I replaced the Timeout in camera communication message with the logo on honeybomb with a white background, with "Timeout in Camera" on the bottom. (I then put this program on the Classmate, which resides in a silver briefcase with honeycomb and our logo on it).

I like the idea of the tabbed dashboard. However, when that raw data is necessary, I am usually editing the code, so I can just probe stuff.

[Brandon_L]

It would be cool to record the camera feed from the matches, how can you do that with the default dashboard?

[apalrd]

There is a VI to save the images at a predetermined rate, to JPG files. Seems to work well.

[jspatz1]

We've done quite a bit of customizing. Bigger vision window, orientation compass, kicker strength indicator, status lights. Simplified the overall look for easy viewing. Pretty easy when using Labview to program.

[Brandon_L]

There is a VI to save the images at a predetermined rate, to JPG files. Seems to work well.

Ill look at it, but theres no way to do a video?

[Radical Pi]

Ill look at it, but theres no way to do a video?

There are quite a few programs that can convert a series of images into a video (ffmpeg comes to mind)

On that topic, I looked where the dashboard should be saving camera images and found only a single image back from when I was getting the camera to work. I checked the Dashboard and the code seems to be intact.

[byteit101]

There are quite a few programs that can convert a series of images into a video (ffmpeg comes to mind)

On that topic, I looked where the dashboard should be saving camera images and found only a single image back from when I was getting the camera to work. I checked the Dashboard and the code seems to be intact.

ah, ffmpeg! my favorite video editing program. I used images with timestamps to make it timed correctly, and got a nice video: http://thecatattack.org/media/Vid/#AsixM409 (Match 4 (from robot camera) is the best, at the end of auto, we are staring at our team, and you can watch the seconds count down, then we jump forward). we even had a "Cat-o-Vison" sign and played four of these in the pits (one got scrambled up later)

we are using our ZomB dashbaord (http://www.chiefdelphi.com/forums/showthread.php?t=82612) and right now I am adding the smashTCP video to it so we can stream video: http://www.chiefdelphi.com/forums/showthread.php?t=82422 (and my version doesn't need .net 4, It uses .net 2!)

[slavik262]

As many of you know, I'm currently in the process of making one (http://www.chiefdelphi.com/forums/showthread.php?t=80561). I've ran into a roadblock though. After working with the UI for several weeks, I went today to test the networking only to find that FIRST had completely changed the protocol around. If anybody could get me up-to-date documentation on the dashboard protocol, I would be extremely grateful.

[spartango]

While for competition we have a stable custom labview Dashboard(robot-side code is all Java), we've been experimenting with a java swing dashboard:

http://code.google.com/p/grtframework/downloads/detail?name=FRCDashboard.jar

[tutkows1]

How do you make the custom dashboard look for the camera feed?

[Robototes2412]

should you be able to get the camera feed with just a specialized java swing image container?

[Joshuaal2000]

For my team, I am Using the Demo Dashboard as a base, but I have completely modified it to only contain info that our drivers want during the match, such as two bars to compare our what our drivers set for our kicking distance, to that of what the robot is currently set to kick at. This makes it simple for the drivers to see when the Kicker is in the correct position. We have Booleans for certain necessary features. We also display What state our Autonomous and Kicker state machines are currently in, Using enumerations from our C code.

Our custom Dashboard works great. We're using LabVIEW on the robot, so it was easy to make the data match up.

One wrinkle we added was to split the display into two tabs. One is for use during a match and the other has a lot of diagnostic information (like raw encoder counts and other sensor input).

I have also done this to my dashboard, but in a different fashion. Using Data sent from the robot, we have made an autonomous and a teleop tabs plus a developer tab for debugging. During the match, the tabs switch from auto to teleop instantaneously when the state of the game changes with no manual control needed. This allows us to display different data during each part of the match, and allows us to keep our auto tab uncluttered so we can have larger text and inidcators, so that the driving team can view it from their starting position. The developer page requires manual opening to view.

[jhersh]

As many of you know, I'm currently in the process of making one (http://www.chiefdelphi.com/forums/showthread.php?t=80561). I've ran into a roadblock though. After working with the UI for several weeks, I went today to test the networking only to find that FIRST had completely changed the protocol around. If anybody could get me up-to-date documentation on the dashboard protocol, I would be extremely grateful.

I don't believe it changed much... what are you thinking changed? I know we added in the error data that shows up on the dashboard and the made a distinction between high- and low-priority dashboard data. If you have any more direct questions about it, just PM me.

[slavik262]

They didn't completely change it around - that was me being a bit reactionary and frustrated that it changed when I went to test it. The user data used to be in the following order: User string (as in a string of text you could add), Error string, and then the rest of the user data. This is in contrast to the current setup with high-priority data, then the error string, then the low-priority data. I have it working (to my knowledge anyways - I still need to do some more testing with the robot) thanks to Eric Haskins and his documentation. You can check out my first release at the bottom of this page (http://www.chiefdelphi.com/forums/showthread.php?t=80561&page=3). There's a few bugs in the initial release that I noted on page 4 -they're already fixed and I'll have the next release out in a day or so.

[jhersh]

They didn't completely change it around - that was me being a bit reactionary and frustrated that it changed when I went to test it. The user data used to be in the following order: User string (as in a string of text you could add), Error string, and then the rest of the user data. This is in contrast to the current setup with high-priority data, then the error string, then the low-priority data.

The primary change was to rename the fields. Because user strings and user data are both just variable size data fields, we didn't think they should be named as though they would only work in those ways. Since the real difference was the priority of each field wrt to the error strings, we decided to name it as such. Then on the robot, we made it easier to send either strings or packed data to either field. Make sense?

What was the practical difference that impacted your code?

-Joe

[bladetech932]

We have a custom dashboard of which the main purpose is to reduce lag and increase the size of the vision