Using Processing for custom dashboard
 

Hello! I'm asking this question on behalf of a few of my colleagues whose area of expertise is in the language Processing. They're fantastic programmers, and can make any GUI you can imagine. I believe it's a highly object-oriented dialect of Java (I don't program with it myself, so I'm not sure), and apparently there are libraries you can import to compile it as regular Java. Our actual robot is programmed in C++, and we've never used network tables before. Is it possible to construct a dashboard that can send data to and from the robot using Processing? Thanks!

Re: Using Processing for custom dashboard
 

Why not just use Smartdashboard?

Re: Using Processing for custom dashboard
 

If you want to use Java, just extract the NetworkTables bindings from SmartDashboard. They have a separate jar file available that has them. The JAR is also distributed with the C++ stuff, look in C:\WindRiver\WPILib\desktop-lib

We did our custom dashboard in python, also using NetworkTables.

As long as both sides are using a common communication mechanism (like NetworkTables), it doesn't matter what language either side is written in.

Re: Using Processing for custom dashboard
 

Like I said, we're not sure what we're doing, but if we could use Processing, everything would be perfect.You're kind of the team that inspired us to make a custom dashboard.... Would we simply extract the NetworkTables Jar file into an eclipse workspace and add "some code" to send and receive values on the dashboard and robot-side programs?

Re: Using Processing for custom dashboard
 

Yup.

Re: Using Processing for custom dashboard
 

Can you inform me of somewhere I could go to learn? Thanks, by the way

Re: Using Processing for custom dashboard
 

This document covers getting the client (ie dashboard) side of network tables running in netbeans. http://wpilib.screenstepslive.com/s/...client-pc-side

Re: Using Processing for custom dashboard
 

Network tables seem fairly straightforward from the example on that page. I was wondering if there is much lag/delay between sending and receiving information. We would like to send information from the keyboard to a Motor controller, which I believe has to be updated once every 10ms or so... so that's a lot of information. Do we need to add delay (such as a wait statement or state machine) to both sides of the code or should it be okay to just attempt to send data back and forth in real-time? Also, should we create separate network tables for input and output communication? Thanks!

Re: Using Processing for custom dashboard
 

Even the joysticks for the driver station aren't updated enough to be used in latencies less than 100ms if that's what you care about. Chances are, that isn't really what you care about, and so the latency is low enough that you won't notice it. But the NetworkTables lag could easily be in the 100ms range or higher.

You should use different elements in the table, but no need to create separate tables. What we've traditionally done is just used the 'SmartDashboard' table, that way we can use all of the SmartDashboard infrastructure on the robot side and use the SmartDashboard itself.

Re: Using Processing for custom dashboard
 

We use raw Java on the display and custom network code to get custom packets from the cRIO. The data structure is 200 bytes, and contains every input, sensor, motor output, pneumatic state, and vision targeting parameter we have. Then we use Java reflection to open up the data structure and print it on the screen in a panel for quick debugging -- reflection avoids the need to update the data printer every time the software kids need the data structure change to change. We found that using custom packets is less processing and bandwidth-intensive than the Network Tables since we can control the data rate directly. The display also stores the data to file in a .CSV format for quick telemetry analysis post-match. Avoiding Network Tables also avoids "heavy weight" library dependencies, which has bitten us in the past when we've swapped laptops around.

The kids wrote some code around the data structure for a GUI. We may do touch-screen next year, but not at the expense of our current goals (plus a physical button board is better for the offseason stuff we do).

Our software goals for the display are more along the lines of quick integration debugging, sensor tuning, & match replay rather than live match control. Our drivers rarely take their eyes off the field.

I've never heard of "Processing" until now. Will have to look that one up.

Re: Using Processing for custom dashboard
 

Thanks everyone! Hypothetically, we now have all the knowledge to make a custom GUI than except the camera display (just the display, not vision processing. Eventually, we'll do that on-board). I believe there's a lot of stuff in WPI for that. Would we have to set up an entire robot project (configured and everything as if we were actually controlling the robot with it) to utilize that or just import it like we did with NetworkTables?

Re: Using Processing for custom dashboard
 

If you do this please document it. I really like the processing language.

Re: Using Processing for custom dashboard
 

So can images be transferred via network tables, too?

Re: Using Processing for custom dashboard
 

I wouldn't transfer images in network tables. You could technically do some small ones, but why not do it more efficiently. As for the latency of network tables. The variables are written into the local table rather quickly, like in a millisecond or so. The update rate is used to determine how often modified values are replicated to other clients. This value varies by language, and the LV default is 100ms. If you wire up a different number, it will have a bit more overhead, but less latency. The other option is to call flush yourself, to force the update when something interesting happened, like you finished processing an image.

Other than the delayed updates, there shouldn't be much more latency than straight TCP communications.

Greg McKaskle

Re: Using Processing for custom dashboard
 

How exactly does that work? I've been looking everywhere on socket communication (which might be what you're talking about) to transmit mid-high resolution images at a high frame rate in real time. As of yet, we're not planning on doing any vision processing; just a GUI.