Reachy Robot 1 Camera Not Detected: Full Diagnosis and Fix Guide

ByPriya Nair

What blank lsusb output actually tells you

Running lsusb and seeing nothing camera-related isn’t a driver problem — the kernel hasn’t seen a device at all. That’s a fundamentally different situation from device detected but misbehaving, and it narrows the search considerably. Same story if ls /dev/video* returns nothing: there’s no device node to enumerate because nothing showed up on the bus.

On a working Reachy 1, both cameras appear in lsusb output and you’d see eight /dev/video* nodes — four per camera. Complete absence of all of these means start at the hardware layer, not the software layer.

The Reachy 1 camera architecture

Reachy 1 mounts two Raspberry Pi camera modules inside the head — one macro lens, one wide-angle. They connect to the compute hardware via CSI (Camera Serial Interface) ribbon cables. CSI connections are delicate. Unlike a USB plug that clicks in firmly, a CSI ribbon just slides into a ZIF (zero insertion force) socket held by a small plastic latch. A cable can look correctly installed while making intermittent or no contact.

Those cameras then present themselves to Linux as USB Video Class (UVC) devices via an onboard bridge chip — which is why lsusb is a meaningful first check even though the raw sensor interface is CSI, not USB.

Step 1: Inspect the physical connection

Before running any more software diagnostics, power the robot down and open the head to look at the ribbon cables. This step comes first because no software command can compensate for a bad physical connection.

  • Check both ends of each ribbon cable — the camera-module end and the board end.
  • Metal contacts should face the correct direction (usually away from the latch, toward the board).
  • Press the cable fully into the socket, then push the latch closed until it clicks.
  • Inspect the cable itself for kinks, creases, or hairline cracks near either connector. A cracked cable can fail completely or flicker between working and not.

Robot joints flex during operation. Vibration alone is enough to walk a ribbon cable loose over weeks of use. This is the single most common root cause of a camera that vanishes from the system entirely.

Step 2: Read dmesg right after boot

After reseating the cables, boot the robot and run:

dmesg | grep -iE "usb|video|uvc|camera"

This catches kernel-level USB enumeration events at startup — more targeted than journalctl -b | grep -i video. On a working system you’ll see the camera’s USB vendor and product ID appear, followed by something like uvcvideo: Found UVC X.X device as the driver claims it.

If dmesg is still silent about any camera device after a reseat, the module either isn’t powered or isn’t physically reaching the bus. No driver or configuration change fixes that.

Step 3: Confirm the uvcvideo module is loaded

Reachy 1 cameras expose a UVC interface. Verify the driver is present:

lsmod | grep uvcvideo

If nothing comes back, load it manually:

sudo modprobe uvcvideo

Then reboot and check lsusb again. On modern Ubuntu or Debian systems this module loads automatically on device insertion, so a missing driver is rare — but it takes thirty seconds to rule out.

Step 4: Isolate the ROS2 camera stack

Once cameras appear in lsusb and /dev/video*, the fault may be further up the stack. Check the SDK server first:

systemctl --user status reachy_sdk_server.service -n 10000

Then stop the service and launch the camera controller in isolation:

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

Watch the terminal output directly. Persistent “waiting for image” messages mean the driver isn’t delivering frames — even if /dev/video* nodes exist, they may not be producing data.

Then check whether the ROS topics are publishing:

ros2 topic list | grep image
ros2 topic echo /left_image/image_raw/compressed --once

Topics listed but echo hanging means the camera nodes are running but not receiving frames. Topics absent entirely means the launch itself failed earlier.

Quick triage: which layer is broken

  • Nothing in lsusb, no /dev/video* nodes, dmesg silent — hardware fault. The camera is not reaching the system bus. Inspect and reseat cables; if that changes nothing, the module may be failed.
  • Device appears in lsusb but no /dev/video* nodes — driver fault. The device was enumerated but no video interface was claimed. Try modprobe uvcvideo.
  • /dev/video* nodes present but ROS topics carry no data — software or configuration fault. The kernel sees the hardware; the issue is in the ROS2 stack or the SDK service.

The blank-diagnostic scenario in the original report — nothing in lsusb, nothing in /dev/video* — falls squarely into the first bucket. Physical inspection before any further command-line work.

If reseating the cables changes nothing

A camera module that still doesn’t appear in lsusb after the cable has been reseated and confirmed undamaged is likely failed. Share your dmesg output, a description of the cable’s physical condition, and a summary of steps already attempted when you contact Pollen Robotics support. They can confirm whether a replacement module is needed and guide the internal disassembly safely — opening a robot head without guidance risks stressing other connections that are currently fine.

Sources


Similar Posts