We have been seeing problems where cameras are not displaying to dashboards under FMS, although they do work back in the pits. Particularly this is with Labview programs.
I have a strong hunch that the FMS is blocking the video streams on ports 1180 to 1190. This hunch is based on a C++ team experiencing the same problem, but they solved it by switching their MPEG stream to port 5800.
Does anyone know how to change the MPEG port on a Labview program? Both on the Labview/roboRIO side and the dashboard?
Same here, except weirdly it worjed at first but then due to connection issues (something at the high school was messing with their system), they messed with our wireless config a bit before they found out the real issue, after they did this i could no longer see the mjpeg stream (using the url http://raspberrypi.local:1185/?action=stream)
The problem seems to occur when the roboRIO can’t connect to the driver station immedietly after startup. If you don’t have the updated VIs, a workaround is to turn on your robot on the field, then walk back to your driver station and hit the “reboot roboRIO” button.
You can actually find an extremely similar issue documented earlier. We are dealing with it now as well. With everything set up correctly, the dashboard will NOT display the video until the RoboRio is reset. Rebooting from the driverstation does not work - pushing the button on the roborio does.
We’ve verified that even when experiencing the problem, the robot is getting the stream correctly from the camera because we can probe the wires (running the code rather than deploying it) and see the images.
There’s been conjecture in other places that it’s a problem with the MDNS resolution.
Unfortunately we’ve been too busy to go hard code our IP addresses in all the robot .vi’s. Perhaps will have time Saturday. We are already running static IP addresses on everything because we’ve seen MDNS problems before field-side.
In the new camera server for LabVIEW, at code start, the server would ask for the roboRIO’s routable name and publish it as a portion of the camera server URL for USB cameras. During beta, we did not hear any issue and didn’t see any issues in our testing.
Then, one day near the end of build season, using normal cables, I noticed that this wasn’t working and the NT value was “localhost.localdomain”. It seems to be a race condition. I made a quick change to the code, but it wasn’t pushed out as a mandatory change since nobody was complanining about it. For some reason, it seems to happen very frequently on the field. I gave the fixed code to a few teams at the regional I was attending and shared them with FIRST so they could be made available to CSAs if needed.
This issues was not introduced by the week 1 DS update, and only affects the camera server.
The fix is easy and safe and will be made available in an update later today. Sorry it wasn’t caught in time to be fixed before the season began.