Two depth cameras USB busy: fix the interface claim error

You bring up the first depth camera and it streams perfectly. You launch the second one and it dies with a failed to claim usb interface error and a USB status of busy, even though both cameras preview fine one at a time in the vendor viewer. This pattern, one camera healthy and the second refusing to start, is almost never a broken camera.

It is a host-side problem: USB controller capacity, an interface already claimed by another driver, a power budget that collapses under two streaming devices, or cabling that worked at one stream and fails at two. This guide walks through the checks in order of probability, with the commands and numbers you need, and ends with the cabling and hardware choices that avoid the problem altogether. It applies to any USB 3 depth or stereo camera on embedded ARM boards and small x86 hosts.

Understand what the error actually means

A USB device exposes one or more interfaces, and the host driver must claim each interface before transferring data. Claiming is exclusive: only one driver on the host can hold an interface at a time. When your SDK reports that it failed to claim an interface with a busy status, the kernel is saying that something else, or nothing, answered the claim request. Two very different causes produce this:

• Another driver on the host already holds the interface, so the claim is refused.
• The claim or the following queue request fails at the electrical or bandwidth level, so the transfer layer reports the device or resource as busy.

Because both print a similar message, engineers often chase the wrong one. The fastest separator: run lsusb -t with both cameras connected. If both devices appear under a SuperSpeed (5000 M) branch, the enumeration is healthy and you should suspect bandwidth and controller capacity. If the second camera drops to 480 M or disappears, suspect power or cabling first.

Check the USB controller topology first

On small boards, the number of physical USB sockets says nothing about how many USB controllers sit behind them. Two blue ports can hang off one controller, and a controller serves a total bandwidth pool, not a per-port one. A depth camera pushing depth plus infrared plus colour at 30 fps can consume most of one USB 3 controller's practical throughput. Two such cameras on one controller exceed it before either camera is faulty.

Find the topology:

1. Run lsusb -t and note which bus each camera sits on.
2. Run lspci and count the USB controllers; on x86 you can usually add a PCIe USB controller card to split the load.
3. On embedded boards, read the SoC documentation: many boards wire all USB 3 sockets to one controller and share the rest at USB 2 speeds.

If both cameras share a controller, your options are: move one camera to a controller with spare capacity, add a controller, or cut each camera's stream budget so both fit. Measure, do not guess, with a bandwidth monitor such as usbtop or the kernel's usbmon while both cameras stream at your production settings.

Rule out a competing driver holding the interface

The second classic cause is a leftover driver or a second copy of the depth stack. On Linux, distribution packages of the depth library can install udev rules and a user-space library that claims interfaces when a node starts. If you later install the vendor SDK manually, the two can fight: the first node claims camera one, a stale module grabs camera two, and your second node gets the busy error.

The fix is to keep exactly one stack:

1. Remove the distribution package of the depth library (apt remove the relevant package) if you run a manually installed SDK.
2. Reinstall the vendor SDK once, from the manufacturer, and note the version.
3. Unplug both cameras, replug them, and confirm with lsusb -t that both enumerate at SuperSpeed.
4. Launch camera one, then camera two, and watch dmesg -w as the second claims its interfaces.

This mirrors the startup-order problems covered in the article on multiple USB depth cameras on Linux: startup troubleshooting, which also explains how to pin serial numbers so each node always opens the same physical camera.

Budget the bandwidth per stream

If topology and drivers are clean, the remaining cause is arithmetic. USB 3 offers about 400 MB/s of practical throughput per connection after protocol overhead, and a controller shares its pool. A depth camera's budget is roughly:

Worked example: an 848 × 480 depth plus one IR stream plus 848 × 480 colour at 30 fps needs about 30 × (0.81 + 0.41 + 0.61) MB ≈ 55 MB/s per camera, which is comfortable. At 1280 × 720 with two IR streams and colour, each camera approaches 150 MB/s, and two cameras on one controller start colliding with overhead. The remedy is to disable every stream you do not consume. Depth-only operation at reduced frame rate is the standard first deployment setting; add colour and IR back one stream at a time until the busy error returns, then back off.

