Depth camera no matching device found: fix USB open failure

Your launch log fills with "No matching device found... waiting for devices", and under it the line that matters: "Failed to set USB interface". The camera is not dead. A moment earlier the same node printed "Device found" with the camera's USB address, so enumeration succeeded and power, connector and data pair are good enough to be seen. What failed is the exclusive claim that follows enumeration, and that has four causes, each with a five-minute test: a process that still owns the interface, udev permissions, a wrapper or library version mismatch, and the calibration files the driver loads while opening the device. The last one is what bit the log below, and redoing the calibration cleared it.

What the log proves before you change anything

Two lines decide the direction. First: Device "2bc5/0401@1/4" found — the driver enumerated a camera with vendor ID 2bc5, product ID 0401, on bus 1 at address 4. Second: Could not open "2bc5/0401@1/4": Failed to set USB interface! — the open path failed at the exclusive claim. The log even names the spot: the device-open constructor, astra_device.cpp line 76 in the astra-camera 0.2.2 wrapper. All four causes die inside that constructor, so rereading the message cannot separate them. The tests can.

The address in that string maps to a kernel file:

Bus 1 becomes 001 and address 4 becomes 004, so this camera lives at /dev/bus/usb/001/004. Write it down; three of the four tests use it. Decision up front: with a "Device found" line in the log, leave the camera, the cable and the port alone. The fault is on the host side.

Worked example: timing the retry loop in the failing launch log

Inputs: three consecutive failures, time-stamped 1583121524.954, 1583121527.968 and 1583121531.000 (UNIX time, in seconds), with the device string identical each time. The rule: the poll interval is the later timestamp minus the earlier one.

• 1583121527.968 - 1583121524.954 = 3.014 s
• 1583121531.000 - 1583121527.968 = 3.032 s

The node retries about every 3.0 s, and the device never re-enumerates: same bus 1, same address 4, failure after failure. That is a stable, powered, visible camera that only fails the claim — the profile of a host-side blocker, not a flaky cable.

Decision: this is a polling loop, not a crash. Leave the nodelet manager running while you fix the cause; it connects on the next poll without a relaunch. One exception worth watching: if the address, the /4 part, ever changes between retries, the camera is dropping off the bus and the problem moves to power and cabling.

Cause 1: another client still owns the interface

The claim on a usbfs device is exclusive — one open descriptor at a time. The owner is rarely a mystery: it is whatever opened the camera last. A calibration session with its viewer still running, an earlier launch whose nodelet manager never exited, or a leftover kernel binding. In this log the first failure lands seconds after a calibration run, which makes an un-closed calibration client the first suspect.

Test: fuser -v /dev/bus/usb/001/004. Every PID printed there holds your camera; match them against the process list for old managers. Fix: close the viewer, kill the stale manager, and if the claim still fails, unplug and replug once to clear the interface state.

The same ownership rule governs machine-vision cameras: one client owns a USB3 Vision camera's interface, and a node that died without releasing can keep holding a device after a restart.

Cause 2: udev permissions on the device node

Enumeration does not prove access. Discovery can list a camera while /dev/bus/usb/001/004 stays root-only; the claim then opens that file for exclusive use and is refused. Test: run the same launch once with sudo. If the camera opens, permissions are the whole problem.

Fix: one rule in /etc/udev/rules.d/99-depth-cam.rules, using the IDs from your own device:

SUBSYSTEM=="usb", ATTRS{idVendor}=="2bc5", ATTRS{idProduct}=="0401", MODE="0666"

sudo udevadm control --reload-rules && sudo udevadm trigger

Then unplug and replug: the system applies the reloaded rule when the device reappears. Read the IDs with udevadm info -a -n /dev/bus/usb/001/004 (the idVendor and idProduct lines) rather than typing them from memory. The full walkthrough, including what to check when the rule file exists and access still fails, is in udev rules for USB cameras on Linux.

Cause 3: the wrapper and the library disagree

This failure has a track record. After an OpenNI update from 1.8.8 to 1.8.9, camera nodes failed with the same "Failed to set USB interface" while the bundled viewer kept working; reverting the library restored them. The regression sat between wrapper and USB library — not in the camera, not in udev.

Test: open the camera with the manufacturer's viewer on the same machine and port. Viewer opens, node does not: version mismatch. Fix: put the wrapper on the library it was built against and keep the SDK and firmware pairing matched — 3D camera header version mismatch covers that alignment. If you cannot align them, pin the wrapper to the last version that worked.

Cause 4: the calibration files load during open

Here is the confirmed culprit for this log. The driver resolves depth_camera_info_url and rgb_camera_info_url while it opens the device, before a single image flows. A file that is missing at that path, or a YAML whose image_width and image_height don't match the resolution the driver is opening, aborts the open — and the wrapper surfaces it as the same generic USB failure. This launch failed immediately after a calibration attempt and ran clean once the calibration was redone: that is the signature.

Test in this order:

1. Resolve both URLs and open the files. A file:// URL must point at a YAML that exists at that exact path; an unopenable calibration file is a path problem, not a tuning problem.
2. Read each file's header. image_width and image_height must equal the depth and RGB modes the launch requests; a file written for another resolution fails here.

Fix: regenerate the calibration against the modes the driver actually opens and repoint the URLs. Once the camera opens, validate the corrected files end to end: after redoing the calibration in this case, the depth stream that came out could be turned into a usable map, which 2.5D height map to 3D point cloud walks through from raw pixels to XYZ.

Hardware: one swap test, then stop

If all four tests run clean and the claim still fails, make one isolation pass — not a shopping trip.

1. Swap the cable. Drag-chain installs wear cables at the strain relief, and one swap answers it in a minute.
2. Move the camera from a hub to a root port. The address decode already placed it on bus 1; a root port there removes the hub from the chain.
3. Power-cycle the camera and let it finish booting before you launch. A depth camera that is still booting enumerates late or resets mid-claim; why X_LINK_DEVICE_NOT_FOUND follows camera boot walks the same pattern on another depth camera stack.

The infrared projector in a structured-light or ToF camera is an intentional illuminator: no staring into the emitter at close range, and no removing labels or housing while you test.

If the same error follows the camera across a new cable and a root port, hardware is cleared and the host stack owns the fault. The methodical version of this isolation is in USB camera keeps disconnecting.

A drag-chain-rated replacement for the swap test:

A second camera turns the host into the test variable: one that opens where the first fails sends the first to the bench. A current depth and ToF camera for that swap:

When the usual advice is wrong

• "Unplug and replug." It clears a stale claim and re-applies udev rules, which is why it sometimes works. If the error returns after a replug, stop and run the sudo test and the fuser test.
• "Move it to a faster port." Port speed fixes bandwidth. A depth camera limited to a low resolution over a slow link is that problem, not a claim failure; "Failed to set USB interface" fails at any port speed.
• "The device selector is wrong." With one camera on the bus, a device_id of #1 and devnums of 1 are consistent, and the log proves the node found the camera it asked for. Selectors matter when two identical cameras share a host — then open by port, not by name.
• "Replace the camera." The "Device found" line already cleared its power, its connector and its enumeration. No replacement changes a claim refusal until the four tests above run clean.

Checklist before you relaunch

1. Every program that opened the camera is closed: viewers, calibration tools, earlier launches.
2. fuser -v /dev/bus/usb/001/004 prints nothing — no holder.
3. One sudo run fails the same way as the normal user — permissions cleared.
4. The vendor viewer opens the camera on the same port — stack and hardware cleared.
5. Both camera_info URLs resolve to files whose image_width and image_height match the requested modes.
6. Cable and port swapped once, camera power-cycled and allowed to finish booting.
7. The node is left running: the 3.0 s retry loop connects on the next poll.

If an aging stack keeps losing this fight, the 3D sensor finder lists current depth and ToF cameras, and you can contact us with the log from "Device found" down — those two lines pick the branch.