Disappointed

[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]