ESP32-CAM Projects: Complete Setup Guide

The ESP32-CAM is the cheapest way to put a camera on the internet: a ~$10 board that combines an ESP32-S with an OV2640 camera module, WiFi, Bluetooth, and a microSD slot. Students use it for surveillance robots, wildlife camera traps, door locks with face detection, and timelapse recorders. It is also the board with the highest frustration-per-rupee ratio in the ESP32 family — almost entirely because of two things: it has no USB port (you upload code through an external adapter with a specific wiring ritual), and it is brutally sensitive to power supply quality.

This guide walks the full setup the way it actually goes: the board's anatomy, power requirements that prevent the infamous brownout resets, the FTDI upload wiring, Arduino IDE configuration, the CameraWebServer example, face detection with honest limits, SD card storage, and a diagnosis table for every common error message. Get the power and wiring right once and the board behaves; get them wrong and nothing else you try will help.

The board: what you actually bought

The common "ESP32-CAM" is the AI-Thinker module: an ESP32-S chip, an OV2640 2-megapixel camera on a ribbon connector, a microSD card slot, a bright onboard LED (GPIO 4 — useful as a flash), and broken-out GPIOs. Three facts shape everything else:

No USB-to-serial chip. Unlike a DevKit board, there is no USB port. You program it through the U0TXD/U0RXD pins using an external FTDI/CH340 USB-to-TTL adapter. This is the source of half of all ESP32-CAM pain.
GPIO 0 controls boot mode. For uploading, GPIO 0 must be held LOW at reset; for normal running it must be HIGH (floating is fine). Forgetting to remove the GPIO0-to-GND jumper after flashing is the classic "it uploaded fine but does nothing" bug.
PSRAM matters. The AI-Thinker board includes external PSRAM, which the camera driver uses as frame buffers. If your board variant lacks PSRAM (some clones do), high resolutions will fail — the fix is a lower resolution, not better code.

If you have not yet settled on the controller for your project, the ESP32 vs Arduino vs Raspberry Pi comparison explains where a camera-equipped microcontroller fits versus a full single-board computer.

Power: the brownout problem, first

Read this section before wiring anything. The ESP32-CAM's camera and WiFi together draw sharp current spikes — WiFi transmission bursts reach 160–260 mA, and the camera plus flash LED add more on top. The symptoms of an inadequate supply are distinctive and universal:

Brownout detector was triggered in the serial monitor, followed by a reset loop.
The camera initialises, then the board reboots the moment streaming starts.
Works when the flash LED is off, resets when it turns on.

The rules, in order of importance:

Power the board from 5V, not 3.3V, through the 5V pin — the onboard regulator needs the headroom, and the 3.3V output of a typical FTDI adapter cannot source the transmit bursts. A 5V supply rated for at least 1.5–2 A is the safe choice.
Do not power it from the FTDI adapter's 3.3V rail during normal operation. The adapter is fine for the logic-level serial signals; it is not a power supply. (During flashing, with WiFi off, the adapter's supply usually suffices — but if flashing is flaky, power the board separately and connect only GND, TX, RX.)
Add a chunky electrolytic capacitor (470–1000 µF) across the 5V and GND pins near the board. This is the single most effective brownout fix: the capacitor supplies the millisecond current spikes the regulator cannot track.
Keep power leads short and thick. A metre of thin jumper wire has enough resistance to drop hundreds of millivolts under burst current — the brownout detector notices.

The companion power supply guide covers adapters, regulators, and battery operation in depth; the brownout behaviour here is the camera-board-specific instance of those general rules.

Upload wiring: the FTDI ritual

You need a USB-to-TTL serial adapter (FTDI FT232, CH340, or CP2102 — any works) set to 3.3V logic level. The wiring:

ESP32-CAM pin	Adapter pin	Notes
5V	5V (or VCC)	Power the board from the adapter only for flashing; see power section
GND	GND	Common ground is non-negotiable
U0T (TX)	RX	Crossover: board TX goes to adapter RX
U0R (RX)	TX	Board RX goes to adapter TX
GPIO 0	GND	Only during flashing — jumper to ground, press reset, then upload

The flashing procedure, in order:

Connect everything above, with the GPIO0–GND jumper in place.
Plug in the adapter. Press the RST button on the ESP32-CAM (or cycle power) — with GPIO 0 held low, the chip boots into download mode.
In the Arduino IDE, select the port and click Upload.
After a successful upload, remove the GPIO0–GND jumper and press RST once. The board now boots your program.

