ESP32 Cam EZB Firmware
Transform ESP32-CAM into an EZ-B for Synthiam ARC: simultaneous video streaming and servo control in a compact, cost-effective solution.
Compatible Hardware
Description
This firmware converts a ESP32 Cam into an EZB for ARC to connect to it.
This firmware transforms an ESP32-based camera module into a full EZ-B-compatible controller with integrated Synthiam ARC video streaming. It enables the ESP32 to function simultaneously as a real-time camera and as a robotics/IoT peripheral controller - all in one compact board.
Summary
This firmware turns an ESP32 camera module into an ARC-compatible EZ-B controller with live video, digital I/O, ultrasonic measurement, and optional ADC support.
To deploy successfully you must:
- Select the correct CAMERA_MODEL_* define.
- Edit the mapping tables to match your ESP32 board’s GPIO.
- Flash the firmware and connect through Synthiam ARC.
Once mapped, the ESP32 behaves like a compact, Wi-Fi enabled, vision-equipped EZ-B controller ready for robotics and IoT applications.
Important note about PWM/actuators: If PWM output for actuators is required, use an external controller such as a PCA9685, SSC-32, or another dedicated PWM/servo driver. This is necessary due to the limited processing and I/O capability of ESP32 devices-especially camera-based modules. The camera subsystem consumes a significant amount of CPU time, DMA bandwidth, GPIOs, and LEDC timer resources, so PWM generation must be offloaded to a slave peripheral controller for reliable operation.
What the Firmware Provides
EZ-B Compatibility The ESP32 accepts ARC control commands and behaves like an EZ-B, allowing digital outputs, ultrasonic sensors, and other peripherals to be controlled directly from Synthiam ARC.
Integrated Camera Streaming The onboard OV2640 camera streams JPEG video to ARC, providing live visual feedback alongside peripheral control.
Simultaneous Operation Camera streaming and peripheral control run together, making the ESP32 ideal for robotics scenarios where vision and control must happen at the same time.
Supported ESP32 Camera Boards
This firmware includes camera model definitions for many common modules, including variants of classic AI-Thinker style boards, M5Stack units, and ESP32-S2/S3 models with cameras.
Supported models include:
- CAMERA_MODEL_AI_THINKER
- CAMERA_MODEL_WROVER_KIT
- CAMERA_MODEL_ESP_EYE
- CAMERA_MODEL_M5STACK_PSRAM
- CAMERA_MODEL_M5STACK_V2_PSRAM
- CAMERA_MODEL_M5STACK_WIDE
- CAMERA_MODEL_M5STACK_ESP32CAM
- CAMERA_MODEL_M5STACK_UNITCAM
- CAMERA_MODEL_M5STACK_CAMS3_UNIT
- CAMERA_MODEL_TTGO_T_JOURNAL
- CAMERA_MODEL_XIAO_ESP32S3
- CAMERA_MODEL_ESP32_CAM_BOARD
- CAMERA_MODEL_ESP32S3_CAM_LCD
- CAMERA_MODEL_ESP32S2_CAM_BOARD
- CAMERA_MODEL_ESP32S3_EYE
- CAMERA_MODEL_DFRobot_FireBeetle2_ESP32S3
- CAMERA_MODEL_DFRobot_Romeo_ESP32S3
Only one camera model should be enabled in the firmware at a time. A mismatched model typically results in "frame size = 0" or initialization errors.
Understanding GPIO Mapping (Very Important)
Different ESP32 camera boards have:
- different exposed header pins
- different analog capabilities
- different LEDC PWM support
- pins occupied by the camera bus (XCLK, PCLK, VSYNC, HREF, SDA/SCL, etc.)
- differences between ESP32, ESP32-S2, ESP32-S3 variants
Because of this, ARC’s digital and ADC port numbers do NOT directly match ESP32 pin numbers. To solve that, the firmware uses mapping tables that translate between:
ARC Dx -> ESP32 GPIO
ARC ADCx -> ESP32 ADC-capable GPIO
This mapping layer exists so that:
ARC always sees consistent "Dx" ports (0-23) regardless of hardware Camera-critical pins are never accidentally used for peripherals Different ESP32 board layouts remain compatible by changing only one mapping section PWM-capable pins are used only where supported Project code in ARC remains portable across ESP32 models
Editing the Mapping for Your ESP32 Module
You must customize the mapping arrays to reflect the physical pins on the ESP32 camera board you are using. This is the only hardware-specific part of the firmware.
This is how ARC ports and ESP32 parts are mapped. In the example below, ARC D0 is mapped to ESP32 port #2. Example of the concept for WRover with camera:
const uint8_t ARC_TO_ESP_DIGITAL_PIN_MAPPING[24] = {
2, // ARC port D0
13, // ARC port D1
14, // ARC port D2
15, // ARC port D3
12, // ARC port D4
0xff, // ARC port D5 (not used)
0xff, // ARC port D6 (not used)
0xff, // ARC port D7 (not used)
0xff, // ARC port D8 (not used)
0xff, // ARC port D9 (not used)
0xff, // ARC port D10 (not used)
0xff, // ARC port D11 (not used)
0xff, // ARC port D12 (not used)
0xff, // ARC port D13 (not used)
0xff, // ARC port D14 (not used)
0xff, // ARC port D15 (not used)
0xff, // ARC port D16 (not used)
0xff, // ARC port D17 (not used)
0xff, // ARC port D18 (not used)
0xff, // ARC port D19 (not used)
0xff, // ARC port D20 (not used)
0xff, // ARC port D21 (not used)
0xff, // ARC port D22 (not used)
0xff // ARC port D23 (not used)
};
const uint8_t ARC_TO_ESP_ADC_PIN_MAPPING[8] = {
0xff, // ARC port ADC0 (not mapped)
0xff, // ARC port ADC1 (not mapped)
0xff, // ARC port ADC2 (not mapped)
0xff, // ARC port ADC3 (not mapped)
0xff, // ARC port ADC4 (not mapped)
0xff, // ARC port ADC5 (not mapped)
0xff, // ARC port ADC6 (not mapped)
0xff // ARC port ADC7 (not mapped)
};
// ----------------------------------------------------------------
// Serial Expansion UART Configuration (in ARC this is UART #0)
// ----------------------------------------------------------------
#define SERIAL2_RX 12
#define SERIAL2_TX 13
Where:
0xFF= not available- Valid range = 0-23 for digital and 0-7 for ADC
This means ARC’s D0...D23 and ADC0...ADC7 stay consistent in software, even though the underlying ESP hardware changes.
How the Firmware Uses the Mapping
Once configured, ARC can:
Peripheral Control
- Toggle digital outputs
- Drive PWM-capable pins
- Read ultrasonic distance
- Poll analog inputs (if available)
Camera Streaming
- Send JPEG frames via TCP
- Auto-adjust compression based on frame size to prevent buffering issues
Resource Management
- Reserves LEDC timer channels so PWM output can’t break camera clock timing
- Manages Wi-Fi event handling for both AP and STA modes
Benefits of This System
Portable Projects ARC projects don’t need to change when switching ESP32 boards - only the mapping tables change.
Camera Safety Prevents peripherals from attaching to camera data lines and causing frame failures.
Better Hardware Compatibility Works with ESP32, ESP32-S2, and ESP32-S3 camera variants.
All-in-One Hardware Eliminates the need for a separate EZ-B and camera module.
Cost Effective Uses low-cost ESP32 hardware for high-level robotics and IoT tasks.
Typical Use Case
Perfect for robots or IoT devices needing combined vision + control, such as:
- FPV robotic rovers
- Mobile robots with live video feedback
- Remote inspection robots
- Home automation with visual monitoring
- Telepresence devices

