Reachy Robot 1 Camera Not Detected: Diagnosing Blank lsusb and /dev/video Output

ByPriya Nair

What blank lsusb output is actually telling you

lsusb lists every USB device the Linux kernel can see on the bus. If the Reachy cameras don’t appear anywhere in that output — not even as an anonymous or unrecognized device — the OS genuinely cannot find them. That’s a hard line between two very different classes of problem.

When a camera shows up in lsusb but not in /dev/video*, that’s a driver issue: the kernel sees the hardware but no UVC module has claimed it. Fixable in software. When lsusb is completely silent, no software fix will help — there’s nothing for a driver to bind to. The problem is physical, and that’s where to focus.

How the Reachy 1 camera system is wired

The Reachy 1 head carries two Raspberry Pi cameras, each paired with a different optical lens — one wide-angle for environment perception and one macro for manipulation tasks. These are CSI cameras, not standalone USB devices. They connect via ribbon cable to a compute board inside the head, which bridges them onto the USB bus so the host computer can reach them through /dev/video*.

That bridging step matters. There are two potential failure points before you even get to software: the CSI ribbon connection between each camera and the internal board, and the USB connection between that board and the host machine. Either one failing produces exactly the blank output described here.

Software checks to run first

Before touching any cables, exhaust the software side. It’s faster and safer.

Watch dmesg live while replugging

Open a terminal and run:

dmesg --follow

While that’s streaming, physically reseat the USB cable coming from the Reachy head. If the camera board enumerates at all — even briefly, even with an error — you’ll see it here. Look for lines containing usb, video, uvcvideo, or error codes like -71 (device not responding) or -32 (broken pipe). A completely silent dmesg during that replug means the USB event never reached the host at all.

Check the USB tree

lsusb -t

This shows bus hierarchy and link speeds. It won’t surface a missing device, but if you expect the camera on a specific port and see that slot empty, it confirms the absence rather than leaving you guessing.

Try loading the UVC module manually

sudo modprobe uvcvideo
lsmod | grep uvc

If the module loads cleanly but lsusb still shows no camera, the module is not the issue. The device is simply absent from the bus and no amount of driver work will change that.

Pull boot-time USB events

journalctl -b | grep -i usb

Compare this with your video-specific grep. USB errors at boot — power issues, enumeration failures — sometimes appear here when a narrower filter misses them.

Physical checks inside and around the head

If every software check comes up empty, the problem is almost certainly physical. Opening the Reachy head requires care; the Orbita ball-joint mechanism and internal cable routing are tight. Read Pollen Robotics’ documentation before proceeding, and don’t force anything.

The USB cable from head to host

Start with the simplest thing. Swap the USB cable connecting the head to the host for a known-good one. Then plug a different USB device into the same port on the host to confirm that port is live and not the culprit.

Internal CSI ribbon cables

Inside the head, each camera connects to the compute board via a CSI ribbon cable. ZIF (zero insertion force) connectors are fragile. The locking tab can partially release during shipping or reassembly, and a ribbon that looks seated may not be making full contact. Power everything off, open the locking tab, reseat the ribbon until it stops, then close the latch firmly. Test before closing anything up.

Power connector to the camera board

The internal compute board gets power from the head’s wiring harness. That connector can come partially loose and still look attached. Check it while you’re already in there.

Ruling out the host USB port

Before concluding the camera hardware is dead, plug a USB webcam into the same host port. If it shows up in lsusb and creates a /dev/video* node, the port, kernel modules, and driver stack are all working — the problem is inside the Reachy head. If an external webcam also fails to appear, the host side needs attention before anything else.

When to contact Pollen Robotics support

If reseating cables doesn’t fix it and an external camera confirms the host is healthy, the camera module or internal board may have failed outright. Pollen Robotics supports users through their community forum and handles hardware failures under warranty. When you reach out, include your dmesg --follow output from the replug test — even a completely silent log is useful, because it rules out partial enumeration and tells them the device never appeared on the bus at all.

Sources


Similar Posts