Maker ยท Technical Deep-Dive

AIY Vision Kit โ€” Camera Replacement & Final Fix

Follow-up to the initial troubleshooting log, covering the camera hardware failure and its resolution

Status: Resolved. Camera confirmed working end-to-end โ€” detection, capture, and a clean photo โ€” after ruling out the cable and config, then finding and fixing two separate real issues: a dead original sensor and a background service silently holding the camera open.

The short version

Background

After getting WiFi and SSH working, the camera still wouldn't detect (vcgencmd get_camera โ†’ detected=0) despite correct cable orientation and multiple reseats. Suspected either a bad cable or a dead sensor after 9 years in storage.

1. Replaced the cable first โ€” no change

Swapped in a new Pi Zero camera cable, kept the original 2017 camera module. Still detected=0. Ruled out the cable as the culprit.

2. Replaced the camera โ€” detected!

Swapped in a new Raspberry Pi Camera Module V2.1 (8MP, Sony IMX219) โ€” a different sensor than the kit's original 5MP V1 (OV5647), since that's what was available to buy.

vcgencmd get_camera
supported=1 detected=1

Confirmed: the original 2017 camera module had failed after nearly a decade unused. Cable, Bonnet, and config were never the problem.

3. New error: ENOSPC on capture

Detection worked, but raspistill -o test.jpg failed:

mmal: mmal_vc_component_enable: failed to enable component: ENOSPC

This looked like a hardware fault at first, but turned out to be two stacked software issues โ€” neither one hardware-related.

3a. GPU memory too low for the 8MP sensor

Original gpu_mem=128 was tuned for the 5MP sensor. Bumped it to 256 in /boot/config.txt, rebooted, confirmed with vcgencmd get_mem gpu โ†’ gpu=256M. Error persisted โ€” so this wasn't the full story.

3b. Background service silently holding the camera

Used the official Raspberry Pi Engineering diagnostic method (start_debug=1 in config.txt + sudo vcdbg log assert) to get a firmware-level trace. The trace ruled out the "camera physically dead" signature (imx219_open assert) and pointed to a generic peripheral-open failure instead โ€” a sign of a resource conflict, not hardware.

Checked for background processes:

sudo systemctl list-units --type=service --state=running | grep -i -E "aiy|vision|camera|joy"

Found the culprit: joy_detection_demo.service โ€” a demo the AIY image auto-starts on every boot, which was already holding the camera open via MMAL before raspistill could touch it.

sudo systemctl stop joy_detection_demo.service
sudo systemctl disable joy_detection_demo.service

4. Success

raspistill -o test.jpg

Ran silently, produced a real 4.3MB JPEG โ€” first working photo from this kit. โœ…

5. Survived reassembly

After putting everything back in the cardboard enclosure:

vcgencmd get_camera
supported=1 detected=1

raspistill -o test_after_reassembly.jpg

Clean success again โ€” confirms the fix (new camera + gpu_mem + disabled joy service) is stable, not a fluke.

Root causes, in order discovered

  1. Original camera module was dead (age-related hardware failure) โ€” not a cable or config issue.
  2. GPU memory needed raising for the higher-resolution replacement sensor (128MB โ†’ 256MB).
  3. A background demo service was silently occupying the camera โ€” the actual final blocker, found via the official firmware debug-log method rather than guesswork.

Key takeaway

When a "camera not working" error persists after fixing the obvious hardware causes, check what else might already have the camera open โ€” background services from the original OS image are an easy thing to overlook, especially on a system you didn't build from scratch yourself.

Reference documents