what is flashed ESP?
Nink is saying that you flash the ESP32 Cam with the firmware that is posted on this page.
Read the instructions on the ESP 32 Cam hardware page: https://synthiam.com/Support/Hardware/ESP32-Cam
Here is my esp32 cam and FTDI adapter on ARC with a pictures of DJ's modified code for my network, using 192.168.1.17 (came from the Arduino code and serial monitor)
I open ARC and took the 192.168.1.17 and put it in the connect and the camera controls,
here is my results:
this esp32 cam is the easiest one, no wires to connect - just plug in :-)
https://www.amazon.com/Aideepen-ESP32-CAM-Bluetooth-ESP32-CAM-MB-Arduino/dp/B08P2578LV/ref=sr_1_6?dchild=1&keywords=ESP32+Cam&qid=1612713883&sr=8-6 thanks
EzAng
Your version of the esp32 cam doesn’t have as many artifacts and lines in the camera view as @ninks and mine.
mine is pretty distorted often but not as bad as nink’s is. I believe they keep the cost low by using camera components that don’t pass QA
the esp32 cam I posted above from Amazon works better and clearer then the one I used with the FTDI adapter and all the wires
check it out
Here is some info on it:
The HK-ESP32-CAM-MB module is a small camera module with a size of 39.8MM*27MM HK-ESP32-CAM-MB adopts Micro USB interface, convenient and reliable connection method, convenient to apply to various IoT hardware terminal occasions HK-ESP32-CAM-MB module can work independently as the smallest system
A new WiFi+Bluetooth dual-mode development board based on ESP32 design, using PCB on-board antenna, with 2 high-performance 32-bit LX6CPU, using 7-level pipeline architecture, main frequency adjustment range 80MHz to 240Mhz Ultra-low power consumption, deep sleep current is as low as 6mA. It is an ultra-small 802.11b/g/n Wi-Fi + BT/BLE SoC module
EzAng looks like he has somewhat more of a self contained solution with short neat wires and then there is mine (and I suspect yours looks about the same as mine DJ) so maybe I am getting a lot of electromagnetic interference. Reading the forums though it says Short wires. Only a single power supply, remove FTDI, make sure you are close to wifi and run at about 5.3v and lines should disappear. With that in mind, I tried it and No Lines (see new video).
https://youtube.com/shorts/IFF7pNFF4z0
EzAng
Mine :-)
Wow, that's alot of wires, lol
Even better Nick is "no wires"
like I said above:
this esp32 cam is the easiest one, no wires to connect - just plug in :-)
https://www.amazon.com/Aideepen-ESP32-CAM-Bluetooth-ESP32-CAM-MB-Arduino/dp/B08P2578LV/ref=sr_1_6?dchild=1&keywords=ESP32+Cam&qid=1612713883&sr=8-6
No Wires ? OK I guess you could build a Tesla coil but then we are back to the electromagnet interference problem.