The same arithmetic underlies the darker symptom of a starved camera, covered in depth camera black image: fix USB bandwidth and power issues. Busy errors and black frames are two ends of the same budget problem.

Check power before you blame software

Two streaming cameras draw far more than one. A USB 3 port supplies up to 900 mA, and many boards deliver less in practice. A bus-powered hub cannot carry two depth cameras; each camera may enumerate and then fail its first heavy transfer, which the SDK reports as a busy or resource error rather than a clean power fault.

Use a powered hub with its own supply, or better, one camera per root port. If the error appears only when both cameras stream, and dmesg shows disconnects or resets interleaved with the claim failure, power is the likely culprit. Swap to shorter, shielded cables at the same time: marginal USB 3 links retry until the host gives up, and long or worn cables fail exactly at the dual-camera load point.

Swap cables and ports as a controlled test

Cabling deserves its own pass because it is the quickest thing to change and it fails in exactly this intermittent way:

1. Swap the two cameras' cables. If the failure follows the cable, replace it.
2. Use a cable rated for USB 3 and, on a moving stage, a drag-chain-rated one such as the 3 m high-flex USB 3.0 camera cable, which is built for repeated flexing in cable carriers.
3. Keep USB 3 cables at 3 m or less; beyond that, signal integrity drops and full-rate streams fail first.
4. Test each camera in each port. A port that works for one camera and not the other points at the port, not the camera.

For fixed installations, route data cables away from motor drives and contactor wiring, and follow the grounding practices in camera GPIO wiring: prevent damage and triage power faults if your trigger and power lines share a bundle with the USB run.

When the usual answer is wrong

If topology, drivers, bandwidth, power and cables all check out and the second camera still will not start, look at three rarer causes:

• Kernel version. Old kernels had xHCI quirks with multiple isochronous streams; a kernel update from your board vendor often clears it.
• Firmware mismatch between cameras. Two units on very different firmware revisions can behave differently under load; update both to the manufacturer's current release.
• A failing camera. Run each camera alone for an hour. A unit that drops frames alone will dominate the bus in a pair.

If you regularly need more than two depth cameras, USB is the wrong interface. Networked 3D cameras scale better: browse the 3D sensors category for laser profilers and stereo cameras with GigE interfaces, and read vision cell network isolation from a busy plant LAN before you put them on shared networking. The bandwidth trade-offs of shared buses generally are covered in multiple camera modules on one host: shared bus limits.

Pre-deployment checklist

• [ ] Both cameras enumerate at SuperSpeed in lsusb -t before any software starts.
• [ ] Each camera hangs off a controller with measured spare bandwidth at production settings.
• [ ] Exactly one depth SDK version is installed; distribution library packages removed.
• [ ] Each serial number is pinned to one node so startup order does not matter.
• [ ] Unused streams (colour, second IR) disabled until the dual-camera run is stable.
• [ ] Cameras powered from root ports or a powered hub, not a bus-powered hub.
• [ ] Cables 3 m or shorter, USB 3 rated, drag-chain rated on moving axes.
• [ ] An hour-long soak test with both cameras streaming before you close the cabinet.

Choosing hardware that avoids the problem

If you are still specifying the system rather than debugging it, decide the interface per camera count. One or two depth cameras with modest stream settings work on USB 3 with separate controllers. Three or more, or long runs, belong on GigE. Use the camera finder to filter by interface and depth technology, pick drag-chain or strain-relieved cable from the camera cables category, and size the whole chain with the vision system configurator so controller, cable and camera are matched before anything ships. For embedded compute, a host with an add-in PCIe USB controller gives you more root ports and expansion headroom than a single-board computer.

The short version: a busy-interface error on the second depth camera is a claim and capacity problem, not a camera defect. Fix the topology, keep one SDK, spend your bandwidth deliberately, and feed both cameras power and good cable, and two cameras run as calmly as one.