Reachy Robot 1 Camera Not Detected: Hardware vs. Driver Diagnosis on Linux

ByPriya Nair

What blank lsusb output is actually telling you

When lsusb returns no camera entry at all, that silence is the most informative output you can get. The Linux kernel cannot enumerate the device. That makes it a hardware-layer problem, not a driver one — and those two failures need completely different fixes.

There are two distinct scenarios for a camera that stops working on Linux:

  • Camera appears in lsusb but not in /dev/video* — the USB controller sees the device, but no driver has claimed it. A software problem, usually solvable without touching hardware.
  • Camera absent from lsusb entirely — the USB controller cannot enumerate anything at that address. The camera is not making a usable electrical connection.

When lsusb, ls /dev/video*, lsmod, and journalctl all come back empty at the same time, that combination points solidly at the second scenario. No log chatter at all means the OS never even got a chance to reject the device.

Step 1: Watch dmesg in real time during a reseat

Before opening anything, open a terminal and run:

sudo dmesg --follow

Leave it running. Power down the robot, reseat the internal camera connector (gently — more on that below), then power back up. A successful USB enumeration produces a burst of dmesg output: a new device address, speed negotiation, driver binding. If reseating the cable produces complete silence in dmesg, the connection is not making electrical contact at all.

Error messages are actually helpful here. Lines like device not accepting address or cannot reset port point toward a power or USB hub fault rather than a dead camera module — and those are often recoverable without replacing hardware.

Step 2: Physical inspection of the camera connection

Power the robot down completely before opening the head. Then look for:

  • Any ribbon cable or USB cable that looks partially unseated from its connector
  • Connectors that feel loose or show cracked housing, bent pins, or corrosion
  • Visible cable damage — kinks, fraying, or sharp bends near the crimp

Cables inside a robot head flex every time the head moves. Fatigue failures at connector crimps are common and often invisible — the cable looks intact but has broken strands internally. Reseat gently and never force a connector that resists.

If you need to disassemble further, photograph the cable routing before removing anything. Reassembling in the wrong geometry can pinch a cable you just fixed.

Step 3: Map the full USB tree

After reseating, run:

lsusb -t

This prints the USB hierarchy — host controllers, hubs, and attached devices in tree form. An internal USB hub appearing with no children where the camera should be means the hub is alive but the camera isn’t enumerating. If the internal hub itself is missing, the problem is upstream: hub power, or a disconnected hub cable.

For a second pass:

sudo lsusb -v 2>/dev/null | grep -i -A2 camera

This catches anything camera-shaped that the short listing might not label obviously.

Step 4: If the camera now appears in lsusb — driver troubleshooting

A successful reseat that gets the camera into lsusb is good news. The hardware is alive. Now check whether the UVC kernel module loaded:

lsmod | grep uvcvideo

If it is not there, load it:

sudo modprobe uvcvideo

Then check ls /dev/video* again. Most cameras that implement the USB Video Class spec get claimed automatically by uvcvideo on plug-in. If yours did not, it may have enumerated before the module was available, or the module is blacklisted in /etc/modprobe.d/.

If the module loads but no device node appears, enable uvcvideo trace logging:

echo 0xffff | sudo tee /sys/module/uvcvideo/parameters/trace

Unplug and replug the camera, then check dmesg immediately. The output names the exact control command that failed during initialization. Turn the trace off when done:

echo 0 | sudo tee /sys/module/uvcvideo/parameters/trace

Some cameras with non-compliant firmware need a quirks flag. You can set one persistently by creating /etc/modprobe.d/uvcvideo.conf with:

options uvcvideo quirks=0x0104

The specific quirk value depends on the failure mode logged — the ideasonboard UVC FAQ lists the common flags and what each addresses.

Step 5: Collecting logs before contacting Pollen Robotics support

If reseating does not get the camera into lsusb, the module itself may need replacement. Gather these before reaching out to support:

  • sudo dmesg | grep -i usb — USB subsystem output from the current boot
  • lsusb -v 2>/dev/null — full verbose device listing
  • journalctl -b | grep -i -E "camera|video|usb" — filtered journal entries from this boot

These logs let support distinguish a dead camera module from a dead cable — which matters for what gets ordered. Reachy 1 is older hardware, so confirming the failure mode before requesting parts is worth the few extra minutes.

Why Cheese reports “no webcam detected”

Cheese and most Linux camera apps enumerate devices through Video4Linux2 (V4L2). No /dev/video* node means V4L2 has nothing to list. The app is behaving correctly. It is not a separate fault and does not need separate debugging — fix the layers below it and the app works on its own.

Sources

Similar Posts