Hi all, I’m starting a new project and need to use a Raspberry Pi 3 together with an Arducam 2MP global shutter OV2311 camera. The weird thing is I CAN take pictures with the libcamera command line, but I just can’t get the camera working from Python. When I follow the setup steps I found in the docs, the build fails with a compile error and then everything after that also breaks. Any idea what I’m doing wrong?
What works:
libcamera-still -t 5000 -o test.jpg
That produces a proper image.
What does not work: anything Python-related. My plan was to feed the camera into a v4l2 loopback device so my Python code could open it like a normal webcam. None of it comes up.
Welcome! Let’s dig into this. A few details will help us a lot:
Which Raspberry Pi model and which exact camera module are you using?
Which OS release and kernel are you on? Please share the output of uname -r.
Which documentation page did you follow?
Can you paste the exact commands you ran, in order, and the full error log?
The fact that libcamera-still works but Python doesn’t usually points at the bridge/driver layer rather than the camera itself, but let’s confirm with the real output.
I followed the driver installation instructions from the Arducam camarray / synchronized stereo HAT docs page (the driver-installation section).
Commands I ran:
libcamera-still -t 5000 -o test.jpg
cd ~
git clone https://github.com/umlaeute/v4l2loopback.git
cd v4l2loopback
make clean && make
make && sudo make install
sudo depmod -a
sudo modprobe v4l2loopback video_nr=3
cd ~/libcamera # Installation using deb does not need to be executed
export GST_PLUGIN_PATH=$(pwd)/build/src/gstreamer # Installation using deb does not need to be executed
gst-launch-1.0 libcamerasrc ! 'video/x-raw,width=1920,height=1080' ! videoconvert ! tee ! v4l2sink device=/dev/video3
And the log:
Cloning into 'v4l2loopback'...
remote: Enumerating objects: 3408, done.
remote: Counting objects: 100% (383/383), done.
remote: Compressing objects: 100% (180/180), done.
remote: Total 3408 (delta 222), reused 332 (delta 203), pack-reused 3025
Receiving objects: 100% (3408/3408), 1.17 MiB | 4.12 MiB/s, done.
Resolving deltas: 100% (2038/2038), done.
rm -f *~
rm -f Module.symvers Module.markers modules.order
make -C /lib/modules/`uname -r`/build M=/home/pi/v4l2loopback clean
make[1]: *** /lib/modules/5.15.56-v7+/build: No such file or directory. Stop.
make: *** [Makefile:71: clean] Error 2
Building v4l2-loopback driver...
make -C /lib/modules/`uname -r`/build M=/home/pi/v4l2loopback KCPPFLAGS="-DSNAPSHOT_VERSION='"v0.12.7-289-g76434ab"'" modules
make[1]: *** /lib/modules/5.15.56-v7+/build: No such file or directory. Stop.
make: *** [Makefile:51: v4l2loopback.ko] Error 2
modprobe: FATAL: Module v4l2loopback not found in directory /lib/modules/5.15.56-v7+
bash: cd: /home/pi/libcamera: No such file or directory
bash: gst-launch-1.0: command not found
So three separate failures: the loopback module never builds, there’s no ~/libcamera dir, and gst-launch-1.0 isn’t even found.
Thanks, that log is very clear. Let’s break down what happened:
The first error is the key one:
make[1]: *** /lib/modules/5.15.56-v7+/build: No such file or directory. Stop.
That path (/lib/modules/$(uname -r)/build) is a symlink the kernel build system needs. If it’s missing, you don’t have the kernel headers/build tree installed for the running kernel (5.15.56-v7+). Without that, v4l2loopback can never compile. And because the module never builds, sudo modprobe v4l2loopback video_nr=3 fails with Module v4l2loopback not found.
The other two errors are separate missing pieces:
cd ~/libcamera — that directory only exists if you built libcamera from source, which the deb-based install doesn’t need.
bash: gst-launch-1.0: command not found — the GStreamer tools aren’t installed at all.
Can you confirm a couple of things so we’re sure it’s only the headers:
ls -l /lib/modules/$(uname -r)/build
dpkg -l | grep -i headers
lsmod | grep v4l2loopback
which gst-launch-1.0
Also, what are you actually trying to do in Python? OpenCV VideoCapture? picamera? That affects the right approach.
ls -l /lib/modules/$(uname -r)/build
# ls: cannot access '/lib/modules/5.15.56-v7+/build': No such file or directory
dpkg -l | grep -i headers
# (nothing relevant installed)
lsmod | grep v4l2loopback
# (nothing)
which gst-launch-1.0
# (no output)
So yes, no build dir, no headers package, module not loaded, no gst-launch.
What I want is to grab frames in Python. I figured the easiest path was to push the camera into a v4l2 loopback device with gst-launch and then just open it from OpenCV like a webcam, which is why I was following that doc. But maybe that’s the wrong approach now?
I did try sudo apt install raspberrypi-kernel-headers but the kernel I’m running is 5.15.56-v7+ and I’m not sure it matched — the build dir still wasn’t there afterwards.
That confirms the diagnosis. The v4l2loopback + GStreamer path you were following is the older workflow, and it depends on having kernel headers that exactly match 5.15.56-v7+ — which is often a mismatch on these Bullseye images, which is exactly why the make step dies on the missing /lib/modules/.../build link. To even get that route working you’d have to get the matching headers for that specific kernel, then install GStreamer plus the loopback module, then still bridge libcamera into it. That’s a lot of moving parts.
Good news: there’s a much better solution now for your use case. Instead of the v4l2loopback/GStreamer detour, use the Picamera2-based guide — it’s the recommended way to access Arducam cameras from Python and avoids the whole loopback dance.
Can you give that one a shot and report what you get? If Python still can’t see the camera after following it, paste the output and we’ll continue from there.
Ah, that makes sense — I assumed the loopback thing was still the supported route. I’ll stop chasing the kernel headers and drop the v4l2loopback and gst-launch steps entirely.
Before I go ahead: is it safe to assume libcamera-still continuing to work means the camera and driver side are fine, and the only broken part was the bridge into Python? I just want to be sure I’m not missing an underlying hardware issue.
I’ll follow the Picamera2 guide and come back with results.
Correct — if libcamera-still -t 5000 -o test.jpg produces a good image, the camera, the driver, and the libcamera stack are all working. The only thing that was broken was the legacy bridge approach into Python, which failed for two independent reasons:
The v4l2loopback module couldn’t compile because the kernel build directory was missing:
make[1]: *** /lib/modules/5.15.56-v7+/build: No such file or directory. Stop.
which in turn caused:
modprobe: FATAL: Module v4l2loopback not found in directory /lib/modules/5.15.56-v7+
The GStreamer tooling wasn’t installed at all (gst-launch-1.0: command not found), and the ~/libcamera source tree the doc assumed didn’t exist because you installed libcamera via deb.
So nothing points at the camera hardware. Following the Picamera2 guide is the recommended path now, and it removes the need for the loopback device and GStreamer entirely.
Quick summary of where this landed so anyone else hitting the same thing can follow along:
Root cause: the old procedure (v4l2loopback + GStreamer to expose the camera as a /dev/video node) was being followed, but on this image it fails because there are no matching kernel headers for 5.15.56-v7+ (/lib/modules/5.15.56-v7+/build missing), so v4l2loopback never builds, modprobe can’t find it, and on top of that gst-launch-1.0 isn’t installed.
If Python still can’t access the camera after following that guide, post the exact errors and we’ll debug from there. And if the documentation still points people at the loopback route for this scenario, that’s worth updating too.