Reachy Robot 1 Camera Not Detected: Diagnosing USB, Drivers, and Hardware

Reading the Diagnostic Output

When lsusb returns nothing for the cameras, the diagnosis splits immediately into two tracks: either the hardware was never enumerated by the kernel, or the UVC driver hasn’t claimed the device. The fix is completely different for each.

The four commands together tell a clear story. lsusb lists every USB device the kernel has seen. If the cameras aren’t there at all, the kernel never received a USB descriptor from them — that’s a hardware-level failure: loose cable, dead controller, or dead module. ls /dev/video* will be empty either way if lsusb is already empty, but if lsusb shows the device and /dev/video* is still missing, a missing driver is the more likely culprit. lsmod | grep video checks whether the uvcvideo module is loaded. And journalctl -b | grep -i video shows what the system logged about video devices at boot — look for lines containing uvcvideo or errors like device descriptor read/64, error -110, which means the USB stack timed out trying to talk to the device.

Check dmesg Before Touching Hardware

Run this first:

sudo dmesg | grep -iE '(usb|uvc|video|camera)'

Look for “unable to enumerate USB device” — that message, with no matching device ID, means the kernel tried and failed at the electrical layer. Error code -110 is a USB timeout; -71 is a protocol error. Both typically point to a bad cable or loose connector. Confirm the USB host controller itself is alive by plugging in a known-good USB device and running dmesg again. If that device shows up fine, the host controller is working and the problem is local to the camera connection.

For a live watch as you replug:

sudo dmesg --follow

Disconnect and reconnect the external cable or power cycle the robot, then watch for any enumeration attempt in the log.

Physical Connection Check

Reachy 1 uses Raspberry Pi camera modules mounted inside the head, connected back to the compute unit via internal USB cables. Orbita’s ball joint actuator puts real flex on those cables during head movement, and connectors can work loose over time. This is the most common cause of a camera that was previously working and has since disappeared from lsusb entirely.

Steps:

• Power down the robot completely before opening any enclosure
• Locate the internal USB cable runs from the camera modules to the main board or USB hub
• Reseat each connector firmly at both ends — camera side and board side
• Look for visible damage: kinked cables, cracked connector housings, or partially pulled-out pins
• Check that cable routing allows enough slack for head movement — a cable pulled taut by Orbita motion can intermittently disconnect
• Power back up and immediately re-run lsusb

If the cameras now appear in lsusb, reseating fixed it. Make sure to re-route with enough slack so the issue doesn’t recur.

Load the UVC Driver

If lsusb shows the camera device but /dev/video* is still empty, the UVC driver likely hasn’t loaded. Check whether the module is present:

lsmod | grep uvcvideo

If nothing comes back, load it manually:

sudo modprobe uvcvideo

Then check for device nodes:

ls /dev/video*

A successful bind produces a dmesg line like uvcvideo: Found UVC 1.00 device. If modprobe fails with “Module uvcvideo not found”, you may be missing extra kernel modules after a recent update:

sudo apt-get install linux-modules-extra-$(uname -r)

Then try modprobe again. On some systems the module loads on demand when a UVC device is plugged in — but if the device was already connected at boot with a bad connection, it may never have triggered. Replug (or power cycle the robot) after loading the module.

Isolating the ROS Camera Stack

If the OS can see the camera but the Reachy software stack still can’t, stop the main service first. Running the camera controllers in isolation separates any ROS configuration problem from the underlying hardware issue:

systemctl --user stop reachy_sdk_server.service
ros2 launch camera_controllers camera_controllers.launch.py

In a second terminal:

ros2 topic list | grep image

You should see /left_image/image_raw/compressed and /right_image/image_raw/compressed. Both topics appearing but no frames publishing can indicate a power issue with the camera module itself rather than a USB or driver problem — particularly if the camera is visible in lsusb but dmesg shows repeated enumeration retries.

When It Points to a Hardware Failure

If reseating cables doesn’t make any device appear in lsusb and dmesg shows no enumeration attempt at all, the camera module may be dead. Reachy 1 uses Raspberry Pi camera modules, which are available as separate components. Pollen Robotics support can confirm which revision is installed and supply a replacement. Contact them at [email protected] with photos of the head interior, your invoice number, and a summary of what you’ve already tried — that speeds things up considerably.

Sources

• docs.pollen-robotics.com
• pollen-robotics.github.io
• help.ubuntu.com
• bbs.archlinux.org
• medium.com
• github.com
• wiki.seeedstudio.com