Reachy Robot Camera Not Detected: A Step-by-Step Diagnosis Guide

ByPriya Nair

When lsusb shows nothing: what the diagnostics are really telling you

The commands you ran are useful, but only if you know how to read them together. An empty lsusb is the most telling result of all. It means the kernel’s USB host controller cannot electrically enumerate the camera — no driver can fix that, and no software workaround applies. The problem is almost certainly physical.

What each command is actually checking

Before jumping to fixes, it helps to understand exactly what stage failed:

  • lsusb — queries every USB device the host controller can see. A camera absent here has not been detected at all, not even as an unknown device.
  • ls /dev/video* — lists video device nodes the uvcvideo kernel driver creates once it attaches to a camera. On a healthy Reachy 1 with both cameras running, you’d expect eight nodes: /dev/video0 through /dev/video7. No nodes means the driver has nothing to attach to.
  • lsmod | grep video — verifies whether uvcvideo is loaded. If the camera isn’t in lsusb at all, this step is mostly academic — a loaded driver still cannot create nodes for a device the kernel cannot see.
  • journalctl -b | grep -i video — scans this boot’s system log for video-related messages. Pair it with dmesg | grep -i uvc for more targeted output from the driver layer.

Step 1: reseat the internal USB connection

The most common reason a Reachy 1 camera vanishes entirely from lsusb is a loose internal USB connector. These can work free during shipping, handling, or just regular use. Physical inspection comes first — every time.

Power the robot down completely and disconnect it from mains before opening the head. The camera module connects via an internal USB header or cable on the carrier board inside the head assembly. Look for:

  • A connector that is not fully seated in its socket
  • A ribbon cable or USB cable that has partially pulled free
  • Any visible damage to the connector body, socket, or cable sheath

Press each connector firmly home, then power back up and run lsusb again. If the camera device now appears, the remaining steps below are probably unnecessary.

Step 2: dig deeper with dmesg

If the camera appears in lsusb but still no /dev/video* nodes exist, pull more out of the kernel log:

dmesg | grep -i -E 'uvc|video|usb'

Watch for messages about bandwidth errors, unsupported descriptors, firmware load failures, or lines referencing the camera’s USB vendor and product ID. A clean driver attach looks like uvcvideo: Found UVC ... device. Errors here point to a driver-level mismatch rather than a pure hardware problem.

Step 3: check and reload the uvcvideo module

Confirm the driver is present:

lsmod | grep uvcvideo

If it is absent, load it manually:

sudo modprobe uvcvideo

Then check for device nodes again:

ls /dev/video*

If nodes appear now, add uvcvideo to /etc/modules so it loads at every boot. Some trimmed embedded Linux images omit optional modules — if modprobe returns “Module not found,” the kernel image may need to be rebuilt with CONFIG_USB_VIDEO_CLASS=m enabled.

Step 4: verify the ROS 2 camera service

Reachy 1 runs its camera pipeline through ROS 2. Even with working /dev/video* nodes, the cameras will not be usable in the SDK unless the corresponding ROS 2 node is publishing. With the robot fully booted, check:

ros2 topic list | grep image

A healthy system publishes to /left_image/image_raw/compressed and /right_image/image_raw/compressed. If those topics are missing while /dev/video* nodes exist, the camera launch service has not started correctly. Check its status via systemctl or whichever service manager the Reachy image uses.

If the camera still does not appear in lsusb

After careful physical inspection and reseating, if the camera remains completely absent from lsusb and dmesg shows no USB enumeration attempt for it at all, the camera module or its connecting cable has most likely failed. Collect your full dmesg output and contact Pollen Robotics support — note that Hugging Face acquired Pollen Robotics in 2025, so check the current documentation for the right support channel. They can advise on replacement hardware or further on-site diagnosis.

Sources


Similar Posts