Canada
Asked — Edited

ESP32 Development; New And Final Directions

Skip to comments   Jump to end

Because I need a life too, I'm preparing a hard stop to finalize my ESP32 development after my last final changes. I only have time to work on it in my off-time and it's been consuming every spare moment for weeks.

V13 is what i just finished tonight... lucky 13. This is the first step toward the final ESP32 firmware I'm working on, which you can extend with robot skills.

ESP32 Cam EZB
ESP32 Cam EZB firmware
for ESP32 Cam by Espressif
ESP32 Cam
Transform ESP32-CAM into an EZ-B for Synthiam ARC: simultaneous video streaming and servo control in a compact, cost-effective solution.
Firmware Versions 13
Last Updated
Current Version v13
Hardware ESP32 Cam

Check out the release notes because that's the direction I'm heading. I'm removing all support for pwm/servos on the ESP32 GPIO. All ESP32s will require an additional servo controller, such as a PCA9685, SCC32, or a simple Arduino. The ESP32 does not have enough resources to handle the servo and all the other jazz.

  • The core synchronization is out to lunch.
  • The task management is at the mercy of hardware peripheral activities.
  • The DMA or whatever happens internally doesn't share resources and blocks tasks.
  • It's just not a great microcontroller for multitasking.

I think what makes the ESP32 great is its affordability. And because it's low-cost, you can buy 3 of them. And you essentially need 3 or maybe 4 to emulate an ezbv4 properly. It's like comparing a phone CPU to a desktop pc CPU. They're just different tools for different jobs. And the ESP32 is just not made for what we're trying to do. It's made for doing a single task, even though you can argue there are multiple cores, there is a reason...

  • TASK #0 for WiFi/TCP/Network services
  • TASK #1 for your program
  • That's it. That's all you get

So, trying to split all these tasks and services into a micro that is low power and low cost for a reason requires either

  1. more esp32's chained together
  2. a different micro that costs more and has more power
  3. fewer features

So the plan moving forward is...

  • Remove all servo/pwm from both ESP32 and ESP32Cam firmwares. For servo/pwm, use an external servo controller such as PCA9685, SCC32, or an Arduino, etc.
  • dumbing-down the firmware based on what i wrote tonight. It's fully optimized, and I can't squeeze anything more out of it.
  • i'm going to try adding audio to both ESP32Cam and ESP32 and see if i can make that work. It "sort of works" with the ESP32Plus, but it hasn't been fully tested yet.
  • If I can make audio work on ESP32 and ESP32Cam firmware, I'll remove ESP32Plus, and we'll just focus on those two

*Remember: ESP32Cam and ESP32 are completely different microcontroller boards. The chips may be similar, but one with a camera and one without means a whole world of difference. And that is why there are multiple firmwares.

@Athena explain in more detail so there's no questions.

Jump to end

ARC Pro

Upgrade to ARC Pro

Subscribe to ARC Pro, and your robot will become a canvas for your imagination, limited only by your creativity.

Author Avatar
PRO
Canada
#1  

Thanks - here’s a clear, action-oriented summary of DJ_Sures’ announcement, what it means for your ARC project (SSC-32 and ArduinoComs), and exact next steps so there’s no confusion.

What DJ_Sures changed and why

  • ESP32 and ESP32-CAM firmwares will no longer support generating PWM/servo pulses on the ESP32's GPIO pins.
  • Reason: the ESP32 firmware cannot reliably multitask WiFi/TCP + camera + realtime servo PWM generation. The hardware/peripheral scheduling and DMA on the ESP32 cause timing/resource problems for servo control.
  • Result: ESP32 boards will be usable for lighter duties (network, camera, possibly audio), but any servo outputs must be handled by an external dedicated servo controller (PCA9685, SSC-32, an Arduino acting as a servo bridge, etc.).
  • Additional firmware notes: ESP32Plus may be retired; work will focus on ESP32 and ESP32-CAM firmwares. Audio support is being explored for those firmwares.

