Survey: What is your team using for a custom dashboard? ZomB? SmartDashBoard? LabVIEW

Technical Programming
1

Quick survey: What is your team using to create a custom dashboard this year? ZomB Dashboard? SmartDashboard? Writing one in LabVIEW? Something else completely?

We would like to create a custom dashboard for our robot that uses some simple graphical controls and can display the video from the camera on the robot.

We wrote our custom dashboard in LabVIEW last year, and that worked very well, but our one LabVIEW programmer left at the end of last year. Rather than get up-to-speed on LabVIEW, we’d like to try something else this year. (Our team’s software engineers this year are all C++ and Java programmers.)

We’ve been trying to get ZomB Dashboard up and running for the past 4 days or so, including the just-posted ZomB v0.7.1.350, but no success yet. The features look great, we just haven’t been able to get it to work. It would be wonderful if a well-written Quick Start document existed for ZomB. The user manual for ZomB is good, but does not seem to have careful, tested, step-by-step instructions to get it going. I know at least one or two other teams are using ZomB rirght now. If one of those teams would be willing to post step-by-step instructions for how to get started with ZomB, that would be awesome, and be useful to many other teams.

SmartDashboard looks potentially quite interesting. I’d like to know if other teams are successfully using it.

There is also the CARDS Dashboard. We tried to use it briefly this past fall, but there is very little documentation, and we couldn’t figure it out. The last posting was in May 2010, so I’m not sure it is still being maintained.

There is the IFI Dashboard Viewer, but it doesn’t seem like it’s designed to be customized.

Is there any other obvious custom dashboard system I haven’t listed here?

So, what is your team using for a custom dashboard this year?

Any advice, hints, pointers, or instructions in this area would be greatly appreciated. Many thanks!

2

If you want to use something pre-existing, I’m guessing ZomB would be your best bet based on what I’ve been hearing. However, here’s no better advice than to just try them all :stuck_out_tongue:

Sadly, I don’t have much to suggest in the way of the pre-built dashboards (except that I noticed the same problems you had with CARD), as I’m new this year and just jumped right in to making my own dashboard. I’d suggest this if your programmers think they’re capable of it and need something to do (I’m not sure how much experience other FIRST programmers have), as there’s always the problem of many programmers, one robot.

3

We’re writing our own Dashboard in Java. And we’ll share when we’re done with it. Probably at the end of build season. It’s documented nicely, but the code itself is repetitive and will make all sane object-oriented programmers cry.

In the semi-likely event we don’t get it done by shipping day, the code will get finished before the competition, debugged at the competition, and shared after the competition.

If your Java or C++ programmers are interested, we started by looking at the documentation for sockets and it turned out to be pretty simple. Run a server on the robot and client on the driver station. For some reasons the Java writeUTF method puts two extra bytes in front of each line we readLine, so we substring’ed them out in the client-side program.

After that, it was all just busy work getting the values to display on a nicely crafted dashboard (which we’re still working on). I highly recommend the Swing GUI builder in Netbeans because it’s easy to use. It has some general limitations but are easy to deal with. If all you want are string values to display, you can get it running in hours. If you want a nice GUI, it will take longer than that.

4

I’m currently working on some quick start tutorials for ZomB, but what there is out now should get you going. Have you looked at NetConsole? If it is spewing Duplicate symbol errors, try reinstalling ZomB.out (Start>Programs>ZomB>install bindings to robot) and if that fails, try the C++ DBPacket workaround (in the Bindings Help pdf in the ZomB Start menu folder)

Other than that, make sure you are setting your team number in Visual ZomB and that the sources (click the … button) contains urls that start with zomb://.yourteamnumber, and then creating a dashboard (r350 should prompt you for it though)
Also, make sure you are initialize correctly on your robot code:
ZomBDashboard z;
…
constructor():
z(ZomBDashboard::GetInstance(AllTCP, “10.xx.yy.zz”))

where xxyy is your team, and zz is the computer running zomb (only necessary for sending to the robot)

5

My team made a Labview one last year, but this year we basically decided immediately that we would rather use SmartDashboard. It works extremely well, especially for testing, and it’s simple to learn/teach.

Nobody on our team actually knew Labview last year, apart from a little experience I had with it two years ago (just playing around), but it was relatively simple to learn it AT COMPETITION.

6

We will be using LabVIEW again. It plays so nice with LabVIEW cRio code.

<side note> Code written in LabVIEW does not need a dashboard to graphically display data during development, as the VI front panel is accessible when running code from a laptop.

7

We have already had a lot of success with the SmartDashboard, it is a piece of cake to setup and send data. But our team has decided to use the labview dashboard due to its greater selection of features and the professional look. Though we have already ran into complications with the LV dashboard so whether we will be sticking with it is not guaranteed. We have never tried, or ever really considered ZomB due too complications other teams have recounted to us.

8

We are creating our custom Dashboard in C# (.NET) using Visual Studio Express (free). We use the WPI Dashboard class to pack up whatever robot data we are interested in receiving and capture it with a simple .NET UDP listener for graphical display and manipulation. We also capture the camera images (.jpg) using a similar TCP listener. The images were a bit trickier to string back together into separate images given that single packet can contain the end of one image and the beginning of another. It’s really cool to capture all of these images and string them together to make a video of what the robot actually saw. We are excited this year that our Dashboard can actually transmit data to the robot using UDP 1130 which opens up a variety of interesting previously prohibited possibilities….

9

None

10

I’m just glad to hear so many teams building dashboards. If you have any issues, please ask questions. The debugging, logging, and feedback potential is huge, and it is very safe, and relatively easy to improve over the default – one-size-fits-all dashboard. All teams should shoot for some form of customized DB.

Greg McKaskle

11

Say, byteit101: We tried your new Quick Guide for ZomB Dashboard, and it worked great. We got a very simple custom ZomB Dashboard working in about an hour, with a graphical display of the joystick position (the equivalent of “Hello World” for ZomB Dashboard). Huzzah! Thanks so much for writing that Quick Guide, it was a huge help.

We will now start adding more sophisticated controls to our ZomB Dashboard, including the camera image. This looks like it’s going to save us a ton of time, and I think we’ll end up with a very nice custom dashboard. Thanks so much for creating and sharing ZomB Dashboard! This looks like it’s a great resource for teams that want to create a nice custom dashboard without learning LabVIEW or writing a lot of C# or Java code with custom graphics.