Jetson TK1: USB Hub + Logitech Webcam

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

I recently installed CUDA 6.5 and OpenCV 2.4.10 on the Jetson, and both are running successfully. However, when I try to run a sample OpenCV program using the webcam, plugged into a USB hub, it cannot detect the camera. Initially the light on the webcam came on briefly, so I thought it found it, but then it would produce a black screen window claiming it can’t capture video. I checked to see if the device could be seen using $lsusb (which it shows up) and tried using luvcview to access the camera. Unfortunately, I get a strange error: “ERROR opening V4L interface: No such file or directory”, especially since I installed it along with the other OpenCV libraries. Is it possible to capture OpenCV images with a webcam plugged into a USB hub versus directly into the board itself? Or is there another issue to this (i.e. the webcam or missing library)?

Specs:
Webcam = Logitech (model unknown b/c its 8 yrs. old)
Jetson TK1 = R21.1
OpenCV = 2.4.10
CUDA = 6.5

Commands:
OpenCV (Sect. ‘Testing OpenCV’): Jetson/Installing OpenCV - eLinux.org

"cd ~/opencv-2.4.10/samples/cpp

g++ laplace.cpp -lopencv_core -lopencv_imgproc -lopencv_highgui -lopencv_calib3d -lopencv_contrib -lopencv_features2d -lopencv_flann -lopencv_gpu -lopencv_legacy -lopencv_ml -lopencv_objdetect -lopencv_photo -lopencv_stitching -lopencv_superres -lopencv_video -lopencv_videostab -o laplace

./laplace"

Luvcview (Sect. ‘Camera Access’): Jetson/Cameras - eLinux.org

"ls /dev/video*

sudo apt-get install luvcview
luvcview -d /dev/video0 -L

luvcview -o out.avi"

2

Because the Jetson is mostly designed to be an embedded device, it tries to conserve power by automatically suspending inactive USB ports to save power. You may need to disable USB auto suspend mode. If your USB hub has lights on it, you’ll probably see that the port that the web cam is on lights up on boot, and then turns off.

You can disable this temporarily until you reboot:

$ sudo bash -c 'echo -1 > /sys/module/usbcore/parameters/autosuspend'

or to perform this automatically on every boot up, you can modify your ‘/etc/rc.local’ script:

$ sudo gedit /etc/rc.local

and add this near the bottom of the file but before the “exit” line:

# Disable USB auto-suspend, since it disconnects some devices such as webcams on Jetson TK1.
echo -1 > /sys/module/usbcore/parameters/autosuspend

Make sure to save the file and then reboot.

3

Have you tried lsusb ?

Should look like that:
:~$ lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 015: ID 046d:0a04 Logitech, Inc. V20 portable speakers (USB powered)
Bus 001 Device 014: ID 046d:081b Logitech, Inc. Webcam C310
Bus 001 Device 013: ID 046d:c52e Logitech, Inc.
Bus 001 Device 012: ID 8564:4000
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

4

Hi guys,

well well well, I had almost the same problem.

I recently installed cuda 6.5 and openCV4Tegra on the Jetson and both are running perfectly.
However, I was trying to test my Logitech QuickCam Pro 9000 before to try to detect a face using OpenCV. But unfortunately when i just run :

sudo apt-get install luvcview
luvcview

I got this error:

libv4l2:error turning on stream: No space left on device
 Unable to start capture: No space left on device

So after some research, I thought the problem that the Jetson is mostly designed to be an embedded device, it tries to conserve power by automatically suspending inactive USB ports to save power. So I just disabled USB auto suspend mode through adding this following lines to “/etc/rc.local”.

# Disable USB auto-suspend, since it disconnects some devices such as webcams on Jetson TK1.
echo -1 > /sys/module/usbcore/parameters/autosuspend

So, I restarted Jetson and tested my web cam again , but I still get the same error.

I tried lsusb and I got this :

Bus 002 Device 005: ID 046e:52c0 Behavior Tech. Computer Corp. 
Bus 002 Device 004: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000
Bus 002 Device 003: ID 15d9:0a37 Trust International B.V. Mouse
Bus 002 Device 002: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So my web cam is here with the mouse and the keyboard. (by the way I am using a USB hub which is plugged to USB port J1C2 on Jetson)

After more research, I find that some people tried to run 2 or 3 web cam in same time and they got the same error. And I got that the “No space left on device” in this context mean that there is insufficient USB bus bandwidth to stream.

So I tried to run my web cam with a low resolution and low frame rate.

luvcview -d /dev/video0 -f yuv -s 176x144 -i 15

But it doesn’t work and I still have the same error.

Then I was trying to know how much it’s allowed to the USB bus bandwidth. I tried this:

sudo cat /sys/kernel/debug/usb/devices | grep "B: "

I got :

B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
B:  Alloc=  0/800 us ( 0%), #Int=  4, #Iso=  0
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0

so I guess the problem is here.

Any suggestion ??? or a different interpretation for this issue ??

5

If you look at lsusb, you’ll see the vendor ID is 046d and the product ID is 0990. Use “less” to search /sys/kernel/debug/usb/devices for this and “B:”:

less /sys/kernel/debug/usb/devices
/046d.*0990|^B:
# ...use "n" or "p" for next or previous search...

I’m guessing the “B: Alloc” does not apply to the camera.