How this affects your ARC project (SSC-32 & ArduinoComs)

  • If you were using your ESP32 to drive servos directly via its GPIO, you must add a dedicated servo controller to your robot.
  • Good candidates: PCA9685 (I2C PWM driver), Lynxmotion SSC-32, or an Arduino (running firmware to accept serial commands). The SSC-32 skill you already use is an ideal replacement because ARC already supports it.
  • If you already use the SSC-32 skill (virtual servos V0..V31), minimal ARC-side changes are needed - just move the servos physically to the SSC-32 and configure the skill (COM or UART).
  • ArduinoComs: if you use this for custom I/O or as a serial bridge, it can still be used. An Arduino may also be used to handle servo outputs and communicate with ARC.

Practical migration steps (step-by-step)

  1. Decide which external servo controller to use

    • SSC-32: works with ARC via the SSC-32 servo Controller skill. Good for many PWM servos via serial.
    • PCA9685: I2C PWM board (good for many servos, often used with ESP32/I2C).
    • Arduino: you can run firmwares that accept serial commands and output servo PWM. Choose based on how many servos you have, wiring convenience, and whether you need UART or I2C.

  2. Hardware wiring

    • Connect servos to the selected controller channels.
    • Provide a dedicated servo power supply sized for your servos (USB is usually insufficient).
    • IMPORTANT: connect a common ground between the controller (SSC-32 / Arduino / PCA9685 power ground) and the ESP32/computer/EZB where applicable.

  3. Add & configure the SSC-32 (or other) skill in ARC

    • Project -> Add robot skill -> search for SSC-32 servo Controller (or relevant skill).
    • Open the skill window, click the kebab (three-line/hamburger) menu -> Settings/Configuration.
    • Set Connection Type:
      • Direct COM Port if SSC-32 is connected to the PC via USB-to-Serial. Select the COM port and baud rate (must match SSC-32 hardware).
      • UART if connected through an EZB/Arduino (select the correct UART/ezb).
    • Verify virtual ports V0..V31 are created and map to your SSC-32 channels.

  4. Update ARC controls / scripts

    • Replace any code or controls that were using ESP32 GPIO servo ports (d#) with the SSC-32 virtual ports v#.
    • In scripts, use servo constants without quotes (e.g., Servo.setPosition(v0, 90)).
    • If you used custom serial commands to the ESP32 for servo positions, switch those commands to the new controller or use ARC’s Servo.* commands with v#.
    • If you need an example, I can convert your current scripts - paste them and I’ll convert.

  5. Test carefully

    • Move one servo at a time in ARC using the servo control to confirm mapping and power.
    • Watch for jitter (power supply issues) and wrong channel mappings (ensure correct Vx physical channel mapping).

Important ARC notes & reminders

Examples (script snippets)

  • Move SSC-32 servo v0 to 90 degrees (JavaScript example in ARC):
Servo.setPosition(v0, 90);
  • Set SSC-32 servo v0 speed:
Servo.setSpeed(v0, 5);

(Use these in your project scripts or as Startup Initialization.)

Questions I need to help you migrate

  • Are you currently driving servos directly from an ESP32 GPIO? If so, how many servos and which pins?
  • Are you planning to add SSC-32, PCA9685, or an Arduino as your external servo controller?
  • Are your servos currently powered from the ESP32 supply or an external supply?
  • Do you want me to convert any existing ARC scripts or actions to use virtual ports (post a sample script or list of servo uses)?

If you want I can:

  • Provide the exact step-by-step for your chosen controller (PCA9685 / SSC-32 / Arduino).
  • Convert your current servo-related scripts to the new v# calls.
  • Walk through the SSC-32 skill configuration (which settings to check in the kebab menu).

Would you like to proceed with a recommended controller (I usually suggest PCA9685 for I2C ease or SSC-32 for serial compatibility with your project) and give me current servo count and wiring? I’ll give you a migration checklist tailored to your setup.


I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.
Author Avatar
PRO
Synthiam
#2  

Also note that I do not recommend SCC-32 because it's SUPER slow and the protocol is text-based - which is absolutely ridiculous, and the creators should be embarrassed that they made it:P

I recommend PCA9685.. i'm going to make a robot skill for it and it'll work on i2c across all ezb devices.

Login to post a comment