Disappointed

[Team3266Spencer]

Last season I had a few frustrations with the Java library. I feel very limited by the NI vision resources for image processing which may or may not apply to Labview and C++. Most frustrating was the disallowing of the Smartdashboard at competition evidently due to some network hogging issues with the Smartdashboard. Plus I struggled with constant crashing even after updates that were supposed to resolve it. This is disappointing because some of Javas best features are created by the Smartdashboard. Whenever I want to do something with the Smartdashboard now I feel discouraged to because I doubt its usefulness at competition. Maybe it wasn't for other teams but for us it was a pool of problems. I'm looking for someone to tell me we just have something wrong because I would really like to use the Smartdashboard.

[Arhowk]

Honestly, I think that the SmartDashboard was only built for debugging functions, as its competition usefulness is extremely limited. I attempted to use SmartDashboard at first, but what I ended up doing is just making a custom .jar and using a custom byte processor to send messages between the dashboard and the robot. This made customization and vision processing ALOT easier.

The LabView NI Vision resources are... well... underdeveloped. They're useful, but you can't debug anything, view threshholds, etc. WPIJavaCV is slightly useful, but it's not really up to par. I ended up using the OpenCV for Java built-in implementation to do threshholding than converted it into a BufferedImage and did the parallelogram detection by hand.

Unless 2014SD is alot better in terms of competition usefulness this is your best choice. You can't adjust font sizes, you can't add static labels, you cant use HTML formatting, the save/loading of layouts breaks often, the Preferences widget breaks the ftp server, theres no good vision processing widget (hm.. I should make one that would be awesome), you cant swap in and out of pages easily (i have over 8 panels that i switch between based on debug, experienced driver, inexperienced driver, etc.)

Also, if your having problems with autonomous, have you ever tried command-based? I wrote a short little segment of code (100 lines) that lets me do every autonomous (we had static 3disc, 3disc + pyra, 3disc + back, etc) in 10 lines or less.

[AllenGregoryIV]

When were you not allowed to use smartdashboard? We use it every event and have never had any major issues with it specifically.

We use it for both displaying information to the drivers and the ability to change some of the robots settings on the fly.

It was definitely designed to be used during competition.

[Arhowk]

Originally Posted by AllenGregoryIV

When were you not allowed to use smartdashboard? We use it every event and have never had any major issues with it specifically.

We use it for both displaying information to the drivers and the ability to change some of the robots settings on the fly.

It was definitely designed to be used during competition.

We weren't allowed to use it at Kettering, first event of the season. Never attempted to use them at the rest.

Exactly what information are you displaying? Last season, our drivers were the type that they didn't take their attention off of the field and relied solely on peripheral vision to check the dashboard and we couldn't get fonts big enough onto the dash.

Also, what settings? (Just curious). The only settings that we even came close to changing were Xbox 360 > Logitech > Dualshock and camera processing (which had built-in presets for different venues)

[Team3266Spencer]

We use command based and I'm surprised they didn't make you shut down your smartdashboard. Do you think you could help me with this custom dashboard of yours?

[AllenGregoryIV]

Originally Posted by Arhowk

We weren't allowed to use it at Kettering, first event of the season. Never attempted to use them at the rest.

Exactly what information are you displaying? Last season, our drivers were the type that they didn't take their attention off of the field and relied solely on peripheral vision to check the dashboard and we couldn't get fonts big enough onto the dash.

Also, what settings? (Just curious). The only settings that we even came close to changing were Xbox 360 > Logitech > Dualshock and camera processing (which had built-in presets for different venues)

We always displayed the speed of each of our 3 shooter wheels. We also have small things like a small disabled toggle that toggles while the robot is disabled to easily show the drivers that the smartdashboard hasn't crashed.

The dashboard was used mostly by the operator not the base driver. They could adjust the shooter speeds for each of the 3 wheels, and also the speeds the wheels ran when they were in collection mode. We had a couple things that ran on timers, like how long our flick motors ran to shoot out each disc. All of these setting could be adjusted pre-match or during the match.

One of the things that helps make sure you don't have any lag with the dashboard is to limit the number of times you update it. We have two update dashboard methods that get run based on the system clock. One runs every .2 secs and the other every 2 secs. That way we aren't trying to constantly stream information. 0.2 seconds is plenty fast for most things.

[Joe Ross]

Originally Posted by Arhowk

Unless 2014SD is alot better in terms of competition usefulness this is your best choice. You can't adjust font sizes, you can't add static labels, you cant use HTML formatting, the save/loading of layouts breaks often, the Preferences widget breaks the ftp server, theres no good vision processing widget (hm.. I should make one that would be awesome), you cant swap in and out of pages easily (i have over 8 panels that i switch between based on debug, experienced driver, inexperienced driver, etc.)

