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

wow that was a lot of wires, lol, unnecessary
Just got it today, I was amazed also - just plug it into your laptop or computer - works good
Hi Nink,
the picture you took of me is when I used the FTDI adapter on the Esp32 cam with the ARC program - just a few wires, lol... I learned that from a great Arduino teacher from Canada named Bill
Here is a short (funny) video of the "new" ESP32 cam with "NO" wires, lol - It has a built-in adapter to upload DJ's Arduino file, makes it easy, lol
In ARC, connect first when you get the IP from the serial monitor , add the camera last
EzAng
Now I just need to work out how to get GPIO working with ARC and servos / sensors. So far I managed to get one servo to vibrate on GPIO0 but that is as good as it gets.
Hi Nink,
DJ has a video of how to use a servo with the esp32's GPIOs
Step 1: First download version 3 DJ's ESP32 DOIT DevKit v1 - Firmware - Synthiam https://synthiam.com/Firmware/DJ-s-ESP32-DOIT-DevKit-v1-YGHLAL0K4JE
then get the IP to connect to ARC from the serial monitor
Step 2: read Esp32 Devkit V1 - Compatible EZB Robot Hardware - Support - Synthiam Watch this video
Near the end of this video, DJ show how to add a servo - : no vibrating servo here: https://youtu.be/CbMffZfq5cc
for a test, I first used the Led, then the servo, I used a micro servo (a little off, but), works well
remember the GPIO pins on the esp32 are the D pins in ARC servo controls
Auto-position works great
EzAng
Hi @EzAng Yes ESP32 works fine. What doesn’t work is the ESP32-CAM with servos. Finding a free GPIO and making work is the problem.
All I see on this site is:
The pins in ARC are labeled D0 - D23. The ESP32 has GPIO labeled pins, which are not in any ordered sequence. This translation chart below shows the mapping of the ESP GPIO to ARC Dx pins.
I noticed the DATA2 is a D3 and DATA3 is D4
either the cam works or the servo but not together, you are right, seems like a question for DJ
EzAng
It’s most likely due to the timer or resources that are shared between the servo and camera. Must be a conflict of some sort between those two libraries.
Agree
I just used an IoTiny on connection 1 for a servo
esp32 cam on connection 0
that works
esp32 cam can't do it alone
I guess Nink will have to go this rout for now
Thanks
EzAng