First open-source end-to-end emulation of the AI-Thinker ESP32-CAM
in QEMU, paired with a browser webcam → firmware bridge so users can
develop camera sketches without hardware. Status: esp_camera_init()
returns ESP_OK; OV2640 chip-id verifies (PID/VER/MIDH/MIDL exactly
match the datasheet); GPIO 25 VSYNC NEGEDGE interrupt enabled by
the upstream driver. Final piece (cam_task accepting frames) is in
progress — descriptor walker fix landed in this commit.
Backend (Python/FastAPI):
- simulation.py: camera_attach/frame/detach WS handlers
- esp32_worker.py: ctypes binding to velxio_push_camera_frame +
feature-detection fallback for older DLLs
- esp32_lib_manager.py: forward camera commands to the worker stdin
- esp-idf-template/main/CMakeLists.txt: esp32-camera headers added
via add_prebuilt_library + REQUIRES driver (resolves i2c_master_*
symbols). LED_BUILTIN=2 fallback for sketches that hardcode it.
Frontend (React/TS):
- EditorToolbar.tsx: ESP32-CAM (and the rest of the ESP32 family)
added to isQemuBoard list — Run button now starts the QEMU bridge
for these boards instead of falling through to the AVR path
- useWebcamFrames.ts: getUserMedia → OffscreenCanvas →
toBlob('image/jpeg') → base64 → WS at ~10 fps
- CameraToggle.tsx: header button with status colors + frame counter
- SimulatorCanvas.tsx: render CameraToggle for esp32-cam boards
- Esp32Bridge.ts: sendCameraAttach/Frame/Detach + chunked btoa
- useSimulatorStore.ts: diagnostic log on compileBoardProgram
- components-metadata.json: regen including esp32-cam component
Submodule pointer:
- wokwi-libs/qemu-lcgamboa → ff8eee0 (camera devices commit on
davidmonterocrespo24/qemu-lcgamboa branch picsimlab-esp32)
Investigation + tests in test/test-esp32-cam/:
- 13 autosearch markdown docs (overview, SOTA, OV2640 spec, DVP/I2S
spec, build blueprint, blockers resolved, descriptor walker fix)
- 5 sketches (camera_init, sccb_probe, dma_smoke, frame_roundtrip,
webcam_demo) + 8 live + WS regression tests
- README with the user-facing flow
.gitignore:
- libqemu-*.dll.{pre-camera,new,bak} (rollback points, regenerated)
- wokwi-libs/esp32-camera/ (clone consumed by arduino-esp32 path,
not part of this repo)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| README.md | ||
| echo_server.py | ||
| webcam_capture.html | ||
README.md
prototypes
Standalone validation prototypes that run outside the pytest suite. Use these to prove individual layers work before committing to the full shim.
webcam_capture.html + echo_server.py
Validates the browser-side path described in
autosearch/03_browser_webcam_capture.md:
getUserMediapermission grant<video>→ canvas → JPEG encode- WebSocket binary frame transport
- bandwidth at the chosen fps/quality
# Terminal 1: tiny echo server
pip install websockets
python test/test-esp32-cam/prototypes/echo_server.py
# Browser: open the HTML file directly (file:// is fine)
open test/test-esp32-cam/prototypes/webcam_capture.html
# (or right-click → "open with browser" on Windows)
Click Start camera, grant permission. Two video panes should appear: the live feed on the left, the echoed JPEG on the right. The frame counter at the right should climb at the configured fps. If you see the echoed image update, the transport is good and the only thing left is the firmware shim.
What's still to come
When the firmware-side shim from autosearch/04 ships, the natural
next prototype is:
webcam_to_velxio_backend.html— point the same capture loop at the real Velxio simulation WebSocket using the newcamera_framemessage type, with a sketch likesketches/camera_init/camera_init.inorunning underneath.
That's intentionally not built yet — until the backend route knows
camera_frame, the prototype would just sit there with frames being
dropped. See tests/test_camera_websocket.py for the
expected-failure tests that gate this transition.