In case you didn't see it, smartdashboard is being completely rewritten for 2014: http://www.chiefdelphi.com/forums/sh...50&postcount=4

[connor.worley]

We haven't been able to get it to work reliably in C++ without NetworkTables dropping dead every so often. After more issues this season we've given up on it, the issues seem to be caused by SmartDashboard/NetworkTables/some combination of the two, not any particular language.

[Arhowk]

Originally Posted by Joe Ross

In case you didn't see it, smartdashboard is being completely rewritten for 2014: http://www.chiefdelphi.com/forums/sh...50&postcount=4

I did know that but ugh, javafx? nasty.

Originally Posted by Team3266Spencer

We use command based and I'm surprised they didn't make you shut down your smartdashboard. Do you think you could help me with this custom dashboard of yours?

The custom dashboard isn't much but some Swing architecture combined with a OpenCV for Java rendering agent, if you need help with any I can help. Attached is a pic of the nicer dashboard and the not-so-nice dashboard with a bigger screen. I can't give you the exact FPS on the processing, but its decent. Not the best because I do the primary step of processing (blobfinding) in my own Java code so it gets inefficient. (Though I benchmarked it and it was only getting like 5ms downtimes so idk)

Originally Posted by AllenGregoryIV

We always displayed the speed of each of our 3 shooter wheels. We also have small things like a small disabled toggle that toggles while the robot is disabled to easily show the drivers that the smartdashboard hasn't crashed.

The dashboard was used mostly by the operator not the base driver. They could adjust the shooter speeds for each of the 3 wheels, and also the speeds the wheels ran when they were in collection mode. We had a couple things that ran on timers, like how long our flick motors ran to shoot out each disc. All of these setting could be adjusted pre-match or during the match.

One of the things that helps make sure you don't have any lag with the dashboard is to limit the number of times you update it. We have two update dashboard methods that get run based on the system clock. One runs every .2 secs and the other every 2 secs. That way we aren't trying to constantly stream information. 0.2 seconds is plenty fast for most things.

3 shooter wheels? Why wouldn't they be the same? Also, if your showing them on the dash theres a large chance your controlling them via pid so it would be quicker to just display a green/red image if they are ready. Again, why are you being forced to change constants? The constants used on our robot for PID controlling were pretty much universal once kettering hit. For the SD, it seems like it would be easier to just intercept the putData calls and insert them into a flush buffer :/

[AllenGregoryIV]

Originally Posted by Arhowk

3 shooter wheels? Why wouldn't they be the same? Also, if your showing them on the dash theres a large chance your controlling them via pid so it would be quicker to just display a green/red image if they are ready. Again, why are you being forced to change constants? The constants used on our robot for PID controlling were pretty much universal once kettering hit. For the SD, it seems like it would be easier to just intercept the putData calls and insert them into a flush buffer :/

Every robot is different. Getting a linear shooter configuration to have reduced wheel slippage at each wheel requires individual control of the wheels to get the most energy transfer. We also changed speeds due to wheel wearing of the course of an event. We also collected with our shooter wheels so those speeds needed to be changed. Obviously this wouldn't need to happen with every robot but it did for ours. We found a system that worked for us that got us a finalist at Razorback and a trip to IRI so I think it came out alright.

[byteit101]

Originally Posted by Arhowk

I did know that but ugh, javafx? nasty.

Firstly, I agree with your "ugh,nasty" for JavaFX *the language* from JavaFX *the toolkit* 1.x. However, JavaFX *the toolkit* 2.x is a toolkit that you can program in any JVM language, and is much better which is what 2014 SmartDashboard uses. Very handy.

Re the original question, I would have to agree with you for the current 2013 SmartDashboard. When SmartDashboard originally came out, I was the creator of the ZomB Dashboard System (search around for details about that) and saw absoloutely nothing interesting in it aside from the fact that it could run on Mac + Linux whereas ZomB was C#+WPF and windows restricted. If you wanted a totally AWESOME dashboard before 2012, ZomB was it. I was then a senior, and got accepted to WPI (Woo!), and am bringing my experiences from ZomB to SmartDashboard, so expect more awesome soon...

Side rant and strong opinions about GUI toolkits:

I originally wrote ZomB in WinForms, then picked up a book about WPF and was totally blown away, so re-wrote the UI side of ZomB in WPF. To this day, I feel as if WPF is the best engineered UI toolkit i've seen. I left Windows shortly after graduating high school so looked at Java stuff a bit. Swing felt like a worse WinForms and had many things that I felt were odd, in addition to its horrible ugly default look. Then I saw JavaFX and although it seems like a "quick! do WPF! but in java!" sort of thing and 2.x is missing some interesting things, it does have many of the good things I saw in WPF.

[/rant]