Problems with three cameras

[vScourge]

We also had three cameras, connect to an RPi2, and hit the same device-swapping issue at some point. One of our programming students came up with a workaround that involved hard-coding the serial numbers of each attached camera. I'll see if he can post here or summarize the process for me to pass on.

[techhelpbb]

Just to be clear:

Your team is streaming 3 cameras at the same time?
Instead of switching between the cameras?

This would be good to read:
http://unix.stackexchange.com/questi...n-after-reboot

[virtuald]

Originally Posted by techhelpbb

Just to be clear:

Your team is streaming 3 cameras at the same time?
Instead of switching between the cameras?

Technically, streaming 2 cameras, and consuming from the other (but not streaming the results).

This would be good to read:
http://unix.stackexchange.com/questi...n-after-reboot

That looks exactly what I'm looking for, I'll play around with it on a RoboRIO tonight.

[vScourge]

Cool, I believe that's the method we used.

[adciv]

Heads up from 836, we had some issues with the ms cameras too. Not sure why, but colors were changing on us in some cases. I plan to go back to the axis for Champs and investigate the usb cameras more over the summer.

As to the question of running multiple cameras, we wrote some beta code from scratch. I'll send you some system calls that let you track cameras by usb port.

[virtuald]

Originally Posted by techhelpbb

This would be good to read:
http://unix.stackexchange.com/questi...n-after-reboot

Hm, so it definitely looks like the lifecam devices don't have serial numbers or unique identifiers of any kind on them. There are symlinks setup at /dev/v4l/by-id and /dev/v4l/by-path. As you might imagine, the by-id symlinks are useless (only one appears even with multiple devices plugged in), but the by-path symlinks appear to be related to the position on the USB hub, and the information I've found appears to indicate that it should be a stable path.

Initial experiments on a roborio with a hub indicate that the by-path positions are indeed stable across device insert/removals and reboots. I'm not 100% sure of the best way to test this, but I'll add the information to mjpg-streamer's documentation anyways.

[bdaroz]

We were using three cameras on our robot this year (Forward drive, intake alignment, and reverse). They were spare HP cams the school had lying around, all identical. They also didn't have any identifying characteristics from the USB side of things and the RoboRIO would somewhat randomly assign them cam0 cam1 and cam2.

What we did was to use the SmartDashboard to set the camera names and the code that toggled the camera feeds used those values. Took an extra 15-30s once FMS came up on the field to switch through the cameras and make the settings changes, but it worked fine from there on.

[techhelpbb]

Originally Posted by virtuald

Hm, so it definitely looks like the lifecam devices don't have serial numbers or unique identifiers of any kind on them. There are symlinks setup at /dev/v4l/by-id and /dev/v4l/by-path. As you might imagine, the by-id symlinks are useless (only one appears even with multiple devices plugged in), but the by-path symlinks appear to be related to the position on the USB hub, and the information I've found appears to indicate that it should be a stable path.

Initial experiments on a roborio with a hub indicate that the by-path positions are indeed stable across device insert/removals and reboots. I'm not 100% sure of the best way to test this, but I'll add the information to mjpg-streamer's documentation anyways.

Could put a queue in the image (dots on lens or card in field of vision with image or color you could detect with code) or put a relay on the USB wires and connect the cameras one at a time then check the relay output against the device names that appear.

Does this help?
http://superuser.com/questions/74803...ng-usb-devices

[virtuald]

Originally Posted by techhelpbb

Could put a queue in the image (dots on lens or card in field of vision with image or color you could detect with code) or put a relay on the USB wires and connect the cameras one at a time then check the relay output against the device names that appear.

Does this help?
http://superuser.com/questions/74803...ng-usb-devices

That user seems to have a similar problem, namely that there is no serial number. The answers seem to confirm that the by-path identifier will be stable across reboots, so I think I'll go with that until it can be shown that it won't work.

Unfortunately, it looks like at the moment OpenCV won't allow using devices other than /dev/videoX. I've patched OpenCV and pushed a pull request to the OpenCV repo, hopefully they'll take it and it'll work in 3.2.

[Greg McKaskle]

By the way, NIVision does allow you to open the UVC camera in any mode that it enumerates. The WPILib VIs parse and compare the size and framerate. The DB in HW mode uses the JPEG mode while the SW uses YUV and compresses with the roboRIO. I don't have a ton of experience with multiple cameras, but NIVision enumerates and attempts to keep the cameras in order and returns lots of device info to validate.

This, by the way is the acquisition lib, called IMAQdx, and not the processing lib.

Greg McKaskle

[virtuald]

I've posted the information I'm aware of and various information on the mjpg-streamer notes on the roborio-packages page:

https://github.com/robotpy/roborio-p...t-device-paths

[Ben Wolsieffer]

Originally Posted by virtuald

Unfortunately, it looks like at the moment OpenCV won't allow using devices other than /dev/videoX. I've patched OpenCV and pushed a pull request to the OpenCV repo, hopefully they'll take it and it'll work in 3.2.

To work around this problem, we manually resolve the symlink and parse the index from the resolved filename (/dev/videoX), which is then passed to OpenCV.

[virtuald]

Originally Posted by lopsided98

To work around this problem, we manually resolve the symlink and parse the index from the resolved filename (/dev/videoX), which is then passed to OpenCV.

Nice! Well, you won't have to do that anymore if you apply my PR to your opencv build.