Strange one-way/partial SmartDashboard communications issues

Technical Programming
#1

We are experiencing some very strange communications issues between the SmartDashboard and the Robot. I’m at a loss to explain/debug these as the programming/electrical mentor. Has anyone experienced these problems and have a workaround/solution? Searching the site has not revealed any similar symptoms being reported by other teams. I am hoping we are not unique here…

Background: We have a number of Win10 laptops that we use for driverstation control. These are all showing multiple/different/strange issues this year that were not evident last season.

  1. At some point, several laptops have developed a situation where they can receive SmartDashboard information, but cannot send info (changes to text boxes, clicking on start/stop buttons, etc have no effect). Some of these develop overnight with the computer being offline the entire time (So I can’t blame Windows Updates). Once present, the issue seems to be permanent. Turning Windows Firewall off entirely does not solve the issue.

  2. We use RobotBuilder for the basic skeleton of the robot code, and can use that to auto-generate some buttons to run specific commands from the SmartDashboard. Tonight, we hit a new strange issue: with no change to laptop software, robot code, or OS software overnight, a laptop that we were using the previous evening decided that it could send SOME SmartDashboard buttons to the robot, but others were completely ignored. Furthermore, we use the SendableChooser to select between various autonomous modes, and even if the Sendable was defaulted to a specific routine, that routine would not run when starting autonomous (though it worked fine 24 hours earlier). I am unable to explain why this would stop working. We didn’t even download a new program to the RIO, so the only conceivable change would have to be to the driverstation laptop… which doesn’t have general internet access and was shut down the entire time between our unbag times.

The obvious question is What DID change in those 24 hours? We only made one change to the system between the two unbag periods: We switched from a laptop running GRIP for vision recognition over wireless to the RIO, to our POR plan of a Kangaroo sending this information over an ethernet cable to the RIO. (both systems were hard-cabled to the camera on the robot. yes, we had a laptop strapped to the robot last night). Same info being transmitted, same GRIP config… but different physical computer and different transmission medium. But, if it worked fine over wireless, I’d expect it would work just as well over ethernet. I did not disconnect the Kangaroo from the radio to see if that solved the problem, but that’s the first thing we will try when we are able to unbag the robot in the pits at our competition Wednesday night. I don’t THINK we are exceeding any bandwidth limits simply because it was working ok through the radio 24 hours earlier. Still, it’s the only thing we changed… so it must be relevant. Why it would affect comms from laptop to DS, and why it would only affect SOME smartdashboard buttons… is completely beyond me.

Any thoughts from the FIRST Hive??
Thanks!

#2

One additional oddity I forgot about: two laptops over the last two weeks suddenly stopped receiving the SendableChooser from the robot. This meant that no “autononmous options” are transmitted to the SmartDashboard, and we simply could not choose the desired autononomous mode! This is a case of partial one-way transmission in the opposite direction. Again, other info transmitted to the dashboard (e.g. navx gyro heading) continue to transmit ok… so only SOME data is blocked. I have no idea why. I’m worried this will happen in a competition and we won’t be able to select the right autonomous mode before a match. Yes, we could hard-code it, or give a thumbs-down signal to the refs… but since we can’t seem to recover from it even with reboots, it becomes a serious issue if not hard-coded. this does not appear to be an mDNS issue since other info for the SmartDashboard does seem to get transmitted successfully.

#3

There was a recent upgrade to SmartDashboard, you may try to obtain that and see if it fixes your issue.

A tool you can use to get a better look at NetworkTables is the Outline Viewer, it will show you raw NetworkTables values as they really are and let you set them manually. It may give you some insight as to what’s happening (or not happening). You can connect Outline Viewer and SmartDashboard at the same time, so you could watch the values change (or not) as you do things on SmartDashboard to confirm what’s happening.

The Outline Viewer can be found in the same folder as SmartDashboard. Both can be downloaded separately from the Eclipse plugins however:

#4

OK, we have had your almost exact problem, with the Smartdashboard only displaying some things and not others. What is probably happening(but not tested) is that the Driverstation was left open. A reboot of the roboRIO was the only fix we could do that would remedy this. We have not used the latest Smartdashboard update. Sometimes, Smartdashboard is just picky. Maybe the robot was left on for a long time? Or, another thing that comes to mind is that the laptop Smartdashboard is desynced with the NetworkTable. Even though we have only run into this problem a few times, a fix would be nice for all these Smartdashboard problems. If anyone else has anything, I would also like to know.

#5

Thanks for the responses overnight!

I had downloaded the latest driverstation and wpilib/eclipse plugins to all the laptops we were using. I have some laptops that are not yet upgraded, and might try those to see if the older version has an issue… but I’m pretty sure we were seeing pieces of this even before those releases.

@virtuald, looking at the OutlineViewer is a good idea that I was too fuzzy to think of last night. It might give me a clue. At the very least, I might be able to overwrite data directly into the table to determine if it’s the table connection or the SmartDashboard itself that is losing the info.

I was rebooting the robot code frequently with program builds to debug, and that had no effect, so I suspect the problem is on the laptop side. I think I had rebooted each laptop at least once, but can’t be 100% sure (Things get a little hectic in a 2-hour unbag, despite our best efforts to be disciplined). I do know that my personal laptop, once it got into the “I can’t send anything” state, is persistent across reboots and even the wpilib/DS upgrade… which tells me that perhaps there is a Win10 component here. I will also try an older Win7 laptop when we unbag, to see if this is purely an O/S issue.

#6

It would really help if we could see your code. It’s possible you’re not calling / querying SD when you think you are?

My go to fix for SmartDashboard doing anything strange is to close the DS and SD, power down the robot, reopen the DS, reset SD, then power up the robot while tethered. This ensures the computer is connected to the robot during robotInit and should put everything in use back onto SD, though probably not where it is supposed to be. Then run through your various commands and whatnot in case anything is added to SD later than initialization. Then check everything, set everything that should be to Editable, change formatting, rearrange it all again, Save it (I don’t even know if Save does anything, it’s superstition to me), and see if it works as intended.

SD for me is sort of a necessary evil - too useful to get rid of, but too bug ridden and finicky to love.

#7

Chris, I’ll definitely give your procedure a shot. I didn’t tether at all during the experiments, which might provide a new data point.
The “misbehaving” code is a mix of auto-generated stuff from RobotBuilder plus the manually coded AutonomousChooser stuff in Robot.java.

The whole codebase is up on GitHub if anyone wants to take a look (try not to scream too loudly…):

#8

We have had similar SmartDashboard issues as you described. The biggest issue is not receiving the sendable chooser for auton selection. A solution that has worked for us is to select File->New on the SmartDashboard. You lose all the formatting and layout but everything seems to reappear and function.

Well said.

#9

THAT sounds like a fantastic idea, @Brian… I’ll bump that up to the top of the queue to try, as I have never attempted to completely delete the saved SmartDashboard data on any system. When I create a new one, do you happen to know the default name/location? I’d love to diff the old one and the new one to see exactly what changed.

Thanks for the suggestion!

#10

If you click Save, pretty sure it overwrites the previously stored path/name so use Save As and rename it to compare.

Earlier in the year, I changed the names of a few parameters posted to the SD in our code and then went into the SD xml file to update the names so the layout would be preserved. The buttons froze up as you described and I ended up starting over again.

#11

One other thing I see on a windows 10 laptop is that I must start the Smartdashboard before starting the DS. If the DS starts first, the sendable choosers sometimes do not show up. Starting the Smartdashboard first works great.

And if you are making code changes make sure to reboot the RIO and the FRC Dashboard and Smartdashboard at the same time to make sure you clear out the NetworkTables.