Reachy Robot 1 Camera Not Detected: A Hardware-First Diagnostic Guide

Start with what lsusb actually tells you

When lsusb returns nothing camera-related and /dev/video* is empty, the fault sits below the driver layer. The Linux kernel never got the chance to load uvcvideo because the USB device never announced itself. That distinction matters: it tells you to look at the hardware, not the kernel modules.

A working Reachy 1 setup should expose several /dev/video nodes — typically eight, running from /dev/video0 through /dev/video7. Seeing none of them alongside a completely silent lsusb is a clear sign the camera is not reaching the system at all.

Check the internal cable first

Reachy 1’s cameras sit inside the head and connect to the compute unit via internal cables. These can work loose without any drop or rough handling — vibration over time, or a reassembly that didn’t fully seat the connector. Before assuming the camera module is dead, re-seat that cable.

To do it safely:

• Power down the robot completely and disconnect from mains before opening the head enclosure.
• Locate the connector running from the camera module to the compute board. On Reachy 1 this is a small-pitch flat flex cable — push it firmly home and inspect for bent pins or visible damage.
• Re-seat it carefully, then close the enclosure before powering back up.
• Run lsusb immediately after boot and look for a camera device in the output.

If the camera now appears in lsusb, you’re past the hardware hurdle. If it still doesn’t, contact Pollen Robotics support before going further — they can confirm whether a module swap is needed and whether it falls under warranty.

When lsusb sees the camera but /dev/video* is still empty

This is a different failure mode. The USB stack sees the hardware but no driver has claimed it. Short version: uvcvideo isn’t loaded. Check:

lsmod | grep uvc

Nothing? Load it manually:

sudo modprobe uvcvideo

Then re-run ls /dev/video*. If the module loads but the device node still doesn’t appear, the kernel log will usually say why:

dmesg | grep -i "uvc\|video\|camera"

Common causes at this stage: a malformed USB descriptor that confuses the driver, a power negotiation failure on the USB bus, or a USB audio interface claiming the device before uvcvideo gets a chance to bind.

Kernel configuration check

On a customised or embedded kernel, UVC support may not be compiled in. The relevant options are MEDIA_SUPPORT, MEDIA_CAMERA_SUPPORT, MEDIA_USB_SUPPORT, and USB_VIDEO_CLASS. Verify quickly with:

grep -E "MEDIA_SUPPORT|USB_VIDEO_CLASS" /boot/config-$(uname -r)

Isolating the camera service from the SDK

Reachy 1 runs its camera stack inside a ROS-based service. For clean terminal output without the SDK layer in the way, stop it first:

systemctl --user stop reachy_sdk_server.service

Then bring up the camera controllers directly:

ros2 launch camera_controllers camera_controllers.launch.py

Errors print live to the terminal. You can also check whether the ROS camera topics are actually publishing:

ros2 topic echo /left_image/image_raw/compressed

No output and no errors in the launch — that puts the problem upstream of the service. Back to hardware or driver.

Extra tools worth running

v4l2-ctl gives more context than just listing device nodes:

v4l2-ctl --list-devices

It shows device names alongside the /dev/videoX paths. Useful when multiple nodes exist and you need to know which one belongs to the Reachy camera.

For a verbose USB dump of a specific device, take the vendor:product ID from lsusb and substitute it for xxxx:yyyy:

sudo lsusb -d xxxx:yyyy -vvv

To watch kernel events live as you unplug and replug the cable:

sudo dmesg -w | grep -i video

When to contact Pollen Robotics

Re-seating the cable and running through the steps above resolves most of these cases. If lsusb still shows nothing after that, the camera module may genuinely be faulty. Reach out to Pollen Robotics’ after-sales team with photos of the connector area and your purchase documentation — they can advise on replacement and confirm warranty status. Don’t assume module failure until the cable has been ruled out.

Sources

• docs.pollen-robotics.com
• pollen-robotics.github.io
• pollen-robotics.github.io
• ideasonboard.org
• docs.kernel.org
• manpages.ubuntu.com
• linuxvox.com
• tldp.org