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.

Jump to end

ARC Pro

Upgrade to ARC Pro

Don't limit your robot's potential – subscribe to ARC Pro and transform it into a dynamic, intelligent machine.

Author Avatar
PRO
Canada
#1   — Edited

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


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.

Author Avatar
#3  

Quote:

which is absolutely ridiculous, and the creators should be embarrassed that they made it
@DJ, tell us how you really feel.xD You are an absolute treasure.

We're fortunate you have you on our side. Thanks for all you do.;)

Author Avatar
PRO
Synthiam
#4  

Haha - yeah it’s really frustrating working with stuff like that. I’m sure they had an "idea" of why the did it that way at the time. But I’d hope the author realized by now it was the wrong way to do it haha.

The trouble is that you guys want to use these things. And if the don’t work or perform, it reflects poorly onto us.

Author Avatar
PRO
USA
#5  

Quote:

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
Yeah its a really old board. The original SSC-32 is like 20 years old. The SSC-32 U is 9 years old.

Author Avatar
PRO
Synthiam
#6   — Edited

Quote:

Yeah its a really old board. The original SSC-32 is like 20 years old. The SSC-32 U is 9 years old.

still an ascii text string protocol - nothing changed in the newer ssc-32u for protocol performance. i can explain further why it's so slow...

a byte is 8 bits that can represent a value between 0-255. For example, the letter A is a single byte with the value of 65. Capital B is 66. Capital C is 67. Lowercase A is 97, lowercase B is 98, etc...

a string is a list of bytes. So if you type the word HELLO, that's 5 bytes.

Computers don't know what the word HELLO means. They don't know what any string words mean. They know values of bytes.

A communication protocol should use bytes instead of strings. So a value of 0x00 could mean "stop servos". 0x01, 0x0A could mean "move servo 1 to position 10". That's 2 (two) bytes to send a command to move servo.

When you send a string, like their protocol, it's something long like FB23432Asdfjhqawtgh@#$%@3hjadgfhasdg or something who knows... so instead of sending 2 bytes, they send 10 or 15 bytes. PLUS they have to parse the string.

So 2 bytes is 2 bytes. 10 bytes is 5 times more bytes than 2 bytes. At a baudrate of 57600 or 115200, that's HUGE. 5 times slower. Next time you drive your car, drive 5 times slower the speed limit and see how long it gets you to go anywhere.

Author Avatar
PRO
USA
#7  

Yeah thats crazy. How in the heck do they expect you to run 32 servos with those kinda of restrictions/overhead..lol?

Thanks for that thorough explanation!

Author Avatar
PRO
Synthiam
#8  

Exactly - I mean, hardware-wise, it looks promising because it supports 32 servos. But so slow to talk to. It's better for current between the PCA9685, but it's worse for communication speed. It's a tough choice between the two, because both have their downsides. If I had to decide, I'd go with the PCA9685 and provide power to the servos separately

Login to post a comment