Trouble running 5MP Camera Module starter program on Raspberry Pi 3B, no /dev/video0

Raspberry Pi Cameras
1

Hey everyone, first time posting so sorry if I’m missing something obvious here.

I got the 5MP Camera Module for my Raspberry Pi and I can’t get the starter program up at all. The weird part is the camera flashes a light once when the Pi powers on and then never again. If I run any of the programs nothing happens at all, no autofocus movement, no pictures taken.

Stuff I already did:

  • installed opencv and cloned the repo
  • sudo apt-get update and upgrade
  • opened the i2c0 port
  • ran sudo python Autofocus.py

ls /dev/video gives me a bunch of numbers but none of them are video0. I also shut off the legacy camera and now the camera isn’t recognized at all. And when I ran the bug report command it spit out:

ERROR: the system appears to be configured for the legacy camera stack

Any idea where I’m going wrong?

2

Hi, happy to help. A few things I need to know before we dig in:

  1. Which Raspberry Pi model are you on?
  2. What OS image are you running (and roughly how new is it)?
  3. Exactly which camera module? They aren’t all the same under libcamera.
  4. How are you powering the board? The motorized focus camera pulls more current than a normal camera, so weak supplies cause odd behaviour.
  5. Paste the raw output of vcgencmd get_camera and the full output you get when running sudo python Autofocus.py.

Also, can you confirm the repo path you cloned to?

3

I have a model 3b. I’m using rasbian since it’s a raspberry pi. The camera is the 5MP Camera Module for Raspberry Pi (the one with the motorized focus).

I originally had the Pi hooked up to a 5V 2A 5000mAH battery and then retried using house power, same thing either way.

The repo is at ~/Python_Files/RaspberryPi/Motorized_Focus_Camera

4

Thanks. Two things then.

First, the legacy camera question: on newer Bullseye images the vcgencmd get_camera command is no longer how you check the camera, and if the legacy stack is enabled at the same time as libcamera you get conflicting results. That ERROR message you saw ties into it.

Second, can you post the exact terminal output for these two states, before you disabled legacy and after? I want to see the raw lines rather than a summary:

vcgencmd get_camera

and the output of:

sudo python Autofocus.py

from the python folder of the repo.

5

Ok here is what I have.

Before I turned off the legacy camera:

admin@RPI:~/Python_Files/RaspberryPi/Motorized_Focus_Camera $ vcgencmd get_camera
supported=1 detected=1, libcamera interfaces=0

And running the script does this, no pictures come out anywhere:

admin@RPI:~/Python_Files/RaspberryPi/Motorized_Focus_Camera/python $ sudo python Autofocus.py
admin@RPI:~/Python_Files/RaspberryPi/Motorized_Focus_Camera/python $ ls
Autofocus.py
FocuserExample.py
libcamera-1.0.1-cp39-cp39-linux_armv7l.whl
multi_cameras_auto_focus.py
RpiCamera.py
AutofocusTest.py
Focuser.py
libcamera-1.0.2-cp39-cp39-linux_armv7l.whl
__pycache__

ls /dev/video gives a bunch of numbers but no video0 in the list.

After I disabled the legacy camera it got worse:

admin@RPI:~ $ vcgencmd get_camera
supported=0 detected=0, libcamera interfaces=0

So now the camera doesn’t seem recognized at all.

6

Also to be clear I’m not trying to use the legacy stack. I just kept landing on legacy camera pages when I googled the error. I wanted to disable the legacy support, not enable it. So how do I actually activate the camera with legacy off?

7

That actually explains a lot. That supported=0 detected=0 after disabling legacy is expected on newer Bullseye builds, because vcgencmd get_camera is a legacy-stack tool. It has no idea about libcamera, so once legacy is off it reports nothing found even if the camera is fine. Don’t use that command to judge the camera anymore.

On Bullseye with libcamera the correct checks are:

ls /dev/video*

If you see video0 in that list, the camera is recognized correctly under the libcamera stack.

Then to actually grab a frame:

libcamera-still -t 0

Can you run both of those and paste exactly what comes back?