The two classic mistakes: TX-to-TX instead of crossed (nothing uploads, no error that explains it), and leaving the GPIO0 jumper on after flashing (upload succeeded, board appears dead). If uploads fail, check these two before anything else.

Arduino IDE setup

Install the ESP32 board package: File > Preferences > Additional Boards Manager URLs, add https://dl.espressif.com/dl/package_esp32_index.json (or the current Espressif index URL), then Boards Manager > install "esp32".
Select Tools > Board > ESP32 Arduino > AI Thinker ESP32-CAM.
Set Tools > Partition Scheme > Huge APP (3MB No OTA/1MB SPIFFS) — the camera web server sketch is large, and the default partition leaves too little room for the app. "Upload failed: not enough space" almost always means the partition scheme, not your code.
Set the upload speed to 115200 if 921600 proves flaky on your adapter; slower is more reliable through cheap adapters and long jumpers.

The CameraWebServer example: first light

File > Examples > ESP32 > Camera > CameraWebServer. Before uploading, two edits:

const char* ssid = "YOUR_WIFI_SSID";
const char* password = "YOUR_WIFI_PASSWORD";

And in the camera configuration section, confirm CAMERA_MODEL_AI_THINKER is the selected model (it is the default in the current example). Upload with the GPIO0 ritual, remove the jumper, reset, and open the serial monitor at 115200 baud. The board prints its IP address once WiFi connects — open that IP in a browser and you get the camera control page: start/stop stream, and sliders for resolution, quality, brightness, and the face-detection toggle.

If the serial monitor shows WiFi connected and an IP but the browser cannot reach it, the usual causes are: phone/laptop on a different network (mobile hotspot vs router), or a router with client isolation enabled. Put the viewer on the same WiFi network as the board.

Resolution and frame rate: honest expectations

The OV2640 supports up to UXGA (1600×1200), but "supports" and "streams usefully" are different things on an ESP32:

Resolution	Size	Typical streaming behaviour	Use it for
QVGA	320×240	Smooth, ~15–30 fps achievable	Motion detection, low-bandwidth streaming
VGA	640×480	Usable, ~10–20 fps	General surveillance preview
SVGA	800×600	Slower, a few fps	Still captures where detail matters
UXGA	1600×1200	Very slow frame rate; large frames	Single still captures to SD card, not streaming

The constraint is WiFi throughput plus the ESP32's processing, not the sensor. A practical student setup streams at VGA or below and captures UXGA stills to the SD card on trigger — the wildlife camera trap pattern. If the stream stutters, drop the resolution before suspecting the code; and remember the power section — streaming at high resolution raises current draw, which is exactly when marginal supplies brown out.

Face detection: what the example actually does

The CameraWebServer example includes a face-detection toggle. It runs a lightweight detection model on the ESP32 itself and draws boxes around detected faces in the stream. Honest limits, because students routinely over-expect here:

It detects faces; it does not recognise them. Detection ("there is a face here") versus recognition ("this is person X") are different problems. The on-board example does detection only.
It is slow and fragile. Expect roughly 1–2 detections per second at low resolution, with false positives on face-like patterns and misses in poor light or at angles. It is a demo of the concept, not a security system.
Recognition needs a different architecture. A face-recognition door lock typically enrolls face templates and matches against them — heavier processing, tighter constraints on lighting and angle, and honest accuracy limits that belong in the report as measured results, not assumptions.

Use the built-in detection to learn the pipeline (capture → detect → act, e.g. light the LED or save a frame). If your project needs recognition, prototype the recognition on a PC first with the ESP32-CAM as a camera source, and only then decide what must run on the board.

SD card storage

The microSD slot gives the board standalone recording: capture stills or timelapse frames without WiFi. Practical notes:

Use a FAT32-formatted card, 4–32 GB from a reputable brand. Cards above 32 GB ship as exFAT and the ESP32 SD library will not mount them — reformat to FAT32.
The SD interface shares pins with the camera/flash circuitry; in the standard examples the card is initialised in 1-bit mode, which is slower but avoids pin conflicts. Do not "upgrade" it to 4-bit mode without checking the pinout — you will break the camera.
Filename discipline matters: name captures with timestamps (/img_20260923_143022.jpg) so a retrieved card is sortable. The board has no real-time clock — use NTP after WiFi connects, or a DS3231 module for offline timestamping.
Always close files and unmount cleanly in code paths that might lose power. A card corrupted by a brownout mid-write will teach you this once; the capacitor from the power section is the other half of the fix.

