[BUG] DepthAI does not work with OAK-D in LXD containers #450
Comments
gbiggs
changed the title
|
I forgot to mention that I have tried setting up something like the udev rules and script discussed in the installation instructions for Kernel VMs, but modified for LXD. It made no difference to the behaviour I'm getting. |
|
Sorry about the trouble @gbiggs . Unfortunately I don't personally know what LXD is (but I'll Google it shortly). What I'm thinking is happening though is that USB2 is being routed through to the container but USB3 is not. So this is why before boot you can see DepthAI, but not after. This same thing will happen on Virtual Box for example if USB3 is not passed through. See here. And in Virtual Box case, it is necessary to actually run the pipeline to get the USB3 interface to show up (as it only shows up after DepthAI has booted over USB2) and then make sure to add it to pass through into Virtual Box. So I'm wondering if a similar thing is necessary in LXD. But I'm guessing into the dark a little as I don't yet know what LXD is (will Google it shortly). Thoughts? Thanks, |
|
OK, learning a bit more about LXD. From my reading so far, I'm guessing our Docker container reference is probably what should be used to get LXD running, as it sounds like the libusb rework that was needed to work properly in Docker is likely also needed for LXD (since they seem to be very similar). https://hub.docker.com/r/luxonis/depthai-library And beyond that, I'll likely need the team to comment further. Sorry again about the trouble. Thanks, |
|
I'm trying to mimic what the Dockerfile does in my LXD container, but I'm not sure where to install |
|
Hi @gbiggs , Unfortunately I don't know it well enough - and I didn't do the work myself - but here is an overview of at least a bit of what was done to get Docker to work. I remember it being a confusing and fairly lengthy effort. And actually IIRC one of our customers is who actually figured it out and then kind of taught us the technique to do it. That said, I think @themarpe may be able to provide some pointers. And also I think some recent work in libusb itself to make it so it's accessible in a non-priveleged manor (I think it requires root as of now) would help here. I think the main effort is to make it so libusb can be used in non-rooted ways in Android, but I think I remember a "hallway conversation" about how this would help make Docker (and thereby LXD) easier to make work. Thoughts? Thanks, |
|
I will keep playing around with |
|
@gbiggs I'd suggest you taking a look at this. It boils down to 2 steps:
And a third one which stems from first point - linking with newly built libusb. This can be achieved in two ways:
Hopefully this maps to LXD neatly and helps you resolve the issue. If you'll have any additional information, feel free to tag and ask me:) |
|
I had same problem. this solution solves it. Thanks |
|
@oto313 Did you have the same problem in an LXD container or in a Docker container? @themarpe I've tried compiling This is the device in And here's |
|
@gbiggs Hi, I had problem in Docker container - arm32v7 arch Client: Server: |
|
@gbiggs Regarding libusb, if you linked to dynamic you can check using: |
|
@themarpe Apart from |
|
|
|
@gbiggs not sure if you've tested this already, but can you try passing these settings. Seems similar as in Docker container use case, so I presume it could resolve your issue |
|
Thanks for the pointer to how to set a cgroup permission. I added it to my container instance using this command (LXD is slightly different from pure LXC): I confirmed that the configuration has been saved: I also restarted the instance, to be sure it took effect. Running the |
|
@gbiggs If so, there is a file Remove the if statement check, recompile the libusb and depthai and retest. If the above is not apparent, feel free to skim through libusb debug logs and try spotting anything unordinary. |
|
That line doesn't appear in the debug output. I'll read through the log and see if I can find anything useful, and also try a diff. Here's the debug output, in case you know what to look for. The last few lines are repeated forever until the application exits. |
|
I've found a significant difference between the two logs. When running on the host, with a no-udev-libusb, the following line appears about 1.8s into the log: That device number is the OAK-D after rebooting into running-mode on the USB 3 bus. Following that line are many attempts to open the device, which fail with no access until (I assume) udev runs the rule that gives it access, then the device being opened, transfers happening, etc. The above line never happens inside the container. I think this means that the container is not properly announcing the new USB device being attached. I've uploaded the log for the host so you can what I mean. |
|
According to this article:
|
|
Knowing a big more what to look for now, I've found that in the container, the following events are detected: The removal of the boot-mode device when it reboots: The appearance of the boot-mode device after the running-mode device gives up and reboots: The removal of the running-mode device when it gives up and reboots (note that this happens after the above line): Notably absent from the debug output in the container is the event for the running-mode device appearing, even though the device node in Running on the host, the debug output does contain an event for the running-mode device appearance. |
|
@gbiggs can you try forcing USB2 mode in the script you are using? |
I edited
I agree, it's very odd that it consistently misses just that message. I haven't found any further information for LXD hotplugging other than "it just works"; which it does seem to mostly. It's just that one event...
Adding a device with a vendor ID only makes the product ID a wildcard match, apparently. Just to be sure, though, I added devices for both product IDs specifically. It made no difference. |
|
@gbiggs is your issue resolved with the above fix ? |
|
@gbiggs Please provide us details regarding the resolution of the issue . |
|
@Sanjubisanal @ParasPidurkar |
|
@themarpe We still have the same issue. Inside LXD:
|
|
@Sanjubisanal |
Description of the bug
Running the DepthAI demo with
python3 depthai_demo.pyusing a USB-C OAK-D in an LXD container fails to find the device after booting. Instead it gives the following errors:This is the
dmesgoutput from plugging in the USB cable until the demonstration application terminates with an error.Running it again after this fails to even find the device in bootloader mode:
There is no
dmesgoutput while running the application this second time.Reconnecting the USB cable and running the demonstration application again gives the first result above, where the device is at first found, then lost.
Launching the same application in the host OS works fine. The camera image and disparity map are displayed correctly until
Ctrl-Cis pressed.This is the
dmesgoutput for when the application runs correctly on the host OS, from connecting the USB cable through to pressingCtrl-C:To Reproduce
Steps to reproduce the behavior:
depthai_demo.pydemonstration applicationExpected behavior
The demonstration application launches in an LXD container, opens the OAK-D device and displays the camera image and the disparity map.
Attach system log
Output of log_system_information.py:
The text was updated successfully, but these errors were encountered: