Reachy Robot Camera Not Detected: Diagnosing a CSI Ribbon Cable Failure on Linux

ByPriya Nair

What empty lsusb output is actually telling you

If lsusb returns nothing for the camera, that rules out a driver problem immediately. It means the operating system cannot see any camera device at the USB bus level at all. For a standard USB webcam, that would be the end of the story. For Reachy 1, it is almost the wrong diagnostic to run in the first place.

Reachy 1 cameras are not USB devices

The original Reachy 1 uses two Raspberry Pi cameras connected to the onboard Raspberry Pi 4 via CSI (Camera Serial Interface) ribbon cables — not USB. CSI is a dedicated point-to-point interface between the image sensor and the Pi’s image signal processor. Because it bypasses the USB bus entirely, lsusb will never list these cameras, even when everything is working perfectly. Running it was not wrong exactly, but it can only ever come back empty for a CSI device.

What the empty output does confirm is this: you are almost certainly looking at a hardware-layer problem, not a software one. That distinction matters when deciding where to look next.

Check the physical CSI ribbon cable first

CSI ribbon cables are fragile. They look connected when they are not, and a single mis-seat produces exactly the symptom described — nothing in /dev/video*, nothing in the kernel logs, no response from any camera tool.

Before opening the head assembly, power the robot down completely and disconnect it from mains. Then:

  • Locate the two CSI connectors on the Raspberry Pi 4 inside the head. Each connects one camera.
  • Press the locking tab gently to release, pull the ribbon out, inspect the gold contacts for tarnishing or physical damage, then reseat the cable and press the latch back down.
  • Check cable orientation — the contact strip must face toward the connector’s contact pads, not away from them. Getting this backwards is easy and looks fine to the eye.
  • Trace the cable run through the head mechanism and look for kinks, tight bends, or pinch points. A single sharp fold can sever the fine internal traces without visibly breaking the cable jacket.

Reassemble and power up before running any further software checks.

The diagnostic commands that actually apply to CSI cameras

Tools like Cheese, v4l2-ctl, and lsusb are designed for USB UVC cameras. CSI cameras on Raspberry Pi need a different set of commands.

On older Raspberry Pi OS (Buster and earlier)

The legacy camera stack uses a firmware-level detection command:

vcgencmd get_camera

A working result looks like supported=1 detected=1. If detected=0, the Pi firmware cannot see the sensor at all. That is a strong pointer to a physical fault — bad cable, wrong orientation, or a dead sensor. If the command is not found, you are probably running a newer OS with the libcamera stack instead.

On newer Raspberry Pi OS (Bullseye and later)

Raspberry Pi OS Bullseye moved to libcamera. Try:

libcamera-hello --list-cameras

“No cameras available” means the kernel driver did not load the device. Then check the kernel ring buffer directly:

dmesg | grep -i csi
dmesg | grep -i imx
dmesg | grep -i ov5647

These lines show whether the kernel attempted to probe the sensor at boot and what happened. No output here at all is another solid indicator of a physical problem — the kernel never saw a device to probe.

Confirming the /dev/video* situation

With working CSI cameras, ls /dev/video* should list at least two nodes. If the listing is empty but lsmod | grep v4l2 shows the module loaded, the sensor is not being probed. That loop leads back to the cable or the sensor hardware.

ROS2 and the Reachy camera service

Reachy’s software stack wraps camera access in a ROS2 service. Even if the cameras work at the OS level, a faulting service can swallow errors silently. To isolate which layer is misbehaving, stop the main service and launch the camera controller manually so you get live log output:

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

If the launch exits immediately with a camera-not-found error, the problem is at the OS or hardware layer — go back to the CSI diagnostics above. If it runs but produces no data, check the ROS2 image topics:

ros2 topic list | grep image

A healthy system publishes to /left_image/image_raw/compressed and /right_image/image_raw/compressed. Absence of those topics while the service appears to run points to a configuration issue rather than a hardware one.

When the sensor itself has failed

If reseating the cable changes nothing and firmware detection still reports zero, the camera module may have failed outright. Raspberry Pi camera modules can die from electrostatic discharge during handling or from mechanical stress inside the head assembly. Replacement sensors are available from many distributors. Before ordering, confirm which generation is fitted in your unit — the v1 module uses an OV5647 sensor and the v2 uses an IMX219. The connectors look the same but the modules are not interchangeable. Pollen Robotics support can confirm the correct part for your specific Reachy 1 build.

Sources


Similar Posts