Open gavanderhoorn opened 1 week ago
gavanderhoorn
commented
1 week ago I've posted this here in the zivid-ros repository, but any resulting CDI spec would not be ROS-specific at all.
It would be useful even if just using the Zivid SDK 'natively', without any ROS involvement.
apartridge
commented
1 week ago Hi @gavanderhoorn. Thanks for reporting this issue. It does seem like a CDI wrapper for Zivid One+ cameras would make sense. I wasn't aware of this feature. However, note that Zivid One+ has reached its end of life for future improvements and SDK upgrades, the last SDK to support it was 2.11. One+ will going forward only receive updates for critical bugs/fixes/security issues, when relevant. So for this reason we will not be able to prioritize this improvement for One+.
You are correct that One+ will enumerate a few USB devices. These USB devices below (vendor+product id) are being used by One+. I used lsusb with and without camera connected, to make this list. Hopefully these is sufficient for making the spec. Let me know if you need additional info.
0e70:001f
0451:8025
0483:a26b
0451:6401
0451:8027 thanks for your reply.
note that Zivid One+ has reached its end of life for future improvements and SDK upgrades, the last SDK to support it was 2.11.
that's probably true, but we still have these devices, so I have to get something to work :)
You are correct that One+ will enumerate a few USB devices. These USB devices below (vendor+product id) are being used by One+. I used lsusb with and without camera connected, to make this list. Hopefully these is sufficient for making the spec. Let me know if you need additional info.
0e70:001f 0451:8025 0483:a26b 0451:6401 0451:8027
thanks. We'll see whether this is sufficient.
tl;dr: it would be greatly appreciated if Zivid could make a CDI (Container Device Interface) spec available for USB-based Zivid cameras to facilitate passing them through to containers.
original: for a project in which we use a Zivid One Plus M, we're trying to host the ROS driver (and required/related Zivid SDK) in a Docker container.
The camera is a USB device and actually enumerates quite a few devices, all of which seem to have to be available for the driver/SDK to work correctly (if we understand things correctly). The typical approach with Docker would be to pass device nodes to containers using
--device(or sometimes as bind-mounts of actual device nodes).As it's not completely clear which devices belong to the Zivid camera, we're currently passing
/devitself to the container. While this works, it's not very nice, as it pokes a big hole in the isolation typically offered by containers. It's also not always possible, either due to security concerns or other logistical barriers.The container community has come up with a specification (CDI, the Container Device Interface) which allows to succinctly describe what resources would need to be made available to a container in order to "mount a device" and be able to use it from within that container. As a good example, NVIDIA supports CDI for its various GPUs and accelerators as they are/can be quite complex devices to properly expose to a container.
One of the main motivators for the creation of CDI seems to describe the characteristics of USB-based Zivid cameras well (emphasis mine):
Instead of reverse-engineering all the required devices and resources ourselves, I'm wondering whether Zivid would consider providing a CDI spec for their USB-based devices. It should make use of these devices in containers (not just Docker, but also Podman fi) quite a bit more straightforward.
If that would not be possible, some guidance on which devices are enumerated after connection of a Zivid One Plus M to a Linux-based OS would be appreciated. The community could then potentially come up with a CDI spec itself.