I’m testing with a Logitech HD Pro Webcam C920 on a HUB going to the same J1C2 connection (full-sized USB connector) in the default USB2 mode as well as USB3, L4T R21.4. The HUB is powered. I have only the one camera, it isn’t possible for me to test “no space left on device” via adding more cameras (and I can’t confirm if this is USB bandwidth…but the “B: Alloc”, if not occurring in the camera section, will not be related).

So far as USB goes, you can explore what USB information is available on your particular camera via:

lsusb -d 046d:0990 -v | less

Unless the camera is USB3 (and it is too old to be USB3) I doubt the setting for USB2/USB3 for the USB port matters, but run “lsusb -t” to see which driver and speed is applied to each device. The human interface devices will only be a drop in the bucket of bandwidth, and not even matter. A HUB will be running at either its max speed of 480M or 5000M, depending on whether it is USB3 or not. However, iff there is a problem in USB, it would be important to know if the driver is tegra-ehci or tegra-xhci, which is listed in lsusb -t.

I’m not familiar with the “no space left on device” error, but from what I’m seeing on web searches is that this applies to /dev/video0 rather than USB. The video0 device in turn is created by a driver in the kernel which is separate from USB. It is possible that the error is related to latencies in USB and thus influenced indirectly by USB. The solutions I see on the web pretty much suggest what you’ve seen, making the video camera run by itself on its own least-congested USB bus.

For unrelated reasons, I’ve been trying to set up and test the other USB port on the micro connector. I can’t verify it yet, but in theory if you have a type-A micro cable it can connect to this port during normal operation and serve as your average USB2 host connector capable of handling a HUB and keyboard, mouse, so on (or camera by itself). The trick is that almost every single USB micro connector cable available on the market is type-B, not type-A, and you MUST have a type-A to use this port like a normal desktop computer full-size connector. I just found the one and only cable that I’ve seen of this type here:
EDIT: This connector does not work, as it is different than what they advertise on that web page. This is NOT the connector in their picture.
http://www.shopfujitsu.com/store/SelectAccessoryDetail.jsp?partNumber=FPCCBL75AP&category=Cables%20and%20Adapters&title=MicroUSB%20to%20USB%20Conversion%20Adapter(FPCCBL75AP)&mkw=&pmt=&gclid=CjwKEAjwmZWvBRCCqrDK_8atgBUSJACnib3lEfI71BrTfG7ZnXkfSpRReN276zNcWc8yJ5TrEO5EERoCqOzw_wcB&cshift_ck=6d60c883-fa5c-4f6d-9738-cd65aaf1f0b5csXXQvxnjc
On the image of such connectors often you will see a “B”, which is type B…seeing “A” for type-A is very rare. Additionally, on a connector image, two corners of a type-B will be bevelled, whereas type-A has smaller slots in the same corners without the bevel, thus being a bit more “boxy” (“mini” connectors are very close in size and shape, but won’t fit). You can try a cable such as this (no guarantee) in order to move something to the micro port, or perhaps get a mPCIe slot USB card to add more USB ports.

6

Dear linuxdev,

Thanks for your help, I was thinking about this solution ( to plug my web cam in micro connector) and I bought a type-B USB micro connector cable (Connector Types: 1 - MicroUSB Male and 1 - USB Female.).
I plugged my web cam into micro connector with type-B cable, and the Hub in USB 3.0 which it contain the mouse and the keyboard.
My web cam is working, and also my mouse and the keyboard.

But I tried again with mouse, keyboard and web cam plugged in HUB. I ran the “less” to search on /sys/kernel/debug/usb/devices , I got this

https://scontent.xx.fbcdn.net/hphotos-xtp1/v/t34.0-12/11949686_896369127110158_1893008269_n.jpg?oh=c08ee7c6abaf85c4c4416a06638de93e&oe=55EAB713

And when I wanted to explore what USB information is available on my particular camera via

lsusb -d 046d:0990 -v | less

it was just empty, nothing to read , no information.

Anyway, The web cam is working via micro connector. But I want to know if The cable type-B can affect the quality of my streaming webcam??

7

Keep in mind that the USB OTG port has not been fully developed for switching between device and host mode (other than recovery mode always being device, and booting to L4T starting as host). There is another thread going about kernel errors related to adding and removing a USB driver after manually switching the micro port between host and device modes.

In theory, if the USB drivers are working correctly, a type B micro connector cannot work with Jetson in host mode. Host mode responds as owning and controlling the devices (device mode being things like keyboard and mouse). The insertion of a type B should tell Jetson that Jetson itself is to become a device to be controlled by a host somewhere else, e.g., Jetson could look like a mass storage device or similar to the other computer it plugs into. Hosts control devices, devices cannot talk to or configure other devices; hosts cannot talk to or configure other hosts.

Automatic detection and switching of modes has not been added yet for R21.4 (switching requires an echo to /sys files). Even if a type B connector currently succeeds in the USB micro socket, I would not expect this to always function correctly, nor would I expect this to work at all in future releases. You may be better off adding an mPCIe USB card (which could even be USB3…the micro port is only capable of USB2). Or else use a type A micro connector.

8

My interpretation may not be correct, but this is how I see it: The existence of the vendor and product ID in the /sys file is a reflection of host mode. The lack of existence under lsusb is a reflection of the type B connector device mode. This is also a reflection of the OTG mode switch not being developed and not functioning correctly. It is possible that if you removed and added one of the USB cables back enumeration might once more cause lsusb to see the device.