SmartDashboard Poll

[JefferMC]

During some matches on Friday at Palmetto we had, shall we say, "impaired" control of the robot, sluggishness, etc., even while the network monitors showed nominal trip times (<40 ms). We provided our logs to the guys from NI and were asked by several "survey takers" during Friday and Saturday: "Do you (a) have a camera, (b) use SmartDashboard?"

By Saturday morning the official suggestion was to disable the SmartDashboard application on the driving PC, which we did and all "iffy" control problems went away. I've spent much of Sunday thinking about alternate ways to provide configuration information to the robot, and wondering out who make up for the lost feedback mechanisms.

Yesterday, a mandatory update was out for WindRiver C++ to correct SmartDashboard issues. I'm creating this post as sort of an informal survey of my own:

How comfortable are you with continuing to use SmartDashboard during competitions?

[rsisk]

Unofficial word at CVR was the c++ libraries used by the smart dashboard were causing many of the field headaches. Once code was replaced (sorry, used Labview so I don't know the details of the change) field issues were gone for the most part.

[Alan Anderson]

Which "SmartDashboard" meaning are you asking about? Do you want to know if we use the Network Tables implementation for communication of values between the robot and the Driver Station computer? Or do you want to know if we use the Java program having that name? You're asking in the C++ subforum, so I'm not sure whether you care about teams using SmartDashboard variables with the LabVIEW Dashboard.

The name collision between protocol and application is unfortunate and confusing.

[BradAMiller]

There was an issue with the C++ NetworkTables implementation that only appeared when there were several robots all updating a number of variables very frequently. This usually occurred with SmartDashboard but would also fail with the default LabVIEW dashboard and NetworkTables or any other NetworkTables client program on the robot network.

There is a new version of WPILib that will be required for C++ teams that has been posted here:

http://firstforge.wpi.edu/sf/frs/do/...ate_rev_362 2

Brad

[Jared Russell]

Did this issue also affect Java teams? We had a couple of instances where SmartDashboard ceased to update, despite the fact that we still had (responsive) control of the robot.

[Mark McLeod]

I saw the issue with a couple of Java teams.

[Brian Selle]

We had one FMS issue against 16 when we both had intermittent control (16 was sent spinning in place, we were surging in a circle). We use Java Smartboard and I believe 16 uses the C++ version. The FMS team were thinking that we exceeded our bandwidth because of too high a camera resolution displayed on the SmartDashboard. That didn't ring true because I had set our camera to 320x240 using the axis camera tool. Nevertheless, it is probably a good idea to check your camera settings.

[Jefferson]

To be clear, it wasn't us who thought that your settings weren't right. Greg came to our pits to check our camera settings as well. We were in the middle of trying to figure out how WE could have caused the weirdness we saw that match. The robot was very unresponsive, leading to over corrections in steering, and then it looked like the motor outputs got stuck for a couple seconds.
Our DS logging showed significant communications issues, but we don't know who was at fault... could be FMS as far as I know. We only had issues in that one match.

To add a little insight: we have a few dozen variables on the dashboard, but they only update when a specific joystick button is pressed. This allows us to have all the trouble-shooting tools we could need in the pit, while not overloading the network during a match. All we have running during a match is the camera feed.

[Brian Selle]

Originally Posted by Jefferson

To be clear, it wasn't us who thought that your settings weren't right.

Sorry I edited my post to make it clear... it was just a theory from the FMS team. Greg came over to our pit as well and I showed him the setup. We did have a lot of real-time parameters updating for debugging purposes on the SmartDashboard (about 30 or so)... hopefully that's wasn't it. To be safe, I'm going to change the setup so only the camera feed is running continuously during the match.

What's odd is how 2 teams lost/regained communication at the same time... and the idea that somehow one team could mess up another team. I thought that was the whole reason for limiting everyone's bandwidth.

[JefferMC]

I refer both to the Java application that runs on the Control Computer and to the class of the same name that communicates with it via NetworkTables. That they use the same name instantly draws the connection between them in ones mind, and I can't believe that wasn't intentional.

We disconnected the camera (configured at a 1.7 Mbps consuming 320x240x30x30%compression) and quit running the Java application as I was advised by the FIRST personnel. This resolved our issues for the remaining matches.

I specifically asked the FIRST representative if I needed to remove the SmartDashboard class calls in my code and the answer was that to stop running the Java application was sufficient. Again, this representative was explicit in making sure I was talking about Brad Miller's Dashboard vs. any other Dashboard application.

Okay, yeah, maybe I should have posted this in the common Programming forum. I sorta forgot that this feature was common with our Java friends.