Quote:
Originally Posted by bdaroz
We re-tooled much of the CameraServer class in C++ ourselves in order to switch between two USB cameras on the RoboRIO (ugh, bandwidth). In general, the whole class just seemed poorly written and way too touchy.
|
Yes, we did exactly the same thing for the same reason, although last year we only wrapped the CameraServer class to switch feeds. This year, we made our own version of it, primarily to get around the bug that rod@3711 complained about.
The student who did that fix
posted his code on TeamForge (we couldn't figure out how to formally submit it).
The cause of the bug is trivial -- when the CameraServer on the robot parses a request for a frame from the client (e.g. SmartDashboard running on the laptop), it expects a packet with a twelve octet header -- representing three 4-byte integers, the 2nd of which must be -1, indicating hardware compression (which is the only option supported). It reads this packet with:
Code:
if (read(conn, &req, sizeof(req)) == -1)
and then a few lines later checks:
Code:
if (req.compression != kHardwareCompression) ...
Unfortunately, about 90% of the time, the request from the SmartDashboard or the SFX Dashboard (but apparently not the LabView dashboard! -- likely due to different timing) is sent in two packets -- the first packet containing only two bytes, and the second containing the remaining 10 bytes. The
read call above asks for however many octets there are at that instant and doesn't make any effort to read the octets that come later. So the req.compression word it's comparing to hasn't even been read yet and is thus zero, so the call fails.
keco195 -- if you're using the (default) LabView dashboard, this isn't your issue, and I apologize for hijacking your thread!