A minimal capture-to-SD pattern: initialise the camera at UXGA, capture a frame buffer, write it to the card, release the buffer, then drop back to a low streaming resolution or deep sleep. Holding a UXGA frame in RAM while doing anything else is how you meet the out-of-memory reset.

Sending images elsewhere: MQTT and HTTP

A camera that only serves its own web page is a starting point. Student projects usually need the image to go somewhere:

HTTP POST to a server: capture a JPEG frame buffer and POST it to your backend (a Flask/FastAPI endpoint, or a cloud function). Simple, debuggable, and the server can run the heavy ML (face recognition, object detection) that the ESP32 cannot.
MQTT: the ESP32-CAM publishes well over MQTT for signalling ("motion detected", "capture now"), and small JPEGs can go over MQTT too — but keep images on HTTP and use MQTT for control messages. The practical MQTT guide and the cloud connection guide cover the broker and protocol side.
Telegram bot snapshots: a popular student pattern — the board sends a photo to a Telegram chat on trigger via the Bot API over HTTPS. It needs TLS (memory-hungry on the ESP32-CAM; use it at low resolution) and a bot token kept out of shared code.

An ESP32-CAM surveillance robot combines several of these: the camera streams for driving, captures stills on command, and the control channel runs over WiFi/MQTT.

The error-message diagnosis table

Every ESP32-CAM builder meets these. In order of frequency:

Error / symptom	Meaning	Fix
`Brownout detector was triggered` + reset loop	Supply voltage sagging under WiFi/camera bursts	5V 2A supply, 470–1000 µF capacitor across 5V/GND, short thick leads
`Failed to connect to ESP32: Timed out waiting for packet header`	Chip not in download mode	GPIO0 jumper to GND before reset/power-cycle; check TX/RX crossover; try 115200 baud
`Camera init failed with error 0x20001` (or similar)	Camera not communicating	Reseat the ribbon cable (it loosens); check the cable orientation; confirm the AI-Thinker model selection
Upload succeeds, board does nothing	GPIO0 still jumpered to GND after flashing	Remove the jumper, press RST — the board was booting into download mode
`Guru Meditation Error` on stream start	Usually out-of-memory at high resolution	Lower the resolution; confirm PSRAM is detected in the boot log (`PSRAM found`)
`E (camera): PSRAM not found` / malloc failures	Board variant without PSRAM, or PSRAM disabled	Enable PSRAM in Tools menu if present; otherwise cap resolution at SVGA or below
Sketch too big / `not enough space` on upload	Default partition too small for the camera example	Partition Scheme > Huge APP (3MB No OTA/1MB SPIFFS)
Stream works, then freezes after minutes	Memory leak in long-running stream, or WiFi drop	Reboot periodically via software timer; add WiFi reconnect logic; keep firmware current
SD card not detected	exFAT card, bad format, or loose slot	Reformat to FAT32; try a known-good branded card; reseat

When nothing makes sense, simplify to the minimum reproducible case: the CameraWebServer example, QVGA resolution, board powered from a solid 5V supply, serial monitor open. If the minimum case works, reintroduce your changes one at a time. If the minimum case fails, the problem is power, wiring, or the board — not your code.

Deployment notes: enclosures and the field

Heat: the ESP32-CAM runs warm when streaming; in a sealed enclosure add ventilation. Thermal throttling shows up as mysteriously dropping frame rates after 20 minutes.
The flash LED (GPIO 4) is genuinely useful as an illuminator for night captures — the wildlife-trap pattern — but it is also the single biggest current spike on the board. Size the supply for LED-on-plus-WiFi, or trigger captures with the LED and stream without it.
Antenna: the board has a PCB antenna; keep it clear of metal enclosures. A metal box around an ESP32-CAM is a Faraday cage with a camera in it.
Watchdog: enable the software watchdog or a periodic ESP.restart() for long deployments. A camera node that needs a physical reset after every WiFi outage is not deployed, it is abandoned.

The first-build checklist

