Reachy Robot 1 Camera Not Working: Full Linux Diagnostic Guide
What a blank lsusb output is actually telling you
If lsusb returns no camera entry at all, the Linux kernel has never seen the device. That is not a driver problem. Drivers only get involved after the USB subsystem has successfully enumerated a device — so no enumeration means the signal never reached the host controller. The fault is at the physical layer: a disconnected internal cable, a dead camera module, or a failed onboard USB hub.
This distinction matters immediately. Spending time on modprobe uvcvideo or kernel quirk flags when lsusb is blank is wasted effort. The two failure modes — hardware not detected versus hardware detected but no video node created — need completely different fixes.
Run these diagnostics before touching anything
The Reachy 1 routes its head cameras through internal USB connections. Before opening the enclosure, exhaust the software checks so you know exactly what you are dealing with.
Check dmesg for USB enumeration errors
Run sudo dmesg | grep -i usb right after powering the robot. Look for messages like “unable to enumerate USB device”, “device descriptor read” failures, or “device not accepting address”. These appear even when lsusb shows nothing — the kernel attempted to communicate with something and failed. That is more informative than total silence because it confirms the USB bus saw electrical activity but could not complete handshaking.
Pull the full USB device tree
Run lsusb -t to view the hub hierarchy. Reachy 1 routes cameras through an internal USB hub. If that hub itself is absent from the tree, you have a different failure point than the camera module — the hub or its power line is dead.
Verify the uvcvideo module
Run lsmod | grep uvcvideo. On modern kernels this loads automatically when a UVC-compatible camera enumerates. If a device appears in lsusb but uvcvideo is not loaded, try sudo modprobe uvcvideo and watch dmesg | tail -20 immediately after — you should see the driver binding. If modprobe fails with “module not found”, you may need the linux-modules-extra package for your running kernel version.
Use v4l2-ctl instead of ls /dev/video*
Install v4l-utils and run v4l2-ctl --list-devices. It shows device names and driver associations alongside node numbers, which makes it far easier to confirm which physical camera maps to which /dev/videoN entry. Parsing raw ls /dev/video* output tells you a node exists but nothing about what created it.
When lsusb is completely blank
No camera. No hub entry. Nothing. You are in hardware territory.
The most common cause on Reachy 1 is a loose or unseated internal USB cable. The head unit has limited space and camera cables can work loose during shipping, transit, or after repeated head movements over time. Before assuming the camera module has actually failed, check the physical connection.
- Power the robot completely off and disconnect it from mains power
- Consult the Pollen Robotics documentation for your model year before opening the head enclosure — the process differs between the 2021 and 2023 hardware revisions
- Check that the USB connector at the camera module end is fully seated and not canted at an angle
- Trace the cable to where it connects to the internal hub or main carrier board and check that end too
- Look for any visible damage: kinked jacket, bent pins, cracked connector housing
Reseating a loose connector is the fix in a meaningful number of these cases. It is worth checking before ordering replacement hardware.
If the cable looks fine and lsusb still shows nothing after reseating, the camera module itself may have failed. A dead module produces no USB activity at all — the bus stays silent as if nothing is plugged in.
When lsusb sees the device but /dev/video* stays empty
This is a separate problem. The USB subsystem enumerated the camera successfully, but no video device node was created. Nearly all USB cameras — including those commonly used in Reachy’s head — use the USB Video Class protocol and depend on the uvcvideo kernel module to create /dev/videoN entries.
Steps to try in order:
- Load the module:
sudo modprobe uvcvideo - Check
dmesg | tail -20right after — a successful bind looks like “uvcvideo: Found UVC 1.xx device” - Some cameras have non-standard descriptors that cause the driver to reject them. Create
/etc/modprobe.d/uvcvideo.confcontainingoptions uvcvideo quirks=0x80, then reload withsudo modprobe -r uvcvideo && sudo modprobe uvcvideo - Try a powered USB hub on an external port — underpowered USB lines can cause intermittent enumeration that looks like a driver problem
Confirming a camera module hardware failure
The cleanest confirmation: plug a known-working external USB webcam into the robot and verify it appears correctly in both lsusb and /dev/video*. If it does, the system’s USB stack and kernel modules are fine. The fault is isolated to the internal camera hardware. That evidence is also useful to send to Pollen Robotics support.
Getting support from Pollen Robotics
Pollen Robotics maintains documentation for the Reachy 2021 and 2023 lineups and an active community forum. If the robot is within its warranty period, contact them before opening the head enclosure — self-disassembly without guidance can affect coverage. When reaching out, bring the full output of dmesg | grep -i usb, lsusb -t, lsmod | grep uvcvideo, and journalctl -b | grep -i video, plus photos of any visible cable routing inside the head if you have already opened it. The more log data you provide upfront, the faster they can triage whether this is a warranty replacement situation.
Sources
- ideasonboard.org
- ideasonboard.org
- tldp.org
- pollen-robotics.github.io
- pollen-robotics.github.io
- docs.pollen-robotics.com
- forums.raspberrypi.com
- bbs.archlinux.org