8

Hmm ok, so I ran them.

admin@RPI:~ $ ls /dev/video*
/dev/video10  /dev/video13  /dev/video16  /dev/video19
/dev/video11  /dev/video14  /dev/video17
/dev/video12  /dev/video15  /dev/video18

Still no video0 in there.

And libcamera-still doesn’t go well either:

admin@RPI:~ $ libcamera-still -t 0
ERROR: *** no cameras available ***

So the camera still isn’t being picked up. Does the legacy camera need to be fully off for libcamera to see it, or is my ribbon cable the problem?

9

Two things could be going on, let’s rule out the config side first because it’s free.

Make sure the legacy camera stack is actually disabled, then reboot:

  1. Run sudo raspi-config
  2. Go to Interface Options → Legacy camera and select it to disable it
  3. Reboot the Pi again

After it comes back up, run ls /dev/video* again and then libcamera-still -t 0.

If video0 still doesn’t show up, then we’re looking at a hardware/detection side problem rather than a software one, and I’ll want a proper bug report from you.

10

Did the raspi-config steps and rebooted. Same result.

admin@RPI:~ $ ls /dev/video*
/dev/video10  /dev/video13  /dev/video16  /dev/video19
/dev/video11  /dev/video14  /dev/video17
/dev/video12  /dev/video15  /dev/video18

admin@RPI:~ $ libcamera-still -t 0
ERROR: *** no cameras available ***

No video0 at all. I tried reseating the ribbon cable on the camera side too and it didn’t change anything.

11

Alright, at this point I want the diagnostic dump so I can see what the libcamera stack is actually detecting. Reboot the device first, then run this from your home folder:

wget -O arducam-camera-bug-report https://github.com/ketai-dhr/arducam-camera-bug-report/releases/download/tools/arducam-camera-bug-report
chmod +x ./arducam-camera-bug-report
./arducam-camera-bug-report

It produces arducam-bug-report.txt in the current directory. Attach that file to your next post. If you’d rather not post it publicly, send it to me and I’ll take a look.

While you’re at it, double check the ribbon cable orientation at the Pi end. On a 3B the contacts should face the board (away from the Ethernet port side) and the cable should be fully seated in the connector, including the one on the camera. A single reversed ribbon gives exactly this ‘lights up once, then nothing’ behaviour.

12

Ran the bug report, file attached. A couple of things I noticed in it: it shows the legacy camera is disabled, and near the bottom it lists the detected cameras as none, same as the libcamera-still error.

I did check the ribbon at the Pi end and it looks seated the way you described, contacts toward the board. I don’t have a second ribbon to swap in right now.

13

Thanks, that confirms the picture.

Summary of where we’re at:

  • The vcgencmd get_camera output is a red herring. On newer Bullseye builds that command no longer reflects camera support, so supported=0 detected=0, libcamera interfaces=0 after disabling legacy is not evidence of a fault by itself.
  • The correct modern checks are ls /dev/video* (should contain video0) and libcamera-still -t 0. Right now neither the device node nor libcamera sees a camera, and the bug report agrees: no cameras detected.
  • Your setup steps (opencv, repo clone, apt-get update/upgrade, i2c0 enabled, sudo python Autofocus.py, both battery and house power) are all fine and aren’t the cause. Powering from house power rules out the 5V 2A battery as the factor.
  • So this is no longer a repo or Python problem. Config-wise, the legacy stack is off and the system is on libcamera, and libcamera still reports no cameras. With the ribbon reseated and still no video0, the remaining suspects are the ribbon cable itself or the camera module’s connection/detection. A spare ribbon or testing the camera on another Pi would separate those two quickly.

The one software avenue left is to make sure your Bullseye image is current, since older libcamera builds on 3B occasionally fail to enumerate the sensor. If you can, flash the latest Bullseye, keep the legacy camera disabled, and re-check ls /dev/video* before touching any code. If video0 still doesn’t appear with a known-good ribbon, then it’s a hardware fault and the camera/ribbon needs replacing. Post back with the new bug report if the fresh image changes anything and I’ll pick it up from there.