New SmartDashboard installer

[BradAMiller]

For those trying to use the camera plugin with the SmartDashboard and having crashing problems...

Can you try the newest version of the SmartDashboard installer here:
http://firstforge.wpi.edu/sf/frs/do/.../frs.installer

It has a few bugs fixed. There seems to still be a memory problem that we're trying to track down, but it seems to run for about 20 minutes without problems. Please make sure you are doing all the things described on this web page (32 bit java, setting IP address, etc.)

http://wpilib.screenstepslive.com/s/...sion-installer

Also, you should make sure that you are not running 640x480 at 30FPS or you will overrun the bandwidth for 2013. Remember that the field will limit each teams available network bandwidth to 7Mbs. We were testing at 320x240. I believe the FRC Bridge Configuration Utility will do the appropriate Quality of Service (QOS) settings to your DLink access point to simulate the field bandwidth throttling. It is described here:

http://wpilib.screenstepslive.com/s/...o-for-home-use

This is only for those who are using the SmartDashboard camera plugin to display the Axis camera on their SmartDashboard screens. This doesn't effect the SmartDashboard.jar file for anyone using it only for displaying data or Test mode objects.

Brad

[Mr. Lim]

Thanks Brad!

We will be trying this new release ASAP.

We were having some difficulties connecting to a RoboRealm video source using the camera widget, and found a partial solution here:

http://www.roborealm.com/forum/index.php?thread_id=4781

Steven from RoboRealm mentioned that with the bandwidth limitations this year, the camera widget might need to handle streams lower than 25 fps without cutting out to the pink screen.

Thanks for all your hard work! SmartDashboard has really made a big difference to our team these past few years...

[jwhite]

Originally Posted by BradAMiller

For those trying to use the camera plugin with the SmartDashboard and having crashing problems...

Can you try the newest version of the SmartDashboard installer here:
http://firstforge.wpi.edu/sf/frs/do/.../frs.installer

Brad

We tried that code over the weekend, and it did now seem to work with an M1011 that wasn't working on Saturday (we replaced the 206 in frustration, perhaps unnecessarily :-./).

However, we are still getting worrisome instability. If we put a boolean to a network table, we get a socket read exception error that seems to crash the robot code as well. That seems consistent. We see that exception from time to time 'normally', but couldn't pin it to any specific problem.

Cheers,

Jeremy

[bob.wolff68]

Jeremy,
I'm going to read some tea leaves here on your PutNumber crash with a boolean and I may or may not hit the mark... we saw an issue (and have reported it) which would crash smartdashboard/network tables and the robot consistently...

1) int i = 5; SmartDashboard:utNumber("MyLocation", i); // This works and must be done once to induce the crash - put a non-boolean into a named location...

2) bool i = false; SmartDashboard:utNumber("MyLocation", i); // This crashes consistently - the change from an int to a bool leaves someone with the "wrong expectation" of what type will actually be used.

// And here's the fix... don't re-use "MyLocation" with different types - in fact if you want to be sure, make sure you name your locations based on what type they will wind up receiving - "bool_MyLocation" and "int_MyLocation"
3) bool i = false; SmartDashboard:utNumber("differentLocation", i); // This works just fine.

bob

[jwhite]

Originally Posted by bob.wolff68

Jeremy,
I'm going to read some tea leaves here on your PutNumber crash with a boolean and I may or may not hit the mark... we saw an issue (and have reported it) which would crash smartdashboard/network tables and the robot consistently...

1) int i = 5; SmartDashboard:utNumber("MyLocation", i); // This works and must be done once to induce the crash - put a non-boolean into a named location...

2) bool i = false; SmartDashboard:utNumber("MyLocation", i); // This crashes consistently - the change from an int to a bool leaves someone with the "wrong expectation" of what type will actually be used.

// And here's the fix... don't re-use "MyLocation" with different types - in fact if you want to be sure, make sure you name your locations based on what type they will wind up receiving - "bool_MyLocation" and "int_MyLocation"
3) bool i = false; SmartDashboard:utNumber("differentLocation", i); // This works just fine.

bob

Yes, I think your instinct is sound; I was suspecting something along those lines. Although note that our case uses PutBoolean, and I'm not sure that the programmers were reusing variables. We're going to try playing with this a bit, and seeing if adding an exception handler around the PutNumber calls prevents the robot code from dying at the least. Losing your camera is bad, losing your whole robot is catastrophic...

Presumably, there is some xml or other config file on the Driver Station somewhere that can be deleted to 'forget' that information, right? I'll have them try to find that and see if deleting it eases some of this pain.

One of my programmers has a hunch that sending too many variables, too fast, is another source of trouble. I think that's just superstition on his part, but I thought I'd mention it to anyone else losing hair over this.

Cheers,

Jeremy

[jwhite]

Originally Posted by BradAMiller

It has a few bugs fixed. There seems to still be a memory problem that we're trying to track down, but it seems to run for about 20 minutes without problems.

For some reason, even though I read that several times, it never really sunk in. We were just now puzzled as to why our network tables code was crashing, and we failed to put 2 and 2 together. I suspect your 20 minutes figure may be related to traffic; we were also sending an update at a high frequency, and I wonder if we shortened the life span some.

So now the programmers are going to close and restart the smart dashboard before each test...

Figured I'd post in case it saved anyone else a few hairs.

[mitchellweb1]

All network table nodes (Smart Dashboard, LabView Dashboard, The robot) will remember all keys and their most recent values. When they disconnect and then reconnect their values will resync. This is so that if comm is lost at some point then any values which were set while the robot was disconnected will still be sent to the robot on reconnection. This has the consequence that you must close all nodes (Dashboard and robot) at the same time to clear all values. Network tables will throw a TableKeyExistsWithDifferentTypeException if you try to put a value with a different type than the one currently stored.

[bob.wolff68]

The xml file for Smartdashboard is in the install directory for smartdashboard which is usually c:\program files\smartdashboard\ ... that is the one you'd want to hand-edit or blow away, but as was noted...do that with the robot powered OFF and the smartdashboard shut down so that the re-sync of network tables doesn't bite ya. It has quite a good 'memory'

bob

[mitchellweb1]

instead of deleting the xml file you can just do View > Remove Unused after restarting SmartDashboard with the robot off and that will clear all of the widgets

[jwhite]

Thanks for the info; we'll play with that tomorrow afternoon (our solution was to install on a whole different driver station, that got us nice and clean <grin>).

We haven't tested bob's theory yet, but I just noticed something odd. In reviewing our code on bitbucket, I saw that the 'I' in our variable string was apparently a Unicode character of an I with double umlauts. It appears that perhaps a student accidentally got WindRiver to inject an unusual character into the string we were setting as a boolean.

So that may be another source of the crash we were seeing.

Just to improve future google searches, when we see these crashes, we get an exception message Error on FDIO read, and then hard to read error messages. Which is explained well here:
http://www.chiefdelphi.com/forums/sh...d.php?t=113071

Our behavior from there is not clear; it seems as though sometimes we lose all robot function, and sometimes the robot continues to work.

Does anyone have a sense of whether or not adding a try/catch block around network puts would help avoid a robot shut down?

Cheers,

Jeremy