Shuffleboard causing high CPU usage, packet loss

The Shuffleboard/SmartDashboard have always caused high PC CPU/RAM usage for us, even when the window is sitting idle and the computer is not connected to the robot. I haven’t really had a reason to complain about this until now, though, as it is now causing crippling packet loss during robot operation. During operation yesterday, we noticed that, after examining log files, we were having spikes of 100% packet loss that were making the robot difficult to drive. Today, after some testing, it would appear that the packet loss was minimized after closing out the Shuffleboard window.

I noticed a lot of people talking about packet loss on CD were linking it to auto-updaters running in the background, although we don’t appear to have any. What options do we have besides not using the Shuffleboard at all? Is the issue possibly linked to something else?


If you have any System.out.println commands, those are also things that look innocent but actually cause major grief for communication during competition.

Smartdashboard writes aren’t as bad, but we did have some grief with those last year at our first competition.

We don’t have any System.out.print statements. We’ve used them before for brief debugging purposes but we have none in our program right now.

We have been hitting a few issues with Shuffleboard.update() recently. For robots that have been on for 15-20 minutes, calling update() every 1000ms or so has run our JVM’s out of memory. Though it probably does not help that there are ~150 data points going to Shuffleboard in Test Mode.

We’ve started to profile the JVM on the robot just to make sure this will only happen in Test mode (which is the only mode where we try to “dump” all of the data to various SB tabs). Results are still preliminary right now, but I’ll post back when I get more info.

This is interesting. We had this same issue during the preseason on our slightly underpowered driver station laptop. I removed Adobe creative cloud from the laptop and the usage went down, nearly solving the issue. I then added 8gb of RAM to the laptop and the packet loss was solved.

Another thing that helped was limiting the number of unnecessary printouts at any given time. I don’t know if that was the issue in our case, but it shouldn’t hurt.

Is that an OOM on the robot side, or driverstation side? Also be aware that IterativeRobotBase calls Shuffleboard.update() every loop internally so there’s no need to call it yourself

The most obvious suspect is graph widgets - these things are total memory and CPU hogs if you have a lot of data, or just physically large graphs.

Older versions of shuffleboard had issues with memory use related to updating recording files, but this was fixed prior to the 2019 season. I’d be surprised if you were using a 2018 version, but it doesn’t hurt to check - just press F1

1 Like

OOM on the robot side.

Just wanted to give an update on this in case other teams are experiencing this issue.

Our final competition bot has been driving and we’ve continued to notice driving difficulty. After using Shuffleboard on this bot for about 4 or 5 days, I decided to close it out and switch back to SmartDashboard, the dashboard solution we’ve used in years prior. It completely cleared up the lagging controlling behavior we were experiencing before and everything is operating perfectly now. The downside is that it’s not nearly as pretty or dynamic as Shuffleboard, but I’m willing to live with it if it means the robot drives better.

On this note, though… does this happen to anyone else and why exactly does it happen?


Having similar issues with controlling robot. Random commands being sent. This is the first year we’ve used Shuffleboard. Will try closing SB and see if it clears our problems as well. I’ll try to report results tonight.

1 Like

With the robot enabled and sending changing data to SmartDashboard, bring up 2 graphs that use updated data every cycle, and set them to be 2x3 in height/width. Then bring up task manager. Candidates for continuous updates this year are flywheel sensors and current monitoring of the flywheel.

The JVM for shuffleboard will start to hog system memory after a few minutes, which then causes everything else in the system to slow down.

This is on my list of things to investigate over the summer, since fixing memory leaks is what I used to do as part of a team on a gigantic Java application.

What are you displaying on Shuffleboard? Certain displays in Shuffleboard can cause lag, especially on older computers. The biggest example would be graphing a value over time.

We’ve had these issues for the last couple of years with shuffleboard on our underpowered drivers station laptop. It seems to work fine for longer on our higher powered programming laptop, but will eventually bog it down as well. It sure does smell like a memory leak to me.

It’s why we keep rolling back to smartdashboard even though it’s not nearly as nice.

Graphs are a giant memory and CPU hog. A group at CERN has built a JavaFX library for realtime data logging that seems to be much faster and much more efficient than the builtin charts. I’d like to use that library instead, but I have very limited time and probably won’t be able to make that change myself

Cool, I’ll look into it from that perspective then. JavaFX in general performs much better with modern graphics cards so it’s great to hear there are other options out there.

Even Gerrit Grunwald’s graphs/gauges have issues over extended periods of time, so I feel your pain.

We use smartdashboard so I haven’t seen lagging during driving. But with that said. In testing Shuffleboard I have seen it peg out our CPU. Just having it open causes the CPU fan to kick into high gear. So I can see where your coming from here.

Sorry for your difficulty using this… But thank you for the heads up.


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.