Board identified as AI-Thinker ESP32-CAM; ribbon cable seated and latched
5V supply rated ≥1.5 A; 470–1000 µF capacitor across 5V/GND at the board
FTDI adapter at 3.3V logic; TX/RX crossed; common ground
GPIO0→GND jumper procedure practised: jumper on → reset → upload → jumper off → reset
Arduino IDE: AI Thinker ESP32-CAM board, Huge APP partition scheme
CameraWebServer example runs; IP reachable from a device on the same WiFi
Resolution chosen for the use case (stream low, capture high to SD)
Face detection tried with honest expectations (detection, not recognition)
SD card FAT32, timestamped filenames, clean unmount in code
Brownout tested deliberately: stream + flash LED on, watch for resets before calling it done

Timelapse mode: the battery-friendly camera

Continuous streaming is power-hungry; timelapse is not. A timelapse node wakes, captures one frame to SD, and deep-sleeps — the same duty-cycle arithmetic as any battery ESP32 project, with the camera as the payload:

#include "esp_camera.h"
#include "esp_sleep.h"

void setup() {
  init_camera_at_UXGA();          // high-res still, not streaming
  capture_frame_to_sd();          // timestamped filename
  esp_sleep_enable_timer_wakeup(10 * 60 * 1000000ULL);  // every 10 min
  esp_deep_sleep_start();
}
void loop() {}

With a 10-minute interval, the awake window is a few seconds (camera init dominates — the OV2640 needs ~1–2 s to stabilise exposure, so do not try to shave this below what the sensor needs). The wildlife camera trap is this pattern with a PIR wake source added: EXT0 wake on the motion sensor instead of (or as well as) the timer, so the node sleeps through quiet nights and captures only when something moves. Size the battery with the deep-sleep math — camera captures are brief, WiFi stays off entirely, and a single 18650 runs this pattern for weeks.

Using the ESP32-CAM as a camera source for ML

The board's processor is too small for serious ML, but it is an excellent cheap camera feeding ML running elsewhere. The pattern: ESP32-CAM captures frames and POSTs them to a PC or cloud endpoint, which runs the detector or classifier and sends back a decision over MQTT.

This split plays to each side's strengths — the 2MP OV2640 is a perfectly good sensor, and a laptop GPU runs models the ESP32 cannot load. For a student project it also produces a cleaner report: the vision model trains and evaluates on a PC with proper tooling (the augmentation and training guides in this series apply directly), while the ESP32-CAM chapter covers the embedded capture-and-transport pipeline. Decide the split early: "detect on board" is a demo; "capture on board, infer on server" is a system.

Frequently asked questions

Can I power the ESP32-CAM from batteries?
Yes, with the same design rules as any ESP32 field device: a regulator arrangement that holds 5V under 500 mA+ bursts, a large capacitor at the board, and — realistically — no continuous WiFi streaming on batteries. Timelapse-to-SD or event-triggered capture with WiFi off between events is the battery-feasible pattern; continuous streaming wants mains power.

Why does my board work on USB power from my laptop but reset on a phone charger?
Many phone chargers are fine; many cheap ones sag under burst loads or negotiate current limits the board cannot use. The laptop USB port is actually current-limited too — the difference is usually cable quality and length. Short, thick cable first; then suspect the charger.

Can two ESP32-CAMs stream to one page?
Yes — each board serves its own CameraWebServer page at its own IP. A simple dashboard page with two <img> tags (or iframes) pointed at the two stream URLs gives you a split view. Keep both at QVGA/VGA or your router becomes the bottleneck before the boards do.

Is the ESP32-CAM suitable for a face-recognition attendance system?
As the camera and the network transport, yes; as the recogniser, only with honest limits. The on-board example detects faces but does not identify them. A credible attendance build captures frames on the ESP32-CAM and runs recognition on a server — see the face-recognition door lock project for how that split is structured.

Putting it together

The ESP32-CAM rewards one careful afternoon of setup — power, wiring, IDE configuration — with a camera node that then just works across surveillance robots, wildlife camera traps, and face-recognition door locks. The failure mode is always the same: skipping the power and wiring fundamentals and debugging everything downstream of them. Get 5V with a capacitor, the GPIO0 ritual, and the Huge APP partition right, and the board stops being frustrating and starts being the cheapest camera on your network.

ESP32-CAM Complete Setup Guide: Wiring, Camera Web Server, Face Detection and SD Card Storage