Multiple USB Cameras and USB port assignments

We have 3 Lifecam HD 3000 USB cameras on our robot, 1 plugged into the RoboRIO directly and the the other two via an unpowered USB hub (I don’t have the exact configuration readily available). Bandwidth issues aside, how can we assure that “cameraX” is always the same physical camera, since we are using cameraX to do vision tracking (Java)?

This was one of the last things we worked on prior to bagging/tagging our robot and we had to make a last minute SW change to which camera stream to feed into the vision tracking SW.

I had the expectation that assuming the HW / camera configuration stays the same, camera0 would always be the same physical camera.


(snippets):

UsbCamera camera0 = CameraServer.getInstance().startAutomaticCapture(0); 
UsbCamera camera1 = CameraServer.getInstance().startAutomaticCapture(1);
UsbCamera camera2 = CameraServer.getInstance().startAutomaticCapture(2);

pegVisionThread = new VisionThread(camera2, new Pipeline(), pipeline -> { //Was cam1!

Any thoughts or help would be appreciated!

Yeah, you would think that was the case, but no.

I believe those functions take a string argument which can specify the full path of the camera. To get the path names, you’ll need to ssh into the roborio, but I think you’ll want to use a /dev/v4l/by-path/* path if you want to guarantee a stable path name. I haven’t tried it this year, but that’s what we had to use last year with 3 cameras.

…this is all new to me and I’m not linux savvy, but I have been doing some research online…

If I understand you correctly, you are saying that if I can determine that each camera has a unique device name in the /dev/v4l/by-path/ on the roboRIO, I can simply use the proper path as the argument in startAutomaticCapture() and that should guarantee consistency ?

Exactly.

I should like to note that sometimes USB names-to-device relationships change at boot in /dev change because of udev.

So be aware that where you put one camera you may get a surprise and it may be a different camera after a boot. Kind of a problem if that boot happens between 2 matches or even during a serious power issue induced reboot.

Just be aware of this in case it happens to you.
Using by-path with udev to attempt static (persistent) naming may not always be enough to overcome this issue.

If you use the by-path name you’re much less likely to have that issue, whereas you’re pretty much guaranteed to have the issue if you use /dev/videoX.

Unfortunately, by-path is the best you have if you’re using the Lifecams. They don’t expose their USB serial number, so you can’t use that to identify the camera and create a static path via udev.

Previously we’ve contacted the 3rd party Linux support maintainer for this camera on the Linux platform and tried to get Microsoft in touch with them because there’s also contrast control issues on Linux that are much less an issue on Windows.

It’s not so much an issue from the 3rd party maintainer - Microsoft did something unusual with these cameras that makes them harder to use in Linux.

I bet the serial number is in there, but like the contrast control, the serial number simply doesn’t boil up the software stack to where you can use it.