I’m trying to track down this issue and I havent found anything yet. I have a Limelight 3G running on our robot and, on the web dashboard, the camera stream is nice and fast and responsive. When I add a Camera Server Stream Viewer to SmartDashboard, exact same result from there. When I add a Camera Server/Stream widget to Shuffleboard or Elastic, its not nearly as responsive or up-to-late. The latency seems inconsistent at all times. This seems to only affect the camera stream, as the AprilTag target data is super fast and immediate as expected. Its not a super critical issue, but it would be nice to be able to see what the camera is seeing from the dashboard.
Check your driver station PC Task Manager/Performance/Wi-Fi usage and see if you are trying to force more data through the 4MBPS throttle on the robot radio with the second stream.
I checked Task Manager and it showed Elastic using no more than 0.9 Mbps. Now that I read your response again, I realize that I should have checked the overall PC network usage. I won’t be able to test again until next week, but for now I’ll clarify some things.
What I have confirmed so far:
No matter what other streams or programs are open, the SmartDashboard or web streams are always fast like they should be. I even opened a web stream on the laptop and connected my phone to the robot and opened another stream there, and both streams were all good. Among all this, the Elastic stream was still just very choppy. The latency indicator in Elastic didn’t show anything unusual, I think it was around 4 ms. I do find it interesting how it works fine in SmartDashboard but not in Shuffleboard or Elastic. Perhaps they use a different protocol or something?
It’s interesting that the lag only seems to happen in Shuffleboard and Elastic. I’m not sure what Smart dashboard does for camera stream processing, but I don’t think it would be drastically different.
One recommendation I have is to try decreasing the quality, resolution, and fps of the camera stream and see if it improves, if not, then it’s likely an issue with Flutter image processing and rendering, as it’s not natively supported and has to manually stream and decode the incoming images.
Let me know what fixes you find, since I’m open to finding ways to optimize camera streams more
Camera settings, camera server settings, latency, and bandwidth all interact in complicated ways that are not obvious. Last year I wrote up what I’d managed to figure out about it. Unfortunately it doesn’t cover Elastic or off-RIO cameras but it may provide some clue about what you’re seeing and how to make adjustments. CameraConfiguration/README.md at main · chauser/CameraConfiguration · GitHub
One concern I’ve had about Elastic is that it doesn’t provide any independent camera controls – it just uses the settings from CameraServer so you have to figure out how to get what you want there. Shuffleboard and SmartDashboard (to some extent) allow you to configure camera stream properties from the dashboard side.
I actually thought it might be the opposite problem. Pretty sure Elastic added options to change the camera settings in 2025. I’m wondering if Shuffleboard/Elastic are setting it to some setting that requires reencodinf and thus slowing it down.
I buy all of that. I have no hands-on experience with Elastic and was just looking at the documentation, which could have been for an older version. When I was writing things up last year I found it very helpful to figure out what the actual camera settings were as well as the camera stream settings and then try to puzzle out the implications for performance. One thing I learned was that cameras typically accept settings without objection that they are not capable of delivering. What they do instead is unpredictable. But I don’t know whether that applies to Limelights or to this situation.