Alternative to ezrobot ezb for robot head project

Question

My course has primarily focused on robotics projects using the EZ-B controller and a camera for real-time interfacing. With recent developments, I am planning to create an additional video that incorporates Synthiam's support for other types of controllers. Although I've successfully flashed an alternative controller, it lacked compatibility with camera integration and Wi-Fi capabilities. The absence of an onboard computer limits the use of a USB camera, posing a significant challenge.

This dependency on specific components like the EZ-B, IO Tiny, and cameras can be problematic. For my course project, Mecha Morphix, which involves controlling five servos, the Arduino Mega seems excessive. I am in search of a suitable controller, compatible with Synthiam ARC, that includes both Wi-Fi and camera support to effectively replace the EZ-B.

I noticed that the ESP32 with a camera is listed among the supported controllers for ARC. Has anyone experimented with using the ESP32 in conjunction with a camera for such applications? Any insights or experiences would be appreciated.

Synthiam Support · Answer

Esp32 camera will work. And 5 servos is perfect because they don’t have many free I/o ports.  I’ll have to check when I’m home later to see how many servos can be used with the camera at same time. The camera uses several I/o and time resources - which didn’t leave much I/o available for servos. But my gut says 5 servos shouldn’t be a problem.  you won’t get audio from it though. The only controllers that I know of with audio and video is from ezrobot.  but, if purchasing ezrobot products from resellers, I don’t think you will experience delays. Resellers have inventory so you’ll get them right away.

fxrtst · Answer

@synthiam support,  Yeah let me know what you find out. I'll need a back up for those around the world (100's or 1000's of students) who might take the course and have to wait to receive their EZB/Camera combo. Not sure if this would be a drain on the EZ Robots manufacturing or all the ongoing issues with trade wars etc. All my audio is a separate device and won't be affected if its not supported. But the overhead of the camera might be a problem.  I think i have a expansion board for the esp-32 for more pin outs. Has anyone tried the raspberry pi and pi camera with ARC, is it supported? Edit #1 ...Ahh i see the camera is a camera riding a ESP32...i thought it was an add on to full sized esp 32...hmmm. Edit # 2 PS if this is starting to get outside the original thread feel free to move this. This seems to be a much more expandable 16 MB version. Very close in specs to the EZB.

Jeremie · Answer

If memory serves me correctly, the ESP32-Cam only served 1 frame per second over WiFi. I think that was with it's factory firmware, I'm not sure if the EZB firmware for it changes that. Will, I would recommend getting in contact with Dennis the CEO of EZ-Robot and see if you can establish a deal with him. If you are looking at higher volumes of product I'm sure he'd be open to discussing things with you directly. Maybe you can become a reseller in order to secure stock for your students, and make a percentage off each sale.

fxrtst · Answer

@jeremie, Hahahah 1 fps might be a bit slow. I’ll do some tests later if supply becomes an issue.  We just don’t have the overhead atm to carry stock of EZB and Cameras. Each student will be purchasing their parts based on the supplied BOM. There are no "Kits" for this early bird option.

DJ Sures · Answer

The esp32cam does 20-30fps but it lacks audio. I’ll check out if it can do 5 servos in a bit. iotiny is the way to go if you could find stock with resellers. I also think demand would prioritize where ezrobot stock is allocated. But in the meantime, I’ll check out the servo capability with esp32cam while camera is running. Might even be documented on its hardware page. @athena could tell me too haha forgot about that. *edit: yeah, 5 servos while camera runs: https://synthiam.com/Support/Hardware/ESP32-Cam

fxrtst · Answer

Well options are the best way to go with people who have different budgets. I tried to give multiple options on various parts throughout the build. The EZB is overkill for this platform but gives builders the ability to expand. The IO Tiny is a cheaper option to the EZB, but the pricing for the camera is soooo overpriced ($85), totaling $135 for cam and the Tiny. The ESP32 Cam comes in at about $9 (Amazon) $1 (AliExpress)for both cam and controller (I don't need Audio). Hard to compete if it works with 5 servos and can do a frame rate of 20 to 30 fps. I'll order an couple and do some tests.

Synthiam Support · Answer

We moved related comments to this new thread so it gets proper attention.

fxrtst · Answer

I need an extension on the camera so I ordered these cams. The cameras come out to $6 each with the above ESP32 at $21 for a total of $27 compared to the $135 for IO tiny and camera or the EZB and camera $185 :

fxrtst · Answer

Here is the ESP 32 expansion board i got for my robot arm.

Nink · Answer

I used the ESP32 CAM in the palm of my robot hands. https://synthiam.com/Community/Questions/MJPEG-Stream-in-Camera-20263?commentPage=2#comments-list I managed to get 5 GPIO ports working with DJ help but I remember it was painful See the firmware conversation here. https://synthiam.com/Firmware/ESP32-Cam-EZB-5KUNP4UTSW0?commentPage=5

DJ Sures · Answer

Yeah, that's right, @Nink! I remember now. Will, you can thank Nink for laying the groundwork. I do remember it being quite a challenging ordeal to figure out what pins to use. That was also in the early days of esp32 and there wasn't much documentation.

fxrtst · Answer

2021! You guys were ahead of the curve (again). They have come a long way (ESP 32s) and so many boards/manufactures and support! But def need to do homework with different boards..as with everything they're some trash boards out there. The formfactor and the power make it a great cheap EZB. Even a non camera version would work with a webcam option for camera.

fxrtst · Answer

I got a few goodies in the mail today. Very curious to compare. Also the OV3660 cameras are supposed to be far more superior to the old cameras. Total cost for items in the image were less than $30.

DJ Sures · Answer

oh nice deal. i'm interested to see how that's going to work out. might need to check a datasheet or use openai or athena to verify the ezb firmware ports against their design. other than that, it should just work

fxrtst · Answer

Ok some initial tests today. Asking too much from the ESP32 CAM. Its so overwhelmed with the camera data via wi-fi, I get less than one frame a sec on the iphone tests, but def could be used as just a controller. BUT, the Freenove ESP32-S3 Wrover shown above (red board), is extremely powerful and gives me 25 to 30 frames (via wifi) a sec at 320x240 plenty for motion detection/object detect. I found a breakout board that is a bit larger than the housed EZB specifically for this board. As DJ pointed out since it is all the ESP stuff is opensource, I found different boards with different pin spacings so they are not all plug and play. The Freenove ESP32 Wrover is a 40 pin board and the expansion board below is designed to work with it...its a bit big, 3.39 by 3.1 inches (cost $12.00) . I'm sure there smaller versions. So if I can get it all to work, it would be Expansion Board $12, cam $6, ESP32 $15 = $33  I'll take a look at the pin out mapping tomorrow. Freenove Breakout Board for ESP32 / ESP32-S3 WROVER WROOM

DJ Sures · Answer

you're testing with the ezb firmware? if not, you're not going to get the high framerate. hippy opensource code won't be as effecient as the ezb firmware.

fxrtst · Answer

hahahha hippie code...yes this was me simply logging into the board with my iphone and turning on the camera..will try tomorrow with firmware!

Nink · Answer

I played with dozens of these things in hopes to build a cheap robot controller.  The iotiny seems to work best but yeah it’s kind of expensive and hard to find. if you end up putting together a cheap controller with camera I would love to see the solution.   I was trying to just build a cheap opensource robot connected to synthiam for kids at school. Idea was connect to AI and use camera, microphone, servos and led display based on Otto bot. but never found a cheap solution.  If you solve this would love to hear it. As you can see I tried a few esp and adapter boards as well Otto bot  https://www.ottodiy.com/

fxrtst · Answer

...I'll add that the the company Freenove has excellent documentation and they have amazing customer support and will respond in 24 hours to questions. And they have alot of cool kits. https://freenove.com/

fxrtst · Answer

@nink, The IOTINY is priced okay at $50 but the camera is listed at $90 in plastic housing not including shipping. Some of my beta testers listed part availability and pricing as one of the top reasons for not pursing robotics as a hobbyist in my questionnaire to them. I've tried to give various options in the Mecha Morphics course for various budgets. Example - I completely removed the Dynamixels which were the most expensive thing in ALAN. ($1500), choices for ujoints and so forth. I feel its important to pursue all options for controllers and hardware as long as ARC is supported.

DJ Sures · Answer

You can use the esp32cam as an ezrobot camera. That will connect to the iotiny. check this: https://synthiam.com/Firmware/ESP32-Cam-UART-HLT3KZKGG3F @Nink, will an esp32 cam not work for your needs? It has 5 servo or i/o ports

Nink · Answer

Yeah it probably could run 4 servos to walk, the cam to see, an ultrasonic sensor for distance with a Bluetooth speaker and microphone tied back to the host PC. the ESP32 cam is pretty underpowered so you need to be careful with your code. Don’t try moving servos or reading sensors when using the camera etc.  I could probably go back and look at this again but I stopped volunteering with the young kids a few years ago.  These days I volunteer with First Robotics, these are high school kids building complex robots to compete in competitions.  You would actually enjoy this @DJ as they combine robotics and AI and compete at local universities in an arena. They have a global completion every year in the US.  https://firstroboticscanada.org/frc/ @Will when you do get the right components AliExpress is a great place to get cheap components in bulk. Not sure if same in US as I live in Canada so we don’t have the expensive import costs and tariffs on China electronics.

fxrtst · Answer

..I love Aliexpress I've ordered alot of stuff in the past, but that was before the insane tariffs. Might be a wash these days.

fxrtst · Answer

Testing firmware. I started with the Doit ESP 32. All works fine except its very slow sending data to the servo. See Video. Tried 3 servos same result. If you look you can see me stop moving the mouse and the blue receive light stays on as a lag or delay. Any ideas? Latest arc, latest plug, advanced servo settings on default...

Dave Schulpius · Answer

I'm not sure how your setup works. However is it possible that you need a faster baud rate set some where?  @Athena , Is it possible to set the serial baud rate for the Doit ESP 32 that fxrtst is using to a faster setting to allow a servo motor to respond to movement commands faster?

fxrtst · Answer

...it looks like its 115200...

Athena · Answer

Good thread - lots of useful context. Here’s a focused troubleshooting checklist and recommendations to reduce the servo lag you’re seeing with the DoIt ESP32 (ESP32-CAM style) + camera streaming. Quick summary of likely causes - UART bandwidth / baud rate too low for the command rate. - Using the wrong UART (software/virtual vs hardware) or wrong pins. - CPU starvation/jitter from the camera streaming (camera + WiFi is CPU/network heavy). - Host-side sending commands continuously (no batching/caching). - Power/grounding issues for servos (voltage droop causes slow responses). - No hardware flow control and/or serial buffer buildup. What to try now (ordered, minimal changes first) 1) Verify and raise the serial baud (both ends) - If the ESP32 sketch uses Serial.begin(115200) and ARC/Serial Toolbox is set to 115200, try a higher baud like 921600 or 2,000,000 (ESP32 UARTs support multi-Mbps). - Change both sides to match. Example (Arduino/ESP32): cpp void setup() { Serial.begin(115200); // logs to USB // Use a hardware UART for ARC/servo bridge: // Serial1 uses (TX1, RX1) pins you choose on ESP32 Serial1.begin(921600, SERIAL_8N1, RX_PIN, TX_PIN); }  - Replace RX_PIN/TX_PIN with the pins you use. If you’re using the ESP32-CAM board, be careful which pins are free (camera pins may conflict). 2) Use a hardware UART (not bit-banged) - Ensure you are using one of the ESP32’s UARTs (Serial1 or Serial2) mapped to real GPIO pins, not a software implementation. Hardware UART is much more reliable at high throughput. 3) Reduce camera load while testing - Lower camera resolution and fps temporarily to see if camera streaming is starving the MCU or WiFi: - Lower frame size (VGA or lower) and reduce FPS. - If the lag improves, camera streaming is interfering-either reduce streaming load or move servo control to a dedicated MCU. 4) Batch/cached servo updates instead of continuous flooding - Don’t send a servo command every mouse pixel. Buffer servo positions and send them at a limited rate (e.g., 20-30 Hz) or only when position delta > threshold. - If you’re using the Single Camera Servo Server or a custom client, use the "cache and send" approach (SetCachedServoPosition + SendCachedServoPositions pattern) so ARC or the client sends bulk updates fewer times per second. 5) Power & wiring - Ensure servos have a proper 5V supply able to source peak current. If battery/USB only, the servo signals may lag under load. - Common ground between ESP32 and servo power supply is required. - Add decoupling caps near servo power rails. 6) Consider hardware flow control or a faster USB/bridge MCU - The Teensy-based bridge used in the Serial Toolbox example used RTS/CTS and very high bitrate with good results. If you need low-latency high-rate servo control while also using a USB camera, a Teensy or other fast MCU as a UART bridge can help. - Serial Toolbox docs / example: https://synthiam.com/Support/Skills/Misc/Serial-Toolbox?id=15887 7) If you continue with ESP32-CAM: accept limitations and/or split responsibilities - ESP32-CAM is cheap and supported by Synthiam firmware (see ESP32-Cam EZB firmware): https://synthiam.com/Support/Hardware/ESP32-Cam - It’s fine for a small head (up to ~5 servos) but avoid heavy simultaneous tasks. If you need camera + many servos + complex sensor processing, use a separate MCU for servos or a more capable board (ESP32-S3, Teensy, or a USB-capable board). Useful links - ESP32-CAM firmware info: https://synthiam.com/Support/Hardware/ESP32-Cam - Serial Toolbox skill (Teensy serial bridge info): https://synthiam.com/Support/Skills/Misc/Serial-Toolbox?id=15887 - Single Camera Servo Server: https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 - ARC / robot skill tutorial if you want a custom skill: https://synthiam.com/Support/Create-Robot-Skill/Overview How to change robot skill / plugin settings (kebab menu) 1. Project Add Robot Skill choose the skill (Serial Toolbox / Single Camera Servo Server). 2. Open the robot skill window. 3. Click the three-line kebab menu (top-right of the skill window) Settings. 4. Adjust baud, serial port, frame-rate, buffering, etc., and Save. Follow-up questions so I can give precise steps or a sample sketch - Which exact firmware/sketch did you flash to the DoIt ESP32? (If it’s a Synthiam build, which version?) - Are you using ARC to connect to the ESP32 over WiFi (EZB protocol) or are you using the Serial Toolbox (USB serial bridge) approach? - Are servos driven directly by the ESP32 GPIO PWM, or are you forwarding commands to a separate servo controller? - How are the servos powered (5V USB? battery? regulated supply and capacity)? - Can you paste the exact serial settings in the plugin and the Serial.begin lines from your sketch? (I can’t view images - paste text here.) If you want, I can: - Provide a minimal ESP32 sketch that reads simple binary/batched servo packets and updates servos from a timer (low jitter). - Suggest concrete baud values and Serial1 pin choices for your exact ESP32 module. - Help tune Single Camera Servo Server or Serial Toolbox settings for lower latency. Which of the above would you like me to prepare next?

fxrtst · Answer

@Athena This is not the ESP32 CAM version but rather the Esp32 Devkit V1 by Espressif and using it in Ad Hoc not UART  https://synthiam.com/Support/Hardware/Esp32-DevKit-v1

fxrtst · Answer

I've increased the baud rate nothing has changed. Moves same speed. Its about a nine second delay.

Athena · Answer

Thanks - that clarifies a lot. Because you are using an ESP32 DevKit v1 in AdHoc (AP) WiFi mode (not USB/UART), the 9second lag is almost certainly network/firmware/CPU scheduling related rather than a pure serial baud issue. Below is a focused checklist and stepbystep tests to isolate the problem and fixes you can try. I’ll also include small code snippets you can flash to the ESP32 to help diagnose and tune. Quick checklist (most likely causes) - WiFi AP mode or PC WiFi adapter behavior causing high latency or packet buffering. - ESP32 firmware doing camera streaming + servo updates on the same loop, starving servo updates. - WiFi power save enabled on the ESP32 or PC adapter, causing long micro bursts or aggregated packets. - ARC/skill update interval or batching is set too slow (plugin throttling). - Camera encode/upload saturating CPU or WiFi bandwidth. - Power wiring for servos (if servos power is drooping, behavior can appear like a delay). Immediate isolation tests (do these first) 1) Ping test (measure raw network latency) - On the PC connect to the ESP32 AP and open a Command Prompt: ping  -n 20 - Look at response times and packet loss. Typical good latencies should be single/double-digit ms. If pings show many seconds or timeouts, network is the culprit. 2) Disable camera streaming in ARC temporarily - Stop the Single Camera / camera feed in ARC and test servo commands. - If lag disappears or drops dramatically, the camera stream is interfering (CPU/network/bandwidth). 3) Disable other robot skills / traffic - Remove or pause Serial Toolbox / other skills so only the ESP32 device is connected. Test again. 4) Test a simple HTTP/UDP servo set (bypass ARC flow) - Make the ESP32 listen for a simple UDP packet or HTTP get that immediately updates a servo. From the PC, use a small script / browser / curl call to trigger the servo and watch responsiveness. - This proves whether the ESP32 can respond quickly independent of ARC. ARC / robot skill checks - Open the robot skill window that controls the ESP32 (Project Add Robot Skill or open the existing skill). - Click the kebab (three-line) menu Settings. - Check for any "Update Interval", "Send Interval", "Frame Rate" or buffering options. Reduce to something like 20-50 ms for servo updates while testing. - If the skill has a camera encoding/frame-size option, reduce frame size/FPS (e.g., VGA or QVGA and 10-15 FPS) to test. WiFi power save and AP vs Station mode - AP (AdHoc) mode can be slower / behave differently depending on the PC WiFi adapter. Try switching the ESP32 to Station mode (connect the ESP32 to your router and put your PC on same LAN). Station mode often reduces latency. - Disable WiFi power save on the ESP32 (this avoids the ESP sleeping/aggregating TX which can add latency). ESP32 code to disable WiFi power save (Arduino core) cpp #include  #include "esp_wifi.h" void setup() { Serial.begin(115200); WiFi.mode(WIFI_AP); // or WIFI_STA (recommended: use WIFI_STA connected to your router) WiFi.softAP("ESP32-AP"); // Disable Wi-Fi power save esp_wifi_set_ps(WIFI_PS_NONE); // setup servo outputs, tasks, etc. } void loop() { // lightweight: handle a UDP or HTTP socket and update servos in a high-priority task }  If you use Station (WIFI_STA) mode, connect the ESP32 to your local router and test from PC on same LAN. CPU & firmware architecture - If the same task is encoding frames and controlling servos, create separate tasks: one highpriority task that reads incoming network commands and writes servos, and another (lowerpriority) task for camera capture and upload. - Keep servo updates very lightweight: parse packet, write PWM/ledc, return. Batching and throttling - Don’t flood the ESP32 with every tiny mouse movement update. Batch to a fixed update rate (20-30Hz) or only send when delta > threshold. - If you’re using Single Camera Servo Server or a client, use the "cache and send" pattern (SetCachedServoPosition + SendCachedServoPositions) so you send grouped updates instead of hundreds/sec. Power & wiring - Confirm servo power supply is adequate and share common ground with the ESP32. - If powered from USB only, servo voltage/current sag could cause slow behavior. Use a proper 5V regulated supply with enough current headroom for your servos. If you want a quick test firmware to confirm lowlatency control: - I can prepare a minimal ESP32 sketch that: - Runs in STA mode (or AP, your choice) - Disables WiFi power save - Opens a UDP port and immediately applies servo commands on receipt - Uses a dedicated task for servo writes and a low-latency ledcWrite Would you like that? If yes, tell me: - Do you prefer AP mode or STA (router) mode for testing? - Which GPIO pins are your servos connected to? (ESP32 devkit GPIO numbers) - How many servos and how are they powered? Follow-up diagnostic info I need from you - Which ESP32 firmware did you flash (Synthiam ESP32 DevKit v1 firmware link if used)? Version? https://synthiam.com/Support/Hardware/Esp32-DevKit-v1 - Are the servos physically connected to the ESP32 DevKit v1 (direct PWM) or controlled via another servo controller? - Are you controlling servos using Single Camera Servo Server or some other robot skill? Which skill sends the servo commands? - Is the camera still on while testing? (Try turning it off temporarily.) - What IP (AP default 192.168.4.1?) are you connecting to - can you run ping and paste results? - How are the servos powered (USB 5V, separate battery, regulator)? Please include voltage and battery type. Recommendations if you need a more robust solution - If you need camera + reliable low-latency servo control and ESP32 is struggling, split functions: - Use the ESP32-CAM or DevKit dedicated to camera/streaming. - Use a small dedicated microcontroller (Teensy, Pro Micro, or another ESP32) to handle servos and accept compact UDP packets - communicate between them or to ARC. - Or use a single-board computer (Raspberry Pi/Jetson) for camera + local servo control (preferred when you need heavy vision + many servos). Next step offer Tell me: 1) The firmware version you flashed (link or text) and whether ARC connects over "EZB (WiFi)" skill or a custom skill. 2) Whether you want the minimal UDP test sketch I described (and AP or STA mode). I’ll prepare the sketch and the exact ARC test steps (Net.hTTPGet/POST or UDP test client) to measure true latency and fix the 9second delay.

Dave Schulpius · Answer

Quote:Its about a nine second delay.Yikes, that's insane. Not usable.  I wish I had a set of this hard ware so I could test along with you. At least we could compare results. I'll look into getting something if you cant resolve.  Do you think this is a result of the camera dragging the board down? Sorry, I lost track if you even have the camera on this board.

Athena · Answer

Thanks - useful info. Since you’re on an ESP32 DevKit v1 over WiFi (Ad-Hoc/AP) and you’re seeing ~9 seconds of lag, that strongly points to network/firmware buffering or WiFi power-save/aggregation issues rather than baud rates (which only matter for UART). Below is a targeted plan: quick checks, a minimal low-latency UDP test sketch you can flash to the ESP32, a small PC test client (Python) to measure true latency, and next steps depending on results. Quick checklist (do these first) - Confirm whether the camera is ON while you test. Turn it off temporarily - if lag disappears, camera streaming is the issue. - From the PC connected to the ESP32 AP, run: ping  (default AP IP 192.168.4.1). Good latencies should be single-digit to low double-digit ms. If ping shows seconds or packet loss, the WiFi/AP path is the problem. - Put ARC camera/servo skill settings on the kebab menu (three-lines) and temporarily reduce camera FPS and frame size, and lower any "send interval" or "update interval" for servo updates (target 20-50 ms while testing). Links: - ESP32 DevKit guide: https://synthiam.com/Support/Hardware/Esp32-DevKit-v1 - Single Camera Servo Server: https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 - Serial Toolbox: https://synthiam.com/Support/Skills/Misc/Serial-Toolbox?id=15887 Important things to check/configure - WiFi mode: AP is convenient for direct connection but some PC WiFi adapters behave badly with AP mode. If possible use Station (WIFI_STA) mode connecting both ESP32 and PC to the same router - that often lowers latency. - Disable WiFi power save on the ESP32 to avoid TX aggregation delays. - Avoid doing heavy camera encoding and servo control in the same single loop on the ESP32 - use separate tasks or keep servo handling extremely lightweight. - Power: ensure servos have a proper 5V supply and common ground with the ESP32. Power sag can look like weird delays. Minimal low-latency UDP test (ESP32 Arduino sketch) - Purpose: bypass ARC for a moment; verify how fast the ESP32 actually applies commands when receiving network packets. - Behavior: starts AP (or STA if you change), disables WiFi power save, listens UDP port 8888, parses packets of form "servoIndex,microseconds" (e.g. "0,1500"), updates servo PWM immediately, and sends an ACK back so you can measure RTT. Flash this to your ESP32 (adjust SERVO_PIN and AP vs STA block as needed): cpp // UDP Servo Test for ESP32 DevKit v1 #include  #include  #include  // --- CONFIG --- #define USE_AP true // set to false to use STA mode (connect to router) const char* ap_ssid = "ESP32-TEST"; const char* sta_ssid = "YOUR_ROUTER_SSID"; const char* sta_pass = "YOUR_ROUTER_PASS"; const int UDP_PORT = 8888; const int SERVO_PIN = 18; // change to the GPIO you use const int LEDC_CHANNEL = 0; const int LEDC_FREQ = 50; // 50 Hz for hobby servos const int LEDC_RES = 16; // 16-bit resolution WiFiUDP udp; char packetBuf[128]; void setup() { Serial.begin(115200); delay(500); Serial.println("UDP Servo Test start"); if (USE_AP) { WiFi.mode(WIFI_AP); WiFi.softAP(ap_ssid); Serial.print("AP IP: "); Serial.println(WiFi.softAPIP()); } else { WiFi.mode(WIFI_STA); WiFi.begin(sta_ssid, sta_pass); Serial.print("Connecting to AP..."); unsigned long t=millis(); while (WiFi.status() != WL_CONNECTED && millis()-t  65535) dutyf = 65535; return (uint32_t)dutyf; } void loop() { int packetSize = udp.parsePacket(); if (packetSize) { int len = udp.read(packetBuf, sizeof(packetBuf)-1); if (len > 0) packetBuf[len] = 0; String s = String(packetBuf); // Expected format: "servoIndex,pulseUs" e.g. "0,1500" int comma = s.indexOf(','); if (comma > 0) { int idx = s.substring(0, comma).toInt(); int pulse = s.substring(comma+1).toInt(); // For now we only support single servo channel mapping (idx unused) uint32_t duty = pulseUsToDuty(pulse); ledcWrite(LEDC_CHANNEL, duty); // Send ACK IPAddress remote = udp.remoteIP(); uint16_t remotePort = udp.remotePort(); String ack = String("ACK,") + String(millis()); udp.beginPacket(remote, remotePort); udp.write(ack.c_str()); udp.endPacket(); Serial.printf("Recv:%s -> pulse=%d duty=%u
", packetBuf, pulse, duty); } } }  PC test client (Python) - measures RTT and shows latency - Replace ESP32_IP with your board IP (AP default 192.168.4.1). This sends a few packets and prints RTT. python import socket, time ESP32_IP = "192.168.4.1" # change if using STA mode PORT = 8888 sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(1.0) def send_pulse(pulse_us): msg = f"0,{pulse_us}".encode() t0 = time.time() sock.sendto(msg, (ESP32_IP, PORT)) try: data, addr = sock.recvfrom(1024) rtt = (time.time()-t0)*1000.0 print(f"ACK from {addr}, RTT = {rtt:.1f} ms, data={data}") except socket.timeout: print("No ACK (timeout)") # test for pulse in [1000, 1500, 2000, 1500]: send_pulse(pulse) time.sleep(0.1)  How to interpret results - If ping shows low ms but your UDP RTTs are low (tens of ms) and servo moves instantly, then the ESP32 can handle low-latency control - the problem is likely ARC skill settings, camera streaming, or how ARC/client is sending (flooding or batching). - If ping shows very high latency or packet loss, that’s the network/AP problem. Try STA mode via router or different PC WiFi adapter. - If ping is fine but UDP RTT is high or ACKs delayed, then the ESP32 firmware is probably CPU-starved by camera encoding/streaming or WiFi power-save/aggregation (disable PS and separate tasks). ARC-side checks (kebab menu + skill settings) - Open the Single Camera Servo Server or whichever skill is sending commands. - Click the kebab menu (three-lines) -> Settings. - Look for Update Interval / Send Interval / Frame Rate options and set low intervals for servo updates (e.g. 20-50 ms) while testing. - If the skill has a "Cache & Send" pattern, enable it so updates are batched (this reduces send overhead). Follow-up questions (I need this to continue) 1. Is the camera running on that DevKit while you see the 9-second delay? Try the UDP test with camera turned OFF first and report results. 2. How many servos and which GPIO pins are you using (list pins)? How are they powered (USB, battery, separate 5V regulator)? Describe battery type and voltage. 3. Did ping to 192.168.4.1 show large RTTs or packet loss? Paste 10 lines of ping output here. 4. Are you using Single Camera Servo Server or a Synthiam EZB (WiFi/EZB protocol) skill to talk to the board, or a custom client? Which skill in ARC is sending the servo commands? If you want, I will: - Provide a variant of the ESP32 sketch that runs camera stream in a separate lower-priority task while keeping servo updates in a high-priority task (helpful if camera is on-board). - Provide recommended ARC skill settings (exact names/locations) you should change in the kebab menu once you confirm which skill you’re using. Which do you want to try next - run the UDP test (I can help adjust the sketch for STA mode and your pins), or should I prepare the "separate tasks" sketch with camera + servo split?

fxrtst · Answer

@dave yeah something isnt right because, I get plenty of correctly moving servos with this esp-32 and other software over wifi . I've changed computers incase it was the wifi in my desktop, laptop gets the same 9 sec delay. I changed the baud rate and still same results. I changed servos 3 times, only other thing i was going to do was move the servo power off the board to see if it was a power issue from the board ie servo under powered. This testing is not the red board above. as that needs new IO pin remaping in the firmware. Testing has been on this board: https://synthiam.com/Support/Hardware/Esp32-DevKit-v1 This board has NO camera. I wanted my testing to be progressive..ie get a regular ESP32 board flashed and working before i spent the energy on the Freenove board above with camera. EDIT: Took the servo power off the board same thing happening.

fxrtst · Answer

I'm starting to wonder if the Espressif libraries changed since this last firmware was released in 2024. Or the ESP32Servo by Kevin Harrington.

Athena · Answer

Thanks - good troubleshooting so far. You’ve proven it’s not the servos, not the PC, and not the board’s servo power (you removed servo power and saw the same behavior). That narrows it down to firmware / network / protocol handling or the way ARC/skill and the ESP32 firmware are talking. Below is a focused diagnosis + actionable steps (with a minimal test sketch) to isolate whether the problem is: - the Synthiam firmware you flashed (or the Arduino ESP32 core / libraries used to build it), or - network/TCP behaviour between ARC and the ESP32, or - the way servo PWM is implemented (Servo library vs LEDC). Please try these in order. I included a low-latency UDP test sketch that bypasses ARC so you can confirm the ESP32 itself can respond quickly. 1) Immediate checks (quick) - Confirm AP vs STA: are you using ESP32 in AP (default 192.168.4.1) or STA (connected to router) mode? Try STA mode (connect both PC and ESP32 to same router) - STA often has lower latency than AP on PC adapters. - Ping the ESP32 IP from the PC while you reproduce the delay: - Windows: open cmd and run: ping 192.168.4.1 -n 20 (or the ESP32 STA IP) - Paste 10 lines of results here. We need to see if raw network latency or packet loss exists. - Temporarily disable any camera stream and other robot skills in ARC. Test only servo commands. - Confirm which ARC robot skill is sending commands to the board (Synthiam "ESP32 DevKit v1" EZB skill? Single Camera Servo Server? Serial Toolbox?) - open that skill and check Settings (kebab menu) for any "Update Interval", "Send Interval", or "Frame Rate" options and set them small (20-50 ms) while testing. 2) Bypass ARC: use a UDP test to measure true RTT and response - If the ESP32 can respond in single-digit to low-double-digit ms to direct UDP packets, the issue is likely ARC/skill or TCP buffering. - Flash this minimal UDP + LEDC servo sketch to your DevKit v1 (adjust SERVO_PIN if needed). It: - runs in AP by default (set USE_AP false for STA), - disables WiFi power save, - listens UDP port 8888, - maps pulses in microseconds to ledc duty and writes immediately, - replies with an ACK (so you can measure RTT). - Flash and run it, then run the small Python client below from your PC to test RTT. ESP32 UDP + LEDC servo sketch cpp // UDP Servo Test for ESP32 DevKit v1 (LEDC PWM, no Servo library) #include  #include "esp_wifi.h" #include  #define USE_AP true // set false to use STA mode (change SSID/PASS below) const char* ap_ssid = "ESP32-TEST"; const char* sta_ssid = "YOUR_ROUTER_SSID"; const char* sta_pass = "YOUR_ROUTER_PASS"; const int UDP_PORT = 8888; const int SERVO_PIN = 18; // change to your GPIO const int LEDC_CHANNEL = 0; const int LEDC_FREQ = 50; // 50 Hz for hobby servos const int LEDC_RES = 16; // 16-bit WiFiUDP udp; char packetBuf[128]; uint32_t pulseUsToDuty(uint32_t us) { // For 50Hz: period = 20000us. duty = (us/period) * (2^RES - 1) float period = 20000.0; float dutyf = ((float)us / period) * ((1UL  ((1UL  0) packetBuf[len] = 0; String s = String(packetBuf); // expected "servoIndex,pulseUs" e.g. "0,1500" int comma = s.indexOf(','); if (comma > 0) { int pulse = s.substring(comma + 1).toInt(); uint32_t duty = pulseUsToDuty(pulse); ledcWrite(LEDC_CHANNEL, duty); // send ACK with timestamp String ack = String("ACK,") + String(millis()); udp.beginPacket(udp.remoteIP(), udp.remotePort()); udp.write(ack.c_str()); udp.endPacket(); Serial.printf("Received: %s -> pulse=%d duty=%u
", packetBuf, pulse, duty); } } }  PC test client (Python) - measures RTT python import socket, time ESP32_IP = "192.168.4.1" # change if using STA and different IP PORT = 8888 sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(1.0) def send_pulse(pulse_us): msg = f"0,{pulse_us}".encode() t0 = time.time() try: sock.sendto(msg, (ESP32_IP, PORT)) data, addr = sock.recvfrom(1024) rtt = (time.time() - t0) * 1000.0 print(f"ACK from {addr}, RTT = {rtt:.1f} ms, data={data}") except socket.timeout: print("No ACK (timeout)") for p in [1000, 1500, 2000, 1500]: send_pulse(p) time.sleep(0.05)  Expected results - Good: RTTs in single/double-digit milliseconds and servo moves immediately. - Bad: RTTs in seconds / no ACKs / huge jitter -> indicates network or firmware blocking. 3) If the UDP test is fast, the ESP32 is capable - problem is ARC / robot skill or TCP - Many robot skills use TCP. TCP + Nagle + small writes can cause buffering if TCP_NODELAY isn’t set or if ARC/skill batches updates at long intervals. - If the robot skill or Synthiam firmware uses TCP and you can’t change it, try: - look in the skill kebab Settings for "Send Interval" and lower it (20-50 ms). - if the skill uses camera + servo on same TCP link, temporarily stop camera streaming and test servo-only. - if the skill has a "Cache & Send" option, try enabling/disabling it to see differences. - If you have server-side control (firmware), prefer UDP for servo control or ensure TCP_NODELAY is enabled on the socket (if your firmware/library supports it). 4) If UDP test is slow / inconsistent -> firmware or core/library problem - You mentioned wondering if Espressif libraries changed since that Synthiam firmware was released, or if ESP32Servo by Kevin Harrington changed. That’s a valid suspicion. - Things to check: - Which exact Synthiam ESP32 firmware version did you flash? (Paste the version string or link) - Which Arduino-ESP32 core version was used to compile that firmware originally? The ESP32 Arduino core changed many internals in some releases; if the firmware was built against one core and you recompiled with another, behavior can differ. - If Synthiam provided a precompiled bin, get the build notes (board/core versions). If not, recompile using the same ESP32 core version they used when building the firmware. - In your own tests, avoid the Servo library (which can use timers and may be less predictable). Use LEDC (ESP32 hardware PWM) as above - it’s more deterministic and lower overhead. How to check Arduino/ESP32 core version - Arduino IDE: Tools Board Boards Manager search for "esp32" the installed version is displayed. - PlatformIO: open platformio.ini and check platform = espressif32 @ x.y.z If you want, I can: - Build a small firmware variant that uses LEDC PWM and a TCP/UDP server configured the way ARC needs, plus disabling power save and using a separate high-priority task for servo writes (helpful if camera is later added). - Show how to set TCP_NODELAY in ESP32 (if using WiFiClient - there's a method in some core versions; otherwise use raw sockets and setsockopt). - Help you recompile the Synthiam firmware against a specific ESP32 core version if you give me the firmware source or version number. 5) Useful next diagnostics I need from you Please paste these: - Firmware you flashed (link or version string from the Synthiam page or binary). - The ping output to the ESP32 IP (10 lines). - Whether you are currently using AP or STA mode. - Which ARC robot skill is used to talk to the board (Synthiam ESP32 DevKit skill? or custom TCP from Single Camera Servo Server?). - If you’ve tried the UDP sketch above, paste the Python client outputs and describe whether servo motion is instantaneous. 6) Immediate recommended workaround if you need a working solution now - Use a small MCU (Teensy/Pro Micro) as a dedicated servo controller reachable by ARC via Serial or a fast UDP bridge; keep ESP32 only for camera/streaming (or vice versa) - this avoids mixing heavy WiFi/camera load with servo timing. (If you want to pursue this, I can provide the Serial Toolbox + Teensy wiring steps described in the Serial Toolbox docs.) - Or recompile the ESP32 firmware using the same Arduino core used when Synthiam released that firmware version (if you can find that version). Summary / Offer - I can prepare and tailor the UDP/LEDC test sketch (or STA-mode variant) for your exact servo pin(s). - I can prepare a "separate tasks" sketch that keeps servo handling high-priority and camera in a lower-priority thread (useful once you add camera). - I can help you locate/confirm the Arduino core version Synthiam used and provide steps to recompile. Which do you want right now? - A ready-to-flash UDP+LEDC sketch preconfigured for your servo pins (tell me the pin(s) and whether you prefer AP or STA), or - Help checking the firmware / core version and steps to recompile the Synthiam image? Also, paste your ping output and the firmware version if possible - that will let me narrow down the cause faster.

fxrtst · Answer

@Athena remove any remarks in your instructions where a camera is mentioned. The Esp32 i am testing on does NOT have a camera. I want to start with the bare minimums to get started. Like just getting a single servo to move properly. So lets disregard any instructions about a camera for now.

Athena · Answer

Perfect - thanks for the clarification. I’ll remove any camera references and keep this strictly to the bare minimum: get one servo moving reliably and measure latency. Below is a focused plan, a ready-to-flash minimal ESP32 sketch (no camera code), a Python test client to measure round-trip time (RTT), wiring / power checks, and next steps if you still see the ~9 second delay. What this will do - Run a small WiFi UDP server on the ESP32 (AP by default, or change to STA). - Disable WiFi power save (to avoid aggregation/sluggish TX). - Accept UDP packets of the form "0,1500" (servoIndex not used here, pulse in microseconds). - Immediately write to the servo using ESP32 LEDC hardware PWM (no Servo library). - Reply with an ACK so the PC can measure RTT. 1) Wiring & power (do this before flashing) - Use an external regulated 5V supply for the servo. Do NOT power servos from the ESP32 3.3V or from the USB alone if servo current is significant. - Connect servo ground to the ESP32 GND (common ground required). - Connect servo signal to a safe GPIO (recommended: 18, 19, 21, 22, 23, 25, 26, 27, 32, 33). Default in the sketch is GPIO 18. - Add a 1000 F decoupling capacitor across servo 5V and GND near the servos if possible. 2) Flashable ESP32 sketch (AP default) - Change USE_AP to false and set STA SSID/PASS if you want Station mode (recommended if you have a router). - Change SERVO_PIN if you want a different GPIO. cpp // UDP Servo Test for ESP32 DevKit v1 (no camera) // Uses LEDC hardware PWM, disables WiFi power save. // Send UDP "0,1500" -> servo pulse 1500us. Replies "ACK," #include  #include  #include "esp_wifi.h" // CONFIG #define USE_AP true // true = AP mode (192.168.4.1). Set false to use STA mode. const char* ap_ssid = "ESP32-TEST"; const char* sta_ssid = "YOUR_ROUTER_SSID"; const char* sta_pass = "YOUR_ROUTER_PASS"; const int UDP_PORT = 8888; const int SERVO_PIN = 18; // change to your pin const int LEDC_CHANNEL = 0; const int LEDC_FREQ = 50; // 50 Hz for hobby servos const int LEDC_RES = 16; // 16-bit resolution WiFiUDP udp; char packetBuf[128]; uint32_t pulseUsToDuty(uint32_t us) { // period = 1/50Hz = 20000 us float period = 20000.0; float dutyf = ((float)us / period) * ((float)((1UL  ((1UL  0) packetBuf[len] = 0; String s = String(packetBuf); // expected "0,1500" int comma = s.indexOf(','); if (comma > 0) { int pulse = s.substring(comma + 1).toInt(); if (pulse  2500) pulse = 2500; uint32_t duty = pulseUsToDuty(pulse); ledcWrite(LEDC_CHANNEL, duty); // reply ack with timestamp String ack = String("ACK,") + String(millis()); udp.beginPacket(udp.remoteIP(), udp.remotePort()); udp.write(ack.c_str()); udp.endPacket(); Serial.printf("Recv: %s -> pulse=%d duty=%u
", packetBuf, pulse, duty); } } }  3) Minimal PC test client (Python) - Replace ESP32_IP with the device IP (AP default 192.168.4.1). Run from the PC connected to the ESP32 AP or same LAN if STA. - This measures RTT and will show if commands are being ACKed quickly. python # udp_servo_test.py import socket, time ESP32_IP = "192.168.4.1" # change if STA mode and different IP PORT = 8888 sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(1.0) def send_pulse(pulse_us): msg = f"0,{pulse_us}".encode() t0 = time.time() try: sock.sendto(msg, (ESP32_IP, PORT)) data, addr = sock.recvfrom(1024) rtt = (time.time() - t0) * 1000.0 print(f"ACK from {addr}, RTT = {rtt:.1f} ms, data={data}") except socket.timeout: print("No ACK (timeout)") for p in [1000, 1500, 2000, 1500]: send_pulse(p) time.sleep(0.05)  4) Quick validation steps - Flash sketch to ESP32 and open Serial Monitor. - Connect PC to ESP32 AP (if USE_AP true) or ensure ESP32 and PC are on same LAN (if STA). - Run the Python client. - Expected: ACK messages with RTT typically < 50 ms (single/double digits). Servo should visibly move almost immediately upon packet receipt. - If you see no ACK or very large RTTs (seconds), collect these diagnostics. 5) Diagnostics if you STILL see ~9 second delays - Run a ping from the PC to the ESP32 IP: - Windows: open cmd and run: ping 192.168.4.1 -n 20 - mac/linux: ping -c 20 192.168.4.1 - Paste 10 lines of output here. - Note whether the delay is in ping replies (network issue) or the UDP RTT (firmware/app issue). - If ping shows low latency but UDP RTT is still seconds: something at application/server level is blocking (but the above sketch keeps loop very lightweight so it should be immediate). - If ping is high or shows timeouts: try STA mode on a router or try a different WiFi adapter (you already tried two computers - still useful to try a router-based STA). - If the sketch responds fast via UDP but ARC still shows 9s: ARC/robot skill or how ARC is sending commands is likely the cause (we can then look at that skill’s settings or how the skill batches sends). Tell me which ARC skill you are using to send commands. 6) Quick checklist of common pitfalls (no camera) - Common ground between servo supply and ESP32 ground. - Use hardware PWM (LEDC) - sketch does that. - Avoid pins used by flash (6-11), and avoid input-only pins for servo outputs (34-39). - WiFi in AP mode sometimes causes poor latency with certain PC WiFi adapters - try STA via router if possible. - WiFi power save must be off (the sketch calls esp_wifi_set_ps(WIFI_PS_NONE)). 7) Next steps & what I need from you Please run the above test and paste the following outputs here: - The ESP32 Serial Monitor log after boot (shows AP or STA IP). - Python client output (ACK and RTT lines). - If you still see ~9s delay, paste 10 lines of ping output to the ESP32 IP. Also tell me: - Do you want AP mode (easy direct connect) or STA mode (connect to router)? If STA, provide WiFi SSID (or just confirm you’ll set it). - Which GPIO are you actually using for the servo (if not 18)? - How is the servo powered (battery/regulator/USB)? State voltage and approximate current capability. I’ll use those results to tell you exactly what to change next (either firmware tuning, router vs AP guidance, or ARC skill configuration). Want me to prepare a STA-only variant of the sketch pre-configured for your WiFi?

fxrtst · Answer

Well start with the obvious. Rookie mistake. I kept wondering if it was the libraries and sure enough success will only work with the stated library versions listed on the DoItESP32 page. DJ even says no guarantee for any other library versions. He is right, current version is not the best options and a little google snooping says current versions are not stable. So stick with those listed versions of both libraries on compiling the code.  All good and running great. Servo acts normal. Now to move on to the camera version and bigger and better ESP 32s.

Athena · Answer

Great news - nice detective work! Glad you found the root cause: mismatched ESP32/servo libraries can absolutely cause the symptoms you saw. DJ’s note about using the exact library/core versions is spot-on - newer core/library changes sometimes break timing/behavior for servo or WiFi features. A few short confirmations, recommendations and next steps now that the bare-minimum servo test is working and you’re moving to the camera-enabled build. What you discovered - The problem was library/core version mismatch. Using the versions listed on the DoItESP32 page fixed the ~9 second lag. - That indicates the firmware + compile environment (Arduino-ESP32 core + servo library) must match the versions the firmware was written for. Recommended next steps for the camera version 1. Pick the right ESP32 board for camera work - Use an ESP32 module with PSRAM for better camera performance (ESP32-WROVER/PSRAM variants or AI-Thinker ESP32-CAM depending on your needs). PSRAM helps with frame buffers, JPEG encode, etc. - Synthiam ESP32-Cam support: https://synthiam.com/Support/Hardware/ESP32-Cam 2. Reuse the working compile environment - Use the same Arduino-ESP32 core and library versions you used for the servo-only build when you compile the camera firmware. Don’t upgrade those libraries until you confirm everything works. - If you want, tell me what versions you used and I’ll note them in a snippet for future reference. 3. Keep servo control deterministic - Use LEDC (hardware PWM) for servos on ESP32 where possible (more stable than some Servo libs). - Keep servo updates in a lightweight/high-priority path (separate task if your camera code is heavy). - Keep servo power on an external 5V supply with common ground to the ESP32. 4. WiFi and latency settings (no camera yet - but keep in mind) - Use STA mode (connect both PC and ESP32 to same router) if you need reduced AP-mode latency with some PC adapters. - Disable WiFi power-save when low-latency is required: esp_wifi_set_ps(WIFI_PS_NONE). - If you still need very low-latency servo control with heavy camera usage, consider splitting roles: one ESP32 for camera, another microcontroller (or small MCU/Teensy) for servos and fast control. 5. Camera stream tuning (when you add camera) - Reduce resolution and FPS while you tune latency: try VGA/QVGA and 10-15 FPS first, then increase. - Reduce JPEG quality if bandwidth/CPU is a bottleneck. - Use the ARC Single Camera Servo Server skill and reduce frame size/FPS there while testing: https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 Useful Synthiam links - ESP32 DevKit v1 support: https://synthiam.com/Support/Hardware/Esp32-DevKit-v1 - ESP32-CAM support: https://synthiam.com/Support/Hardware/ESP32-Cam - Single Camera Servo Server skill: https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 - Robot Skill Tutorial (if you want to wrap or customize skill behavior): https://synthiam.com/Support/Create-Robot-Skill/Overview/Overview I can help with any of the following (pick one): - Prepare a camera-enabled ESP32 firmware sketch that uses the exact core/library versions you validated for the servo test, and separates servo updates from camera capture (task split). - Suggest the exact compile/platform settings (Arduino core + library versions) if you tell me the versions you used for the working servo build. - Walk you through ARC Single Camera Servo Server settings (kebab menu) to tune FPS, resolution and servo update rate for best latency. - Recommend hardware (which ESP32 module to buy for your camera + five servos Mecha Morphix) and wiring/power plan. A couple follow-up questions 1. Which ESP32 camera board do you plan to use next (AI-Thinker ESP32-CAM, WROVER, Freenove board, etc.)? 2. Which exact library/core versions did you find that worked for the servo-only build? (If you tell me I’ll lock those into any camera firmware I prepare.) 3. How do you want to connect to ARC for the camera build - AP direct-to-PC or STA via router? Note about images - You attached images - I can’t view photos. If they include any text or logs you want me to see, please paste the exact text here. If you want, I’ll prepare a camera-enabled firmware draft (with the same cores/libraries) that separates servo updates into a real-time-safe task and the camera into a lower-priority task. Tell me the board you’ll use and the library versions you validated and I’ll build it for you.

Nink · Answer

Glad you sorted it out.  I was wondering what was going on as I have these controlling everything from remote control cars to robot arms without any major issues.   you should make sure you have seperate power for the servos though or you will get brown outs. Oh and tie the grounds together. (Separate power and ground wires not tied will exhibit the type of problem you are seeing but I believe you were using the same power for both and a small low amp servo so then this would not be the case)

Athena · Answer

Good troubleshooting work - and thanks for the follow-up info. A few quick confirmations, best-practices, and options now that you’ve got the servo-only test working. What Nink said (short version) - Always use a separate regulated 5V supply for servos (don’t power from ESP32 3.3V / USB if servo current is nontrivial). - Tie the servo supply ground to the ESP32 GND (common ground). - Add local decoupling (1000 F or similar) across the servo supply near the servos to prevent voltage dips/brownouts. Concrete checklist (servo-only, minimal setup) - Supply: 5V regulator/battery rated for expected stall current (typical hobby servos ~500 mA each under load; plan accordingly). - Ground: connect servo GND to ESP32 GND with a short heavy wire. - Signal: run servo signal to an ESP32 GPIO capable of PWM (avoid flash/power pins; default ESP32 DevKit pins like 18/19/21/22/23/25/26/27/32/33 are good). - PWM: prefer LEDC (hardware PWM) on ESP32 rather than some Servo libraries - more deterministic. - Decoupling: add a 1000 F electrolytic near the servos + 0.1 F ceramic. - WiFi: if you were using AP mode and got odd latency, STA via a router often reduces jitter (but you already fixed the library mismatch). Suggestions for camera + servo next steps - Board choice: - AI-Thinker ESP32-CAM (cheap) - has onboard camera but limited usable GPIO for multiple servos. - ESP32-WROVER (with PSRAM) or WROVER-based dev boards - better for camera buffering/encoding and general performance. - If you must drive 5 servos reliably and also run camera/streaming on the same ESP32: - Continue using LEDC for servo PWM. - Keep servo updates in a lightweight task or high-priority handler and camera capture in a separate lower-priority task. - Consider using a PCA9685 I2C servo driver to offload PWM and current from the ESP32 (PCA9685 also lets you use one stable 5V power rail and frees GPIO). - Reuse the exact Arduino-ESP32 core and servo/library versions that worked for your servo-only build when compiling camera firmware (you already discovered library mismatch is critical). ARC/Robot skill notes - If you plan to use ARC skills for camera + servo control: - Single Camera Servo Server skill is the expected Synthiam skill for camera + servo streaming: https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 - ARC ESP32 support docs: https://synthiam.com/Support/Hardware/ESP32-Cam and https://synthiam.com/Support/Hardware/Esp32-DevKit-v1 - To configure a robot skill in ARC: Project -> Add Robot Skill, then open the skill’s kebab menu (three lines) in the top-right of the robot skill window to access Settings and tuning options (frame size, fps, update/send intervals etc.). If you want, I can recommend exact skill settings to reduce latency once you pick board + stream settings. Offer: what I can prepare for you - A camera-enabled ESP32 firmware sketch that: - Uses the same library/core versions you validated for servo-only, - Uses LEDC for servos, - Splits servo updates and camera capture into separate tasks, - Optionally uses PCA9685 if you prefer. - A STA-mode preconfigured sketch (if you prefer router-based connection). - Help tuning ARC skill settings (kebab menu) for best latency vs quality. Follow-up questions 1. Which camera board will you use next? (AI-Thinker ESP32-CAM, Freenove, ESP32-WROVER, etc.) 2. Which exact library / Arduino-ESP32 core versions did you lock in for your working servo-only build? (If you paste the versions, I’ll use the same for any camera firmware.) 3. How will servos be powered for Mecha Morphix (supply voltage and maximum current capability)? Which exact servo models (or expected stall current)? 4. Do you want me to prepare a camera-enabled sketch or a PCA9685 + ESP32 example? Do you prefer AP or STA mode? One note about images: I can’t view attached photos - please paste any console output, logs, or relevant text directly in your reply. If you tell me the board and the working library versions, I’ll draft a ready-to-flash camera + servo sketch tuned to your environment and provide the ARC skill settings to use in the kebab menu.

fxrtst · Answer

Yeah it’s just a single servo for eps32 testing. In later tests took the servo off the expansion board incase it’s was causing issues with a battery with shared grounds. It def was the ver of libraries. All working great now.

Athena · Answer

Fantastic - glad you found the root cause and have the singleservo test running reliably. Quick confirmation and a short checklist so this success is repeatable: What caused it - Library / ArduinoESP32 core version mismatch. Some ESP32 cores and servo libraries changed in ways that affect timing, WiFi, and PWM behavior - using the exact versions the firmware was written for fixes those issues. Minimal best practices (singleservo testing) - Use LEDC (hardware PWM) on the ESP32 where possible - more deterministic than some Servo libraries. - External 5 V supply for the servo if there’s any load (even a single servo under stall can draw a lot). - Common ground: tie servo supply GND to the ESP32 GND with a short, solid wire. - Decoupling: 1000 F electrolytic near the servo power + 0.1 F ceramic. - Avoid pins used for flash (GPIO 6-11) and inputonly pins (34-39) for servo signals. - Record the exact library/core versions that worked so you can reproduce builds later. How to "lock" the working environment - Arduino IDE: Tools Boards Manager note the installed esp32 core version. - Library Manager: note the exact library versions (e.g., ESP32Servo or any other servo helper library). - PlatformIO: set the espressif32 platform version in platformio.ini (recommended for reproducible builds). If you plan to expand later (more servos or extra features) - Consider a PCA9685 I2C servo driver to offload PWM and current from the ESP32 (frees GPIO and reduces timing risk). - If you need help, I can provide a PCA9685 example sketch + wiring. I can help next with any of these (pick one) - Save your working build info: I can give the exact platform/library lines you should copy into a README. - Prepare a readytoflash minimal ESP32 LEDC sketch configured for your servo pin and the exact core/library versions you used. - Provide a PCA9685 + ESP32 example if you want to scale to more servos. A couple quick questions so I can prepare the exact files if you want: 1. Which ESP32 dev board are you using (Esp32DevKitv1 or another)? 2. Which exact ArduinoESP32 core version and servo library version did you use that worked? 3. Which GPIO did you use for the servo, and how is the servo powered (regulator/battery + voltage and current capability)? If you paste those three items I’ll put together a readytoflash sketch or a short README you can keep with the project.

Dave Schulpius · Answer

Wow, nice work so far Will ( @fxrtst )! We're watching! LOL.

Athena · Answer

Nice! Great to see the community cheering you on - and awesome work tracking the root cause down. If you want, I can help with the next steps. Pick one and I’ll prepare it: - Prepare a camera-enabled ESP32 firmware (using the same Arduino-ESP32 core + servo library versions that worked for your servo test) and separate servo updates into a high-priority/LEDC task. - Create a PCA9685 + ESP32 example (wiring + sketch) so you can scale to 5 servos without stressing the ESP32 or your power rail. - Produce a short reproducible README / platform config showing the exact core + library versions and PlatformIO/Arduino settings you should lock down. - Walk through recommended ARC skill (Single Camera Servo Server) kebab settings for best latency vs quality when you add the camera. Before I start, quick questions so I tailor the work: 1. Which ESP32 board will you use next for the camera (AI-Thinker ESP32-CAM, WROVER, other)? 2. What exact Arduino-ESP32 core version and servo library version did you lock in that solved the issue? (If you don’t know, paste your PlatformIO/Arduino versions or the output from Boards Manager.) 3. Do you want AP (direct connect) or STA (router) mode for the camera build? 4. How will the servos be powered for Mecha Morphix (voltage, regulator / battery rating, and servo model or expected stall current)? 5. If you attached images earlier with logs or text - I can’t view images. Please paste any console output or log text you want me to see. Links that may help as you move to camera + multi-servo: - ESP32-Cam support: https://synthiam.com/Support/Hardware/ESP32-Cam - ESP32 DevKit v1 support: https://synthiam.com/Support/Hardware/Esp32-DevKit-v1 - Single Camera Servo Server skill: https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 - Robot Skill Tutorial (create/customize): https://synthiam.com/Support/Create-Robot-Skill/Overview/Overview Tell me which option above you want and paste the version info if you have it - I’ll put together the exact code/config you need.

fxrtst · Answer

@Athena i am going to test the firmware that exists for the ESP32 Cam EZB located here: https://synthiam.com/Firmware/ESP32-Cam-EZB-5KUNP4UTSW0 I ordered and have this board to test with. If all works correctly, I will move onto the Freenove ESP32 CAM Board. We will be working together to implement, the camera and remap the pin outs to create new firmware for the Freenove ESP32-S3 CAM Board. Hopefully its just combining code from the ESP32 DOIT Devkit V1 and the ESP32 CAM board and remapping the pins for digital and analog.

Athena · Answer

Nice plan - good choice starting with the Synthiam ESP32-Cam EZB firmware binary and verifying that first. Below is a practical, step-by-step roadmap for testing the Synthiam firmware on your board, then porting/remapping it for the Freenove ESP32-S3 CAM. I’ll include flashing tips, what to check in ARC, pin-remap guidance, and the main pitfalls (camera pins, PSRAM, cores & libraries). If you want, I can prepare starter source code for the Freenove once you confirm the exact pinout and whether you have the firmware source. Useful links - Synthiam ESP32 Cam EZB firmware (the binary you linked): https://synthiam.com/Firmware/ESP32-Cam-EZB-5KUNP4UTSW0 - Synthiam ESP32-Cam support doc: https://synthiam.com/Support/Hardware/ESP32-Cam - Single Camera Servo Server skill: https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 - Robot skill creation doc (if you need a custom skill later): https://synthiam.com/Support/Create-Robot-Skill/Overview Phase 1 - Test the supplied Synthiam firmware on your board 1. Confirm board model and required tools - Identify the exact ESP32-CAM board you ordered (AI-Thinker / model name). The binary is typically built for a specific camera module/board. - Install esptool.py or the Espressif Flash Download Tool. Have a USB-TTL or built-in cable ready. 2. Flash firmware (recommended safe approach) - Put the ESP32 into flash mode (typically GPIO0 to GND while resetting on many boards). - Example using esptool (adjust COM port and filename): esptool.py --chip esp32 --port COM3 --baud 115200 write_flash -z 0x1000 ESP32-Cam-EZB.bin - If you prefer GUI: use the Espressif "ESP32 Download Tool" and follow its prompts. Note: Some vendor binaries require specific partition offsets-if the binary page on Synthiam includes flash instructions use them. If you hit bootloader/flash errors, paste the serial log and I’ll help. 3. Monitor serial output - Open Serial Monitor at 115200 baud (or whatever the firmware prints). - Confirm WiFi mode (AP or STA), IP address, and camera initialisation messages. Paste them here if anything looks odd (I can’t view images - paste the exact text). 4. Connect ARC - In ARC add a Camera Device skill, choose Custom if needed, or add the Single Camera Servo Server skill to connect to the EZB camera server. - Use the IP reported on the serial monitor (AP default is often 192.168.4.1). - Use the kebab (three-line) menu in that robot skill to set resolution/FPS and map camera -> skill. (Open the skill window -> three lines -> Config/Settings.) 5. Quick functional tests - Confirm camera video appears in ARC. - Confirm servo control works (if the firmware supports servo IO): test a single servo first with the LEDC-based control approach you validated earlier. - Check latency and stability with the servo + camera together. Drop resolution/FPS if camera CPU/bandwidth affects servo response. Phase 2 - Prepare to port/remap for Freenove ESP32-S3 CAM Important considerations before touching source: - ESP32-S3 is a different SoC (ESP32-S3) from classic ESP32. The camera driver and Arduino core versions differ; S3 support in esp32-camera has only more recent support and requires correct core and driver versions. - PSRAM: Many camera tasks need PSRAM for frame buffers. Confirm Freenove S3 board has PSRAM and enable it in the core settings if required. - Camera pin differences: camera GPIOs are typically shared and restrict usable GPIOs for servos. Use only GPIOs that do not conflict with camera or flash pins. - Library/core versions: you already found this - lock the Arduino core and camera/library versions that work for your firmware. For S3 you may need different core versions; test carefully. Pin mapping strategy 1. Get Freenove ESP32-S3 CAM pinout (essential). I can’t see your images, so paste the pin list the Freenove doc provides. We need: - Camera pins (XCLK, PCLK, VSYNC, HREF, D0..D7, SIOD, SIOC, PWDN, RESET). - Usable general-purpose GPIOs not used by the camera or flash interface. 2. Build a table mapping: - camera pins -> camera_config_t - servo pins -> LEDC channels - ADC pins used by ARC -> ADC port mapping 3. Avoid these pins for servos: - Flash pins (GPIO6-11) and any camera-used pins - Input-only pins if you need PWM (e.g., some high GPIOs on classic ESP32) 4. If you only need 5 servos, you have options: - Use free ESP32 GPIOs for LEDC PWM (if available). - Or use a PCA9685 I2C PWM driver to offload servo PWM and free GPIO/CPU - strongly recommended if camera stream + servos run on same chip. Porting steps (high level) 1. Get source - Do you have the Synthiam ESP32-Cam EZB firmware source? If not, we’ll need to implement a new sketch by combining: - Synthiam EZB device protocol and networking code (if they’ve published the SDK/source). - DOIT DevKit ESP32 EZB code you used for servo test. - esp32-camera initialization for Freenove pinout. - If the Synthiam repo/binary includes source or references, share it. If not, I can create a starting sketch implementing the EZB camera & servo server protocol - but it’s easier if we have source. 2. Camera config - Update camera_config_t fields to Freenove pins for the camera. - Set PSRAM flag if available/needed: esp_camera_init with PSRAM enabled for larger frame buffers. 3. Wifi & EZB protocol - Keep the same EZB networking/command handlers (servo set, digital IO, camera stream header format). - Ensure WiFi power-save disabled for low-latency control (esp_wifi_set_ps(WIFI_PS_NONE)). 4. Servos & LEDC - Map selected free GPIOs to LEDC channels. Use 50 Hz and same conversion from microseconds -> duty. - If using PCA9685: set up I2C pins not used by camera and add Adafruit PCA9685 library code. 5. Build environment - Ensure you pick Arduino core versions that: - Support ESP32-S3 (esp32 Arduino core version with S3 support). - Have a working esp32-camera driver for S3 and the Freenove module. - If you have a working core + library versions from your earlier servo tests, tell me what they were - I’ll adapt recommendations. 6. Flash, test & iterate - Flash to Freenove, check serial logs, test camera stream in ARC, then test servo moves. - If problem: capture serial logs and the ARC skill debug messages. Common pitfalls & tips - Wrong camera pin mapping = camera init failure. Serial logs will show "camera probe failed". Paste those logs if you see them. - S3 vs classic ESP32: ensure you’re using the S3-capable Arduino core and esp32-camera S3 branch if required. - PSRAM missing or disabled -> out of memory for higher resolutions. - Camera pins overlapping with USB-Serial/boot config pins: Some pins used by camera or servos can interfere with boot mode. Keep bootstrapping pins in mind. - Start low: first get camera-only streaming working on Freenove; then add servos; then test both simultaneously; then optimize resolution/FPS with ARC skill settings (kebab menu). - If CPU or WiFi bandwidth is saturated, offload servos to PCA9685 or a second microcontroller. What I can do next for you Pick one and I’ll produce it: - Prepare a checklist & ready-to-flash procedure for your exact Freenove S3 CAM if you paste its pinout and confirm PSRAM presence. - Draft an Arduino sketch template for Freenove S3 that initializes the camera (using your pin map) and exposes the EZB camera header stream + simple UDP/TCP servo control endpoints (starter code). - Produce a PCA9685 + ESP32 wiring and example sketch to offload 5 servos (recommended if you want rock-solid timing while streaming). - Help you identify exact Arduino core/library versions required for S3 camera and provide PlatformIO config. Quick questions so I can start the Freenove work 1. Do you have the Synthiam firmware source or only the .bin? (If you have source, share it or confirm where.) 2. Exact Freenove board model and its camera pinout (paste the text from the Freenove doc). Does it have PSRAM? 3. Do you want AP mode (direct connect) or STA (router/LAN) for ARC tests? 4. Do you prefer keeping all servos on the ESP32, or use PCA9685 for servo PWM (I recommend PCA9685 for 5 servos + camera)? 5. Which Arduino-ESP32 core + library versions did you use successfully for your DOIT DevKit servo-only test? (I’ll use that as baseline if possible.) If you paste the Freenove pinout and answer the questions above, I’ll draft the first Freenove sketch pin mapping and a flash/test checklist.

fxrtst · Answer

@Athena In the firmware it asks for camera type and lists : // Select camera model //#define CAMERA_MODEL_WROVER_KIT //#define CAMERA_MODEL_ESP_EYE //#define CAMERA_MODEL_M5STACK_PSRAM //#define CAMERA_MODEL_M5STACK_WIDE #define CAMERA_MODEL_AI_THINKER I am using this board:  https://synthiam.com/Firmware/ESP32-Cam-EZB-5KUNP4UTSW0 What camera model is it? I don't see anywhere on the camera to tell me what camera it is other than OV3660

Athena · Answer

Short answer up front - The common, widelysupported ESP32CAM board that Synthiam builds firmwares for is the AITHINKER module (select CAMERA_MODEL_AI_THINKER). - If the camera module itself reports OV3660, that indicates the sensor chip is an OV3660 (not the usual OV2640 on AIThinker). That can require a different camera config. Don’t assume AI_THINKER if the sensor is OV3660 - we need to verify. What to do next (recommended, stepbystep) 1) Try the Synthiam binary first (safe, fast) - Flash the Synthiam ESP32Cam EZB .bin you linked. - Open a Serial Monitor at 115200 baud, reset/power the board, and watch the boot log. - Look for camera init lines such as "camera init done", "camera probe successful", or any camera sensor identification text. Paste the complete serial output here (I can’t see images - please paste text). Why the serial log matters - The firmware usually logs whether the camera probe succeeded and often prints sensor info or a failure message. That tells us which model the firmware succeeded with (and whether a mismatch exists). 2) If you don’t get useful serial output, or the camera probe fails - The camera model #define in source must match the module/pinout the binary expects. The synthiam binary you linked most likely was built for a particular model (commonly AI_THINKER). If your module’s sensor is actually OV3660, that could cause probe failures unless the firmware was configured accordingly. - If probe fails, paste the serial log and I’ll tell you which #define to use or what pin remapping is needed. 3) If you want to detect the sensor directly (optional) - I can give you a simple Arduino sketch that initializes the esp32 camera with a guessed pinmap and prints the camera probe output / sensor id. If you want that, tell me which board pinout you have (or paste the Freenove pinout) and I’ll prepare the sketch. Quick guide to the #defines you saw in the firmware - CAMERA_MODEL_AI_THINKER - usually corresponds to the common OV2640 modules used on the lowcost ESP32CAM board (AIThinker). If the module is AIThinker / OV2640, this is the right choice. - CAMERA_MODEL_WROVER_KIT, ESP_EYE, M5STACK_* - are for other Espressif development boards or M5Stack modules; each has its own camera pins and sometimes PSRAM differences. If you see OV3660 printed on the camera - That indicates the sensor chip is OV3660. It’s not the usual OV2640, so the default AI_THINKER config may or may not work. We’ll need to: - Verify the camera pin mapping for that module, and - Use a camera_config_t that matches those pins and the correct driver support in the Arduino core being used. What I can do for you right now - Option A - If you flashed the Synthiam .bin already, paste the serial log text here and I’ll interpret it and tell you whether it matched the camera and which change is needed. - Option B - I’ll provide a small detection sketch (Arduino) that will initialize the camera and print the sensor ID and probe result. You can run it and paste the output. - Option C - If you want to move to the Freenove ESP32S3 CAM next, paste the Freenove pinout and confirm whether it has PSRAM; I’ll draft a readytoflash sketch (camera pins + EZB server skeleton) for that board. One reminder: I can’t view images, so please paste any serial text or board pinout text here. Which option would you like me to do now?

fxrtst · Answer

ok I'll try first with AI thinker. The sales pitch for the camera says: "The original OV2640 camera has been updated to OV3660, with clearer and more stable image quality. The usage method remains unchanged, improving efficiency." So hopefully no changes.

fxrtst · Answer

@Athena I'm having trouble connecting to the board in ARC in AP mode. I've flashed it and it doesn't find it/won't connect. I still have the board selected in the IDE as DoIt ESP32 Dev V1, is there another board I should chose in the boards drop down. There are no instructions on the board choice on this page: https://synthiam.com/Firmware/ESP32-Cam-EZB-5KUNP4UTSW0?commentPage=3#comments-list

fxrtst · Answer

Note: The board shows up in my network and its transmitting it just wont connect to the board in ARC.

Athena · Answer

Good - thanks for the details. Let’s methodically troubleshoot why ARC won’t connect to the board in AP mode and get you streaming. Quick checklist (most common causes) - Your PC must be connected to the ESP32 AP WiFi network. If your PC is still on your home router WiFi, it will not see the ESP32 AP IP. - Use the exact IP the board printed on the Serial Monitor (the ESP32 AP default IP is usually 192.168.4.1 but don’t assume - confirm). - ARC needs the camera URL in the Camera Device skill as an EZB stream URL: EZB:// or EZB://:24 (both formats are valid; try both). - Windows firewall, VPN or a network profile can block ARC from connecting - temporarily disable firewall/VPN while testing. - If you flashed a binary, Arduino IDE board selection does not affect runtime connectivity; you only need the proper board type when compiling from source. Stepbystep tests and actions 1) Verify PC is on the ESP32 AP - On your PC, open the WiFi list and connect to the ESP32 SSID the board announces (Serial Monitor shows SSID or it looks like ESP32CAMxxxx). - After connecting, confirm the PC IP is in the same range as the ESP32 AP (e.g., 192.168.4.x). If it’s still on your router (192.168.1.x), switch to the board’s AP. 2) Confirm the board IP from Serial Monitor - Open Serial Monitor at 115200 baud, reset the board, and copy/paste the camera init lines here. - Look for lines like: - "AP mode, IP: 192.168.4.1" - or "Connected, IP: 192.168.1.XX" (if STA mode) Paste the exact text (I can’t view images - text only). 3) Ping the board from your PC - Open a command prompt and run: ping 192.168.4.1 (Replace with the IP shown on Serial Monitor.) - If ping fails, the PC is not connected to the same network (or firewall is blocking ICMP). Fix WiFi connection first. 4) Try the Camera Device skill with an EZB URL - In ARC: Project -> Add Skill -> Camera -> Camera Device (if you already have it open, Stop the camera first). - In the device dropdown choose "Custom" and enter one of: - EZB:// - EZB://:24 (Example) EZB://192.168.4.1 or EZB://192.168.4.1:24 - Press Start. Alternate: Start programmatically (ControlCommand) - Open a Script control and run this JS example: javascript // Replace the IP with the value your board printed ControlCommand("Camera", "CameraStart", "EZB://192.168.4.1");  or javascript ControlCommand("Camera", "CameraStart", "EZB://192.168.4.1:24");  5) If the Camera control still fails to connect - Check ARC debug window (three dots on the Camera skill -> Debug or look at the ARC Console for error text) - paste the error text here. - Try directly opening the board IP in a web browser to test connectivity (this firmware may not provide an HTTP stream page, but it’ll show if the IP is reachable): http://192.168.4.1 (replace IP). If page times out, PC and board are not networked. 6) Firewall / VPN - Temporarily disable Windows firewall or any active VPN and retry the CameraStart step. If it connects with firewall off, create an allow rule for ARC or enable necessary ports. 7) Board selection in Arduino IDE (for compiling/if you recompile source) - If you later compile source, use the esp32 Arduino core and choose the AI Thinker ESP32-CAM board (or "ESP32 Wrover Module" if your core doesn’t list AI Thinker). But this is only for building from source - not required when flashing a .bin with esptool. If you still can’t connect, please provide: - The exact Serial Monitor camera/init output (paste text). - The board IP shown. - The Windows PC IP when you connect to the ESP32 AP (run ipconfig in cmd and paste the IPv4 address). - The exact command or CameraStart error text you see in ARC. If you paste those pieces I’ll: - Tell you the exact CameraStart string to use. - Provide any firewall troubleshooting steps specific to ARC. - If needed, give a small ControlCommand test script you can paste and run to show connection/log output.

fxrtst · Answer

@Athena I used the serial monitor and found the correct IP. So I can connect successfully to the board. But the camera will not connect. Based on your instructions I used "custom" in the camera drop down and added "EZB://192.168.50.1" (The ESP32 CAMs IP address) and then tried with "EZB://192.168.50.1:24". I will not enable the camera. I get the following error :" Camera Initialized: EZB://192.168.50.1:24 @ 320x240 EZ-B v4 Camera Error: The operation has timed out. Camera Disabled"

Athena · Answer

Thanks - good progress getting the board reachable on the network. A Camera "operation has timed out" usually means ARC could not open the EZB camera socket on the port the firmware is listening on (or something on your PC/network is blocking the connection). Let’s troubleshoot step-by-step so we can pinpoint the failure. Quick checklist (to verify first) - Confirm your PC is connected to the ESP32 AP network (same subnet as the ESP32 IP). - Confirm you can ping the ESP32 IP from the PC. - Confirm the ESP32 serial log shows the camera initialized and a camera server listening (we need to see those serial lines). Step 1 - Inspect / paste the serial monitor output 1. Open Serial Monitor at 115200 and reset the board. 2. Copy the camera-related lines. Look for lines like: - camera probe successful / camera init done - camera model / sensor id - AP mode / IP address - "server started" or "listening on port 24" (or similar) Paste those exact camera/server lines here (I cannot view images - please paste text). That will tell us whether the firmware actually started the EZB camera server and which port it bound to. Step 2 - Check the listening TCP port from your PC From your Windows PC open PowerShell (or cmd) and run: PowerShell: powershell Test-NetConnection -ComputerName 192.168.50.1 -Port 24  (or replace 192.168.50.1 with the IP printed on serial). Or use telnet: text telnet 192.168.50.1 24  - If Test-NetConnection reports TcpTestSucceeded : True, the port is open and ARC should be able to connect. - If TcpTestSucceeded : False (timeout / connection refused), the ESP32 is not listening on port 24 or firewall is blocking access. Paste the Test-NetConnection (or telnet) output here. Step 3 - Try common HTTP camera endpoints (quick sanity test) Some ESP32 camera firmware expose an HTTP snapshot/stream endpoint. Try these in a browser (replace IP): - http://192.168.50.1 - http://192.168.50.1:8080/ - http://192.168.50.1/jpg/0.jpg - http://192.168.50.1/capture If any respond, let me know the result. Note: the Synthiam EZB stream is not necessarily the same as those HTTP endpoints, but this helps check the camera stream is running. Step 4 - ARC side: start with the Camera Device skill and get debug text - Open the Camera Device skill in ARC. - Stop/start the camera and capture the Debug/Console output (three-line kebab -> Debug). Copy the exact error text here. - Also try programmatically starting the camera from a Script control so we can capture program outputs: JavaScript example (paste into Script control and run): javascript print("Starting camera via ControlCommand..."); ControlCommand("Camera","CameraStart","EZB://192.168.50.1:24"); print("Done starting command");  Paste any output displayed in ARC or errors shown. Step 5 - Firewall / antivirus / VPN - Temporarily disable Windows Firewall and any VPN/antivirus and re-run the Test-NetConnection and the CameraStart in ARC. If it works with firewall off, add an allow rule for ARC (or allow outgoing TCP to the ESP32 IP/port). Step 6 - If TCP port closed - next actions - Re-check the serial log for any "camera probe failed" messages. If you see camera probe failure (sensor not probed), the firmware may have incompatible camera model/pinmap (OV3660 vs OV2640). Paste the exact camera probe lines. - If serial shows probe OK but no server started line: the firmware may be crashing or failing before server thread creation; paste full serial starting from boot to the camera lines. Step 7 - If everything on the ESP32 side looks OK but ARC still times out - Let’s temporarily test with a raw TCP client to confirm the server responds (e.g., use netcat or socat from another device, or use telnet as above). If that shows a connection, ARC should work; then we’ll look at ARC debug and camera skill settings (resolution, skip frames, preview type) to rule out timeout caused by massive initial negotiation. Notes / likely causes - The firmware may not actually use port 24 (firmware might configure a different port). Serial output will show the expected port. - Windows firewall often blocks local TCP connections to devices when PC connects to a different WiFi network (Windows profile public/private). Temporarily disabling firewall is helpful to test. - OV3660 vs OV2640: some modules switch sensors. If camera probe is failing, you’ll need the correct camera model/pinmap in the firmware. If the synthiam binary assumed OV2640 but your module has OV3660, streaming may fail. What I need from you now 1. Paste the camera-related serial monitor text (full camera init section). 2. Paste the Test-NetConnection or telnet output for the ESP32 IP:24. 3. Paste the ARC Camera Debug console message (the full error output). Once you paste those three items I’ll tell you exactly why ARC times out and give the exact next fix (change camera define in firmware and reflash, open firewall rule, or use a different port / re-run the EZB server). If you want I can also provide a tiny Arduino detection sketch that prints the sensor ID and the camera probe result if serial logs are inconclusive.

fxrtst · Answer

I have success! I changed the board to AI Thinker ESP32-CAM board. And reflashed it and everything works now. Now sure if that was the issue or something else fixed it. I have the OV2640 and the OV3660 cameras and I can confirm that the 3660 is FAR superior quality to the prior camera. I will now add a servo to test the camera and a servo at the same time.

fxrtst · Answer

What I find interesting is that the DoIt ESP32 Dev V1 used the default IP in ARC (192.168.1.1:23) And for the ESP 32 CAM I have to look for the IP via serial monitor and enter that in ARC to connect. Is there something in the DoIt sketch that assigns 192.168.1.1:23 IP to the board? And its not in the sketch for the ESP32 CAM board? I think by default the boards ship with an IP of 192.168.4.1. Both boards are in AP mode. Just asking to be informed.

Athena · Answer

Nice troubleshooting - glad you got it working with the AI-Thinker selection and can stream both OV2640 and OV3660. Here’s a clear explanation of why you saw different default IPs/ports and what controls them, plus how to make the behavior deterministic. Why the IP / port differed between boards - Boards themselves do not "have" a permanent IP. The IP you see is chosen by the firmware running on the ESP32, or by the network (if the ESP32 is in STA mode). - AP mode default for the ESP32 Arduino WiFi library is 192.168.4.1. That’s common, but firmware can change it with WiFi.softAPConfig(). - Some custom firmwares set a different AP IP (e.g. 192.168.1.1, 192.168.50.1) - Synthiam or other vendor binaries sometimes choose a different subnet. That explains why your DoIt board appeared as 192.168.1.1 while the ESP32-CAM reported 192.168.4.1 (or 192.168.50.1 in your case). - If the ESP32 is in STA mode it will get an IP assigned by the router (e.g. 192.168.1.x). Different mode different IP behavior. - Port numbers are also set by the firmware. Synthiam EZB-style camera stream commonly uses port 24 for the EZB stream, but other example sketches or services (telnet-like, raw serial-over-TCP, or different firmware) might use port 23 or another port. ARC will remember previously used camera URLs and show them in dropdowns, so you may see a stored 192.168.1.1:23 entry from earlier usage. How to determine the right IP and port (best practices) 1. Always check the Serial Monitor at 115200 after boot - the firmware prints WiFi mode, assigned IP, and server/listen port. Paste that text if unsure. I can interpret it for you. 2. If in AP mode, connect your PC to the ESP32 AP SSID (so your PC IP is in same subnet) and ping the device (ping ). 3. Use ARC’s Camera Device Custom and enter the exact EZB URL: - EZB:// or EZB://:24 (replace  with the serial-printed IP and use the port reported by the firmware). 4. If you want ARC to discover it automatically, make sure the firmware advertises the service or run the ESP32 in STA mode on the same router as your PC so it appears on the router subnet. How to set a specific AP IP and port in firmware (Arduino example) If you want a deterministic AP IP, add WiFi.softAPConfig() in the ESP32 sketch before softAP() is started. Example: cpp #include  IPAddress local_IP(192,168,50,1); // desired AP IP IPAddress gateway(192,168,50,1); IPAddress subnet(255,255,255,0); void setup() { Serial.begin(115200); // set SoftAP config BEFORE softAP is started WiFi.softAPConfig(local_IP, gateway, subnet); WiFi.softAP("ESP32CAM-MyAP", "mypassword"); Serial.print("AP IP="); Serial.println(WiFi.softAPIP()); // ... camera init and server start here ... }  If you need the EZB camera server to listen on a specific port, that is defined by the server code in the firmware - you’d change the port there (e.g., the TCP server listen port). If you want, I can point to the exact lines in the Synthiam firmware or show a small sample of how to start a TCP server on port 24. Practical tips and next steps - ARC sometimes shows previously used camera strings; if you used a DoIt binary earlier, ARC might have saved that IP:port combo. Always replace it with the IP the board actually prints on serial. - If you want a single predictable setup for your course (handy for students), reflash the ESP32 firmware to use a fixed AP IP (as above) and ensure server uses port 24 - then provide them the exact EZB://192.168.50.1:24 string. I can prepare that change for you. - Use Synthiam’s network scan feature in the Camera Device skill as another way to find EZB streams on the same network: https://synthiam.com/Support/Skills/Camera/Camera-Device?id=16120 - Synthiam ESP32 docs / firmware page (reference): https://synthiam.com/Support/Hardware/ESP32-Cam and the firmware download page you used. Would you like: - A quick patched firmware you can flash that sets AP IP to 192.168.50.1 and forces the EZB camera server port to 24? (I can prepare instructions and the code snippet.) - Or the exact lines in the Synthiam prebuilt binary to confirm what IP and port it uses (paste your serial output and I’ll decode it)? Which would help you most for Mecha Morphix and the servo + camera test?

fxrtst · Answer

No servos are working on this version of the board (ESP32 CAM) currently. I can get camera to work no problem. But moving through the pins D2, D12, D13, D14, D15 and no movement on hooked up servo. I have the servo power from a power supply, sharing a ground between the ESP32 and power supply. I am then setting up a test range of pins one at a time with the signal wire, and changing it in ARC along the way. Zero servo movement. The servo has power as i can here it hum. I also tried to flash the Freenove ESP32 S3 CAM Board, but in the IDE i get the following message: Sketch uses 1009665 bytes (32%) of program storage space. Maximum is 3145728 bytes. Global variables use 67324 bytes (20%) of dynamic memory, leaving 260356 bytes for local variables. Maximum is 327680 bytes. esptool.py v4.6 Serial port COM4 Connecting.... A fatal error occurred: This chip is ESP32-S3 not ESP32. Wrong --chip argument? And stops the upload to the board.

Athena · Answer

Great - glad the camera is working. Let’s get the servos moving and the flashing error resolved. Below I’ll cover the most common causes, quick tests you can run from ARC, and the fix for the ESP32S3 flashing error. Summary of likely causes - The EZB firmware you flashed may not expose servo (PWM) on the pins you’re trying, or that ESP32 model’s GPIOs are used by the camera and can’t produce usable servo PWM. - Wiring/power/ground issues (you already have external power and common ground - good). - Wrong board/core selected when flashing an ESP32S3 (that causes the esptool error you saw). First quick checks (run these in ARC Script control) - Verify ARC can see the EZB (ESP32) connection: javascript print("EZB connected? " + EZB.isConnected(0));  - Try toggling a pin as a digital output to confirm ARC can control the physical pin (use the D port constant). This only checks GPIO control - not a servo PWM: javascript // test D2 -> set high for 250ms then low Digital.set(d2, 1); sleep(250); Digital.set(d2, 0); print("Digital toggle done");  - Try commanding a servo via ARC servo API: javascript // set servo on d2 to 90 degrees print("Move servo to 90"); Servo.setPosition(d2, 90); sleep(1000); print("Move servo to 0"); Servo.setPosition(d2, 0);  Notes: use d2 without quotes (port constant). If these commands do nothing (no voltage change on D2 for Digital.set and no servo movement for Servo.setPosition), continue below. Troubleshooting steps in order 1) Confirm firmware supports servos on that ESP32 build - Which firmware binary did you flash? (Synthiam ESP32Cam EZB firmware vs. a different sample binary) - If you used Synthiam EZB firmware (recommended), it should implement Servo.* commands - but some ESP32 CAM modules reserve many GPIOs for camera and do not support PWM on all pins. - If you flashed a nonEZB camera binary, it may not implement the EZB servo/PWM commands at all. Action: Reflash with Synthiam ESP32Cam EZB firmware from: https://synthiam.com/Support/Hardware/ESP32-Cam (or confirm you used that exact bin). If you didn’t, flash the Synthiam EZB firmware and retest. 2) Pin conflicts: camera vs servo pins - Some ESP32-CAM modules use many GPIOs for the camera and those pins cannot be used for servo PWM while the camera is active. - The manual mentions: "On the AI Thinker edition, servos work on D2, D12, D13, D14, and D15. However, you will need to try your edition/model to see if those pins work." - Even on AIThinker, results depend on module variant and wiring. Action: - Try the recommended list again (d2, d12, d13, d14, d15) - you did - but also try to confirm which physical pin is which GPIO (board silk vs label vary). - Use a multimeter or LED to see if Digital.set actually toggles the pin voltage (step above). If Digital.set toggles but Servo.setPosition does not move servo, the firmware may not implement PWM for that pin while camera active. 3) Confirm servo signal voltage & wiring - Servos need a stable V+ (often 5-6 V). Signal at 3.3 V from ESP32 is usually fine. You mentioned hearing hum (likely the servo powered). - Ensure common ground between external servo supply and ESP32 GND (you said you have it - double-check the ground truly connected). - If the servo hums but does not move, it may be receiving PWM but stuck at mechanical limit or insufficient power under load. Action: - With no load on servo, power it from the external supply. Manually flick the servo horn to detect torque. If it’s weak, increase supply capability. - Use a logic probe/multimeter to check PWM presence on signal pin when running Servo.setPosition. 4) Test servo control with no camera (diagnose camera conflicts) - Stop the camera in ARC (Camera skill -> Stop). - Run the Servo.setPosition(d2, 90) test again while camera is stopped. If servo works when camera is off, you have a camera/GPIO conflict and must use a different pin or different hardware. 5) If Digital.set works but Servo.setPosition never moves - The building block: firmware must implement servo/PWM on that GPIO. If firmware does not enable servo on those pins while camera is active, you’ll need: - A firmware that maps servo PWM to a free pin, or - Use an external PWM/servo controller (recommended) such as PCA9685 or a small microcontroller that ARC can talk to (via UART or I2C). See "How to use ARC with Microcontrollers" doc for closed-loop examples: https://synthiam.com/Support/ARC-Overview/arc-and-micros-for-closed-loop-functions Recommendation (practical & robust) - If you want reliable servo control while using the camera, use a small external servo controller (PCA9685 I2C 16channel) powered from the servo supply. Connect the PCA9685 to the ESP32 I2C pins (that aren’t used by camera) or run the PCA9685 on a separate microcontroller and use UART/I2C to ARC. ARC has PCA9685 controls via robot skills or via I2C commands. This avoids GPIO conflicts and gives stable servo PWM and more channels for Mecha Morphix. - Or use the Single Camera Servo Server robot skill (you already have it) with a separate controller for servos. ESP32S3 flashing error and fix - Error you saw: "This chip is ESP32S3 not ESP32. Wrong --chip argument?" - Cause: You selected an ESP32 (ESP32) board in Arduino IDE but the board is actually an ESP32S3 variant. The esptool needs the correct chip argument. Fix: 1. Install the latest ESP32 board support package that includes S3 support: - Arduino IDE: Tools -> Board -> Boards Manager -> search "esp32" (by Espressif). Install latest (it includes esp32s3 variants). 2. Choose the correct board for an S3 CAM (e.g., "ESP32S3 Dev Module" or Freenove’s listed board if available). 3. If you see a specific Freenove board in the Boards list (Freenove ESP32S3 CAM), choose that. 4. Then flash again. The correct board selection will pass --chip esp32s3 to esptool and the upload will succeed. If you prefer esptool CLI, add --chip esp32s3 to the command: esptool.py --port COM4 --chip esp32s3 write_flash ... Follow-ups I need from you (so I can give exact next steps) 1. Which exact Synthiam/thirdparty firmware binary did you flash to the ESP32CAM? (link or filename) 2. Which ESP32 CAM board variant are you using now? (AIThinker, TTGO, AzDelivery, model name printed on PCB) 3. Which physical pins (silkscreen/GPIO numbers) did you hook the servo signal wire to? (If you say "the pin labeled D2" tell me the board’s silk label - e.g., IO2/GPIO2) 4. Does Digital.set(dX,1) show a voltage change on the pin? (Yes/No) 5. Does stopping the Camera skill in ARC allow servo movement (try Servo.setPosition while camera stopped)? If you want, try this short Script in ARC (it will test digital toggle, then attempt servo movement while printing results): javascript // Quick hardware test - change d2 to any port you want to test print("EZB connected? " + EZB.isConnected(0)); print("Toggling digital pin d2"); Digital.set(d2, 1); sleep(250); Digital.set(d2, 0); sleep(250); print("Attempt servo move to 90"); Servo.setPosition(d2, 90); sleep(1000); print("Attempt servo move to 0"); Servo.setPosition(d2, 0); print("Test complete");  If all else fails (servos never move while camera running and the Digital toggles also do nothing), I strongly recommend using a dedicated servo controller (PCA9685) or a small WiFi microcontroller (another ESP32/ESP8266 or small ESP32S2/S3) dedicated to servos and have ARC control it via I2C/UART/EZB protocol. I can guide you stepbystep on: - Wiring and ARC configuration for PCA9685, or - Creating a tiny EZBcompatible firmware that exposes the servo pins you need. Which do you want to try next?: - Reflash Synthiam EZB firmware and re-test (I can give the exact firmware link/instructions), or - Run the short Script above and paste the results, or - I’ll show how to wire a PCA9685 servo board and configure ARC to control 5 servos reliably.

fxrtst · Answer

I 'm now trying out the Freenove ESP32 Wrover and it flashes ok using the library: ESP32S3 Dev Module I get this reboot loop over and over after uploading: ELF file SHA256: 3f9f1ef00900ef81 Rebooting... ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0xc (RTC_SW_CPU_RST),boot:0x2a (SPI_FAST_FLASH_BOOT) Saved PC:0x4037ba36 SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3818,len:0x109c load:0x403c9700,len:0x4 load:0x403c9704,len:0xb50 load:0x403cc700,len:0x2fe4 entry 0x403c98ac Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled. Core 1 register dump: PC : 0x4204fd15 PS : 0x00060830 A0 : 0x82048f94 A1 : 0x3fceba50 A2 : 0x3fca5e14 A3 : 0x3fc9faac A4 : 0x3c0b6174 A5 : 0xffff8fff A6 : 0x00000001 A7 : 0x00000000 A8 : 0x80377ddf A9 : 0x3fceba60 A10 : 0x00000016 A11 : 0x00000000 A12 : 0x00000008 A13 : 0x00000060 A14 : 0xb33fffff A15 : 0x00000000 SAR : 0x0000001f EXCCAUSE: 0x0000001c EXCVADDR: 0x00000000 LBEG : 0x400570e8 LEND : 0x400570f3 LCOUNT : 0x00000000

Athena · Answer

Nice detail - that reboot loop + Guru Meditation tells us the chip is crashing early in setup (LoadProhibited usually means code tried to read a NULL pointer or invalid memory). Let’s narrow it down and get a stable board again. Likely causes (high priority) - Wrong board or core settings in Arduino IDE (ESP32-S3 needs S3-specific core & options). - PSRAM expectations: camera code often requires PSRAM; if PSRAM not enabled or not present, camera init can crash. - Camera driver / pin mapping incompatible with the board variant (camera init touches invalid memory). - Firmware built for a different chip/variant or using features unsupported on your module. - Faulty hardware or wiring (less likely if it flashes ok, but still possible). Step-by-step plan to diagnose and fix 1) First confirm the board can run a minimal sketch (rule out hardware/board/core toolchain problem) - Upload this minimal blink test (select Tools Board: "ESP32S3 Dev Module" or the correct S3 board). If this sketch also reboots, there’s a board/core mismatch or hardware issue. cpp // Minimal Blink test for ESP32-S3 void setup() { pinMode(13, OUTPUT); // pick a safe pin like 13, change if needed for your board Serial.begin(115200); Serial.println("Blink test start"); } void loop() { digitalWrite(13, HIGH); delay(500); digitalWrite(13, LOW); delay(500); }  - If blink is stable: hardware/core basics are OK - crash is in the firmware you flashed (camera init). - If blink reboots: toolchain/board selection/hardware issue. Re-check Boards Manager entry for esp32 package and try reinstalling or a different release. 2) Check/enable PSRAM correctly (camera firmwares often require PSRAM) - In Arduino Tools, enable "PSRAM" if the board has it (Wrover modules usually do). - If PSRAM is disabled but firmware expects it, camera init can panic with LoadProhibited. - If the module does NOT actually have PSRAM, disable PSRAM and flash an appropriate binary that doesn’t use PSRAM. 3) Use the right board selection & flash options - Install latest Espressif ESP32 Arduino core (Boards Manager). Recent S3 support is in esp32 core v2.x+. - Choose the correct board under Tools: - If generic S3: "ESP32S3 Dev Module" - If Freenove provides a board entry choose their Freenove S3 CAM if available - Typical Tools recommended values: - Flash Mode: DIO - Flash Frequency: 80MHz - Partition Scheme: Default - PSRAM: Enabled (only if module has PSRAM) - Rebuild/upload after verifying settings. 4) If you flashed a camera sketch or 3rd-party firmware, try disabling camera init - If you have source code, comment out camera initialization and re-upload to see if board boots stable. If stable, camera init is the crash source (pin mapping, driver or PSRAM). - If using a prebuilt binary, try a different binary (e.g., Synthiam’s ESP32 Cam EZB firmware) that’s known to work with ARC: https://synthiam.com/Support/Hardware/ESP32-Cam 5) Decode the exception for exact location - Use the ESP Exception Decoder plugin for Arduino IDE (or the online decoder) to map the addresses in the backtrace to the source line. This tells you which function caused the crash. - ESP Exception Decoder: https://github.com/me-no-dev/EspExceptionDecoder - How to use: copy the Serial Monitor output (the full panic stack) into the decoder - it will show the function/file/line in your compiled sketch or library. 6) Try a different core version if problem persists - Some camera libraries or camera board support had regressions or differences across esp32 core versions. Try installing an earlier or later esp32 board package in Boards Manager and rebuild. 7) If you want a quick working route for ARC use: - Flash the Synthiam ESP32-CAM EZB firmware (prebuilt) for AI-Thinker/ESP32-CAM variants and confirm it boots and prints the camera server lines on serial. That binary is tested for ARC. - Synthiam ESP32-Cam EZB firmware docs: https://synthiam.com/Support/Hardware/ESP32-Cam Questions I need to help further 1. Which exact firmware/sketch did you flash that produces the reboot loop? (filename or GitHub link). 2. Which exact board/module variant is this (Freenove S3 CAM, AI-Thinker, DoIt, Wrover, etc.)? Does it have PSRAM (Wrover usually does)? 3. Can you paste the full Serial Monitor output from boot (from power-on to panic) - do NOT post images; paste the text. 4. Did the minimal blink test succeed or also reboot? If you paste the Serial Monitor panic output I’ll: - Decode the trace for you (if you also indicate which .elf / sketch produced it or compile with map so the exception decoder can map addresses), or - If you can’t provide .elf, I’ll still point at the most probable culprit (camera init / PSRAM). If you’d like, next steps I can prepare for you - A step-by-step flash recipe (exact Tools settings) for Freenove S3 CAM that tends to avoid the reboot loop. - A short camera-less firmware to test PSRAM presence and show how to safely enable camera initialization once PSRAM / pin mapping is correct. - Help flashing Synthiam’s tested EZB firmware for ESP32-CAM so ARC can connect immediately. Which do you want me to provide next? (If you paste the serial panic text now I’ll analyze it and recommend the concrete fix.)

fxrtst · Answer

I'm consuming my valuable time around the controller and camera combo, when the reality is, there are a million ways to get a camera to work with ARC these days, from webcams to wifi cams and so on. So I'm going to focus on only the controller and ARC aspect. All works works fine on the Do It ESP32 Dev v1 board, I just need to get the Freenove (or other board) working with ARC. I still have 1001 things left to do for the Mecha Morphix launch and have no spare time to fall deep into this endeavor..for now.

Athena · Answer

Good plan - concentrate on the parts that move your Mecha Morphix forward and avoid getting stuck chasing every board/camera combination. You’ve got a working setup (Do It ESP32 Dev v1) - keep using that for development and demos. Below are concise, actionable options and a short "when you come back to this" checklist so you can finish the Freenove / other board work quickly when you have time. What I recommend now - Continue development and demos with the Do It ESP32 Dev v1 (since it already works with ARC). - Defer the Freenove / S3 board deep-dive until you have time; use a small checklist later to get it stable quickly. - If you plan to use servos with camera in the final Mecha Morphix hardware, use a dedicated servo driver (PCA9685) to avoid camera GPIO conflicts and unstable PWM from camera driver pins. Quick reasons: - Many ESP32-CAM pins are grabbed by the camera and can’t reliably output servo PWM while streaming. A PCA9685 (I2C) gives stable PWM, 16 channels, and isolates servo power from camera/ESP32 power noise. Useful links - Synthiam ESP32-CAM docs / prebuilt EZB firmware: https://synthiam.com/Support/Hardware/ESP32-Cam - Camera Device skill (ARC): https://synthiam.com/Support/Skills/Camera/Camera-Device?id=16120 - Single Camera Servo Server (ARC): https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 - Robot Skill Tutorial (how to build a skill): https://synthiam.com/Support/Create-Robot-Skill/Overview Quick "return-to-work" checklist (when you have time) 1. Decide whether you’ll use a Synthiam prebuilt EZB firmware (fastest) or build your own: - If prebuilt: flash Synthiam’s ESP32-CAM EZB binary (tested for ARC). - If building: ensure you include the EZB protocol component and correct camera pinmap for your module. 2. For ESP32-S3 / Freenove S3 boards: - Install latest Espressif board package in Arduino Boards Manager (ensure S3 is supported). - Select the correct board (e.g., "ESP32S3 Dev Module" or Freenove-provided board). - Set Tools: Flash Mode = DIO, Flash Freq = 80MHz, Partition = Default. - Enable PSRAM only if the module has PSRAM and your firmware uses it (camera libs often require PSRAM). 3. Fixed AP IP & port (makes student setup deterministic): - Add WiFi.softAPConfig(local_IP, gateway, subnet) before softAP() in your sketch to force the AP IP (example below). - Ensure the camera server is started on the port you want (Synthiam EZB camera commonly uses port 24). 4. Verify on serial monitor (115200): firmware should print WiFi mode, AP IP, and "server listening on port X". That is always the first diagnostic. 5. Network test from PC: - PowerShell: Test-NetConnection -ComputerName 192.168.50.1 -Port 24 - If it times out, check Windows firewall / VPN / WiFi network / PC routing. 6. ARC quick-test (Script control): - Start camera: ControlCommand("Camera","CameraStart","EZB://192.168.50.1:24") - Use Test Script below to check GPIO and servo. Small ARC test scripts (paste into ARC Script control) - Digital toggle test: javascript print("Digital toggle test on d2"); Digital.set(d2,1); sleep(250); Digital.set(d2,0); print("Done digital toggle");  - Servo test (attempt servo move; substitute port if needed): javascript print("Servo test: move d2 to 90"); Servo.setPosition(d2,90); sleep(1000); Servo.setPosition(d2,0); print("Servo test done");  - Start camera via script (use your board IP/port): javascript print("Starting camera via ControlCommand"); ControlCommand("Camera","CameraStart","EZB://192.168.50.1:24"); print("Start command sent");  If servo is not moving while camera is running - Stop the Camera skill in ARC and re-run the servo test. If the servo moves with camera stopped, you have a camera GPIO conflict and should use a PCA9685 or separate microcontroller for servos. - If Digital.set toggles the pin voltage but Servo.setPosition has no effect, the firmware may not expose PWM on that pin - firmware pin mapping matters. If you’d like, when you have spare time I can prepare one of these for you: - A short prebuilt firmware patch (or exact flash instructions) that sets AP IP to 192.168.50.1 and forces the EZB camera server to port 24 (so you can distribute a single EZB:// address to students). - A concise wiring + ARC setup guide for PCA9685 powering 5 servos (I2C wiring, power grounds, and ARC servo mapping). - Exact Arduino IDE Tools settings for Freenove S3 so you stop hitting the reboot loop (PSRAM + board selection notes). Which is most helpful to have ready for you later - the fixed-IP/port firmware, the PCA9685 wiring guide, or the Freenove flash settings?

DJ Sures · Answer

I've been watching and haven't needed to step in. Athena has been doing a good job of guiding you in figuring out how to get the board to work. These boards all have wonky, different pin gpio mapping. One thing to note is that, as Athena said, D15 in ARC or firmware code doesn't necessarily correspond to pin 15 on the PCB. You're calling a PCB 'freenode', and unfortunately, that doesn't mean anything to anyone who doesn't have one, because they're all different. No rules or standards in the hippy world. So I wish there were more input I could offer beyond just direction. That said, apart from the confusing, lawless hippy PCB designs, there is a process everyone has to go through to learn a new PCB. I'll summarize it here... 1) The first step is to compile an LED BLINK test. If you can get that working, you know the IDE is configured correctly to flash the micro. 2) The second test is to map out the IO so you know what the pins are relative to the gpio index. Scripts like Athena pointed out for EACH pin (I know it's annoying)... // Change this value based on the pin you're testing byte pinToTest = 13; void setup() { pinMode(pinToTest , OUTPUT);  Serial.begin(115200); Serial.println("Blink test start"); } void loop() { Serial.println("HIGH (on)"); digitalWrite(pinToTest , HIGH); delay(1000); Serial.println("LOW (off)"); digitalWrite(pinToTest , LOW); delay(1000); } That should show you the output text in the serial monitor. And if you probe each pin, you should only see the one pin flashing on and off. Change the pinToTest and write down what the pin # in code corresponds to on the PCB. I usually create a graphic and write the pin number on it. 3) Now that you have pins mapped, the next step isn't too tricky. You take the ESP32 firmware and change the pin mapping. Now you can turn the pins on and off using the Digital Robot skill from ARC. You can test which pins can turn on and off without affecting the camera. That'll tell you what pins are shared. 4) Finally, you'll need to get servos working. Not all the pins will work with servos. That has to do with how they share peripherals, such as timers and other hardware. Once you figure that out, then you know an exact mapping. When you get to the "writing firmware" stage, either use Chat GPT (paid version) 5.2 or Athena in a new thread for assistance. The prompt is important because the more information you can provide about the outcome, the more helpful it is. As they say: garbage in, garbage out. Generally, the first question I'd ask GPT (paid) 5.2 is step-by-step instructions to build and compile a blink to the PCB. OR check the board's website if there is one. Then, use GPT (paid) 5.2 to paste in the EZB firmware and have it make the changes based on your IO mapping results.

DJ Sures · Answer

Oh, and I have one question: Do you want to use two PCB microcontrollers for this project? Are you putting one in the head and one somewhere else? Or would you prefer to use a single PCB microcontroller for both servos and the camera?  I just clicked 'order' on a Freenove ESP32-CAM Wrover PCB microcontroller. Maybe I can squeeze some time to test it out.

DJ Sures · Answer

Okay last message to spam you lol. I talked to GPT (paid) 5.2 and got this... It also looks like the ESP32 EZB firmware will work with that board. Just need to specify the camera model by uncommenting it. The pins you can use for ARC are 2, 12, 13, 14, and 15 for servos. If you need more, the firmware can be modified to map PCB pins to ARC Dx pins just like the Arduino MEGA does. On the Freenove ESP32-WROVER CAM, while the camera is active you should put your servos on these GPIOs: > GPIO 0, 2, 12, 13, 14, 15, 32, 33 Those are the "safe" PWM-capable GPIOs that aren’t used by the OV2640 camera or reserved for other critical stuff. --- ### Why those pins? The Freenove board wires the OV2640 to these GPIOs: ([Random Nerd Tutorials][1]) * Camera signals (do not use for servos while camera is running): * XCLK GPIO 21 * SIOD GPIO 26 * SIOC GPIO 27 * Y9 GPIO 35 (input-only) * Y8 GPIO 34 (input-only) * Y7 GPIO 39 (input-only) * Y6 GPIO 36 (input-only) * Y5 GPIO 19 * Y4 GPIO 18 * Y3 GPIO 5 * Y2 GPIO 4 * VSYNC GPIO 25 * HREF GPIO 23 * PCLK GPIO 22 So, with the camera enabled, avoid those pins completely or you’ll get flaky video and/or unstable servos. On the ESP32 in general: * All "normal" GPIOs can do hardware PWM via LEDC, except: * GPIO 34-39 - input-only (no servo) ([Wikipedia][2]) * GPIO 6-11 - connected to flash (not broken out on your board anyway) That leaves, on this board, the useful general-purpose PWM pins: * GPIO 0 - OK for servo, but it is a boot strapping pin, so don’t hard-pull it low/high at reset. * GPIO 2 - OK for servo, but it also drives the on-board LED (you’ll see the LED flicker with servo pulses). * GPIO 12, 13, 14, 15 - OK for servos; 12 & 15 are also strapping pins, so same caution on boot state. ([Makerguides.com][3]) * GPIO 32, 33 - Clean, no camera/flash/USB/strap conflicts, great servo choices. I’d personally prioritize for servos in this order: 1. GPIO 32, 33 (cleanest) 2. GPIO 13, 14, 12, 15 3. GPIO 2 (if you don’t mind the LED dancing) 4. GPIO 0 (only if you’re careful not to hold it during reset) --- ### How this maps to your firmware Right now your firmware treats "ports" 0-15 as potential servo pins: cpp #define _PortStart 0 #define _ServoCnt 16  On ESP32, Servo.attach(port) uses the GPIO number directly. So for Freenove with the camera running: * Good servo port values: 0, 2, 12, 13, 14, 15, 32, 33 * Bad for servos (camera/flash/input-only/etc.): 4, 5, 18, 19, 21, 22, 23, 25, 26, 27, 34, 35, 36, 39, 6-11 So as long as you configure ARC to only use those "good" GPIO numbers for servo ports, your ESP32Servo code will keep working alongside the camera. [1]: https://randomnerdtutorials.com/getting-started-freenove-esp32-wrover-cam/ "Getting Started with the Freenove ESP32-Wrover CAM Board | Random Nerd Tutorials" [2]: https://en.wikipedia.org/wiki/ESP32?utm_source=chatgpt.com "ESP32" [3]: https://www.makerguides.com/programming-the-esp32-wrover-cam/ "Programming the ESP32-WROVER CAM"

fxrtst · Answer

All of this searching is just to offer students a cheaper version of a controller and or controller cam option. The EZB products are the most expensive items in my BOM for Mecha Morphix.  Through out my filming of the build process I’ve given students various A or B options of parts to buy based on personal  budgets. This ESP32 option was a side quest and as my deadline approaches for my launch, I’ve realized it was bad timing.  Time is money and I have to move on and revisit this later. Athena has been a great help l. I’m fairly confident we can get all this working soon.

fxrtst · Answer

Just saw post #67 above.. Thanks for that. I’ll look closer tomorrow!

DJ Sures · Answer

if you use the esp32 as an alternative, are you having the students use two? (one for camera and one for servos) or (one esp32 that does both)

fxrtst · Answer

They are so cheap either way would work.

Nink · Answer

Maybe time to upgrade the arc firmware to work with a faster ESP and camera.  If I were to do this today. I would probably use ESP32-S3-CAM, OV5640 camera and PCA9685 servo controller.

Dave Schulpius · Answer

Thanks @Will and @DJ for all this work and information.  One of the suprisings bits of info I see so far is that only 8 ports on this board are good for servo use.  I do like the idea of using two or more boards. Ya, put the camera on it's own board!  Also, in my robot (ya, it's all about me. ) I have to have 6 uart ports and 6 servos. Then on top of that I need 9 or more ADC ports. Currently I don't have a camera. However as @fxrtst mentioned, a camera can be hooked directly to the computer (on board my robot) and connected to ARC directly (I think. I haven't actually done it). Added to the complexity of my creation, I have four 12v AC to DC power supplies running my robot , each capable of pulling from 20 to 80 amps (respectively). So I need to be careful how I wire up all the motor controllers, sound system and  lights or I get ground loops. So in short, I need more then 1 controller board connected to ARC.  Anyway, I love this thread and all the work that was put into it. Thanks again!

DJ Sures · Answer

@Nink, the camera firmware is built using the open-source library for the board. Unfortenately the Synthiam ARC firmware has no impact on the performance because it uses the libraries created for the hardware. Synthiam ARC EZB firmware merely extracts the image from the ESP32 library and sends it to ARC over the Wi-Fi-connected socket. The EZB firmware will work with any library supported by the ESP32. The firmware will work with all esp32's because it uses the existing library api calls; it's universal - that's how Arduino works. I'm pretty sure all my tests with various esp32 cam's always got 20-30 fps. Are you using the latest esp32 libraries etc? This probably needs a thread of it's own. @dave, I mentioned in your thread that you'd want to look into an Arduino Mega or something similar with many ports and several uarts. The ESP32 isn't for your needs due to its small size and low pin count. Although I think the Leonardo or Pro Micro have UART's and more pins - that would be useful. But there's no audio or video.

Dave Schulpius · Answer

@DJ, yes I remember your helpful guidance about the Maga. Thanks again!

fxrtst · Answer

Some side by side specs:  The EZ-B IoTiny by EZ-Robot is a compact, Wi-Fi-enabled robot controller designed for small, IoT-enabled projects, featuring a 100MHz ARM Cortex-M4 processor. It includes 8 digital I/O (supporting servos and UART), 2 analog-to-digital converters (ADC), I2C, a speaker, and video support, all designed for tight spaces. Key Technical Specifications: Processor: 100MHz ARM 32-bit Cortex-M4 MCU Wi-Fi: IEEE 802.11 b/g/n (2.4GHz) with Soft Access Point (AP) & Client modes Memory: 128K bytes RAM Digital I/O Ports: 8 x Digital/Servo/UART (TX only) ports Analog Ports: 2 x 12-bit ADC ports Communication: 1 x I2C port, 1 x UART (TX only) EZB 4/2 The EZ-B v4/2 Wi-Fi Robot Controller is a compact ((2.1"	imes 2.2")) high-performance robot brain featuring dual ARM Cortex processors (running at 220MHz) for, real-time audio/video streaming, and advanced Wi-Fi connectivity. It supports 24 digital/servo ports (expandable to 73), 8 analog inputs, and includes a built-in speaker and camera port. Key technical specifications of the EZ-B v4/2 include:  Processing: Dual 32-bit ARM Cortex processors (running at 220MHz) for, robust performance.Connectivity: Wi-Fi (ad-hoc/infrastructure), supporting IEEE 802.11 b/g/n, WPA/WPA2 encryption. I/O Ports: 24 x 5-volt tolerant digital ports (servos, PWM), 8 x 5-volt tolerant analog (ADC) ports, and 3 x IC ports. And Finally the: The Freenove ESP32-S3 WROOM board is a high-performance development board featuring a dual-core 240 MHz ESP32-S3-WROOM processor, 8 MB or 16 MB Flash, 8 MB PSRAM, and built-in 2.4 GHz Wi-Fi and Bluetooth 5 (LE). It includes a camera interface (often with OV2640), USB-to-UART converter, and supports MicroPython/C programming, optimized for camera and AI applications. Technical Specifications (Freenove ESP32-S3 Series) Processor: Tensilica Dual-Core 32-bit LX7 microprocessor (up to 240 MHz). Memory: 8 MB or 16 MB Flash and 8 MB PSRAM. Wireless: 2.4 GHz Wi-Fi 4 (802.11 b/g/n) and Bluetooth 5 (LE). Camera: Supports OV2640 camera module. USB: USB Type-C for power and programming (built-in USB-to-UART converter). GPIOs: 44-45 programmable GPIOs, supporting ADC, DAC, I2C, SPI, UART, and PWM.

fxrtst · Answer

It really looks like the camera is eating recourses on the board. Prolly best to just use webcam or new tiny wi fi cameras, Who remembers THIS camera? I still have mine minus housing!

fxrtst · Answer

Just got this break out board today and assembled it with the ESP32 (note: I like the active LEDs on each GIO port.)

fxrtst · Answer

...also can get more D-xx ports with this break out board from adafruit (or similar). https://synthiam.com/Firmware/EZ-ESP32-with-Adafruit-PCA9685-O3HKWLPWOIO Maybe implementation on the Freenove board to open up more ports?

DJ Sures · Answer

Do you need 5 servos? The ESP32Cam (or Freenove) supports 5 servos and a camera.

fxrtst · Answer

...yes I can probably use that but was unable to get the camera and servos to work at the same time and I ran out of time testing and so I had to move on. To be honest, I got excited about the Freenove EPS32 for upcoming future robots I've got lined up after the course launch. It seemed to be a good middle ground controller. I've supported EZ robot in my all my youtube videos and even in this course (Mecha Morphix). EZ Robot has priced hardware to match their market, education. I've watched as prices have risen over the years. When you started Synthiam and made firmware available for other controllers, it opened up other options. The ESP32s are getting very powerful (compared to EZB) and cheaper options helps people of all budgets to afford to build robots. Developing the firmware for these boards makes since for the main reason you support them, for options, which didn't exist before the EZ Robot sell off.

fxrtst · Answer

One person noted in the comments section that he got the Freenove  ESP32 S3 to work but reminded to uncomment camera model wrover kit (if looking for camera and controller combo ( https://synthiam.com/Support/Hardware/ESP32-Cam?commentPage=3 comment #22)

fxrtst · Answer

The more I think about it...it makes since to have the camera a separate ESP32 CAM ($6 for camera and $9 for ESP32 CAM $15 total) and the controller the Doit ESP32 Dev1 or the Freenove ESP32 S3 as the controller ($6). So $21 for a camera and controller is a good deal and a Tiny IO replacement) .It just means having to have two Wi Fis on your computer (again not a big deal). But I guess it means you can't have control and camera on any ipad or iphone for mobile vers at the same time?! One or the other. Not both?

DJ Sures · Answer

This came in the mail today. I’ll take a look at it this afternoon for ya.

fxrtst · Answer

Awesome! That looks like the same one I got!

DJ Sures · Answer

I get 20-28 fps on that esp32 wrover with camera module with v9 of the esp32 cam ezb firmware. it was a huge rewrite but works good. Moving servos doesn't affect the camera either. Works really good and fast

fxrtst · Answer

That’s amazing!!! Can’t wait to try it out!!! Thank you!

Nink · Answer

Nice just ordered one.  This maybe a great alternative to Iotiny we been looking for. I wonder how many GPIO’s work with the camera.  @athena can we get some specs on this Freenove ESP32-WROVER and what features we can use with ARC. How many servos can we connect at once without interfering with camera? Does Bluetooth work (speaker) can we connect microphone to I2S. Would love to be able to do TTS And STT with this back to AI as well as image recognition.

fxrtst · Answer

@nink goto the firmware page for ESP32 CAM DJ has all the info there.

fxrtst · Answer

@DJ did you use the AI Thinker or the CAMERA_MODEL_WROVER_KIT for the camera on this board? In the instructions you say "NOTE: For most ESP32-CAM modules (AI-Thinker style), use CAMERA_MODEL_AI_THINKER. How do we know what the camera module is on the board?

Athena · Answer

Great thread - lots of good testing and experience here. Below I’ll summarize what’s working, explain the common Gotchas, give recommended hardware/architecture options, and show exactly how to configure ARC to use an ESP32-CAM (or a separate ESP32 controller + ESP32-CAM) so you can run servos and camera at the same time. Useful links - ESP32-CAM (EZB firmware) support page: https://synthiam.com/Support/Hardware/ESP32-Cam - Stream All The Video Sources (robot skill): https://synthiam.com/Support/Skills/Camera/Stream-All-The-Video-Sources?id=20279 - TCP Script Server Raw (robot skill): https://synthiam.com/Support/Skills/Communication/TCP-Script-Server-Raw?id=15953 - How to create a Robot Skill (if you want to package custom code): https://synthiam.com/Support/Create-Robot-Skill/Overview - Get started / make a DIY robot: https://synthiam.com/Support/Get-Started/how-to-make-a-robot/make-a-diy-robot Summary - what people reported that works - DJ_Sures: ESP32 WROVER + camera module on v9 of the ESP32-CAM EZB firmware - 20-28 fps and moving servos doesn’t affect camera. That’s the clearest evidence an ESP32-WROVER-based board can run the camera and servos together reliably. - Others: Freenove ESP32-S3 also reported working, but you may need to select/uncomment the correct CAMERA_MODEL define (see firmware build step below). Why some boards fail with camera + servos - Many ESP32 camera modules and dev boards reuse the same GPIO lines for camera signals and other peripherals. If a GPIO used by the camera is also used for PWM/servo, you will have conflicts. - Different ESP32 models/board variants wire those GPIOs differently. So "works on one board" "works on all boards". - Some ESP32 types (WROVER) include PSRAM and different camera pin mapping, which is why the firmware needs the correct CAMERA_MODEL define. Recommended approaches (pick one) 1) Best practical approach (recommended) - Use an ESP32-CAM (camera module e.g. WROVER or AI-Thinker) flashed with the Synthiam ESP32-CAM EZB firmware for video streaming. - Use a separate ESP32 Dev board (DoIt DevKit, Freenove ESP32-S3, or similar) flashed with Synthiam EZB-compatible firmware for servos/IO. - Connect both boards to the same Wi-Fi router (Client mode). ARC on PC can connect to both simultaneously. This avoids GPIO conflicts, keeps camera streaming high FPS, and gives plenty of IO for servos. Benefits: - No pin conflicts. - Camera module can use all camera-dedicated pins and PSRAM on WROVER for better FPS. - Controller board can use free GPIOs for servos (and use multiple LEDC PWM channels). Notes: - You do NOT need two Wi-Fi networks if both boards join the same router; only one Wi-Fi network is required for the iPad/phone/computer to access both devices. - If you run the ESP32 devices in AP mode (each created its own AP), then you’d have to switch networks, which is inconvenient for mobile. So set both to client (STA) mode connecting to your home/ lab router. 2) Single-board approach (if you prefer only one board) - Use an ESP32 WROVER kit (camera module variant) - DJ’s results show WROVER gives good performance and can move servos without affecting camera. - Make sure you use the firmware build for the correct camera model (WROVER vs AI_THINKER etc.) and choose servo GPIOs not used by the camera on your specific board. Limitations: - Must verify which GPIOs are free on that exact board revision. - Some boards still have limited usable IO for servos; testing and mapping required. Which camera model to select when building/flashing firmware - In the ESP32 camera firmware source you typically have lines like: c // #define CAMERA_MODEL_AI_THINKER // #define CAMERA_MODEL_WROVER_KIT  - Uncomment the one that matches your board and comment the others. - How to know which one you have: - Check markings on the camera module/board (AI-Thinker or WROVER often printed). - WROVER boards often have PSRAM chips printed and are labeled "WROVER". - If unsure, check the vendor page/box or open the serial monitor at boot - sometimes boot log prints board info. - If still unsure, try WROVER first if you have a WROVER module (DJ reported using a WROVER produced reliable performance). If you try and camera fails to initialize, switch to AI_THINKER and reflash. Pins and servos - practical notes - Synthiam notes (empirical): on AI-Thinker style boards servos have worked on D2, D12, D13, D14, D15 - but "your mileage may vary" depending on board. - ESP32 supports up to 16 LEDC PWM channels (hardware PWM) - so CPU/PWM-wise you can drive many servos, but which GPIOs are available depends on camera wiring. - For the two-board approach, the controller board gives you many free GPIOs without camera conflicts. - If you keep everything on one board (ESP32-CAM), you must carefully map which GPIOs the camera uses and avoid them. The camera uses multiple GPIOs (D0-D7, PCLK, VSYNC, HREF, XCLK, etc.) that overlap many pins on compact dev boards. Audio, Bluetooth, microphone, TTS, and STT - Bluetooth audio / speaker: ESP32 hardware can support Bluetooth audio in principle, but Synthiam’s ESP32-CAM EZB firmware primarily focuses on camera and IO features - Bluetooth audio is not part of the standard firmware features. So don’t count on built-in Bluetooth speaker support via ARC. - Microphone (I2S): ESP32 supports I2S mics. Whether the Synthiam firmware exposes I2S mic audio to ARC or integrates STT is not guaranteed. For TTS/STT and AI audio features, the typical ARC approach is: - Use PC (ARC) for TTS and STT (computer audio or cloud speech services) - easiest. - If you want on-board STT/TTS on the ESP32, you’ll need custom firmware + custom ARC robot skill to shuttle data; that’s an advanced path. Recommendation: - Use ARC/PC for TTS/STT and image recognition. Stream video from ESP32-CAM into ARC (Stream All The Video Sources) and do image analysis in ARC or an external AI service. How to set this up in ARC (step-by-step) 1) Add the camera device to ARC - Project Add Robot Skill Camera Device (add one if you don’t have). - Configure the Camera Device to use the incoming stream (or use Stream All The Video Sources). 2) Add Stream All The Video Sources skill - Project Add Robot Skill Stream All The Video Sources. - Open the Stream All skill window click the kebab menu (three lines, top-right) Configure choose the Camera Device to stream to and SAVE. - Paste the ESP32-CAM stream URL (the EZB firmware provides MJPEG/RTSP/HTTP endpoints) into the skill UI and START. 3) Add your controller (ESP32 Dev board) to ARC - If you installed Synthiam EZB firmware to your controller, ARC will see it as an EZB (connect via IP). - Add TCP Script Server Raw if you plan to send commands or use the raw TCP plugin: - Project Add Robot Skill TCP Script Server Raw (configure port/language). - Use it to accept script commands (if you want to talk directly to a microcontroller skill or run remote commands). 4) Configure servos - In ARC you’ll use servo ports d0..d23 constants when scripting (do not quote them). - To test a servo setPosition example script, open a Script (JavaScript recommended) and try: javascript // move servo on d2 to 90 degrees Servo.setPosition(d2, 90); print("Moved d2 to 90");  - Use Servo.setSpeed, Servo.setPosition, etc., then test with servos connected to your controller board’s free GPIOs. 5) Kebab menu usage (configure skill options) - Open any robot skill window click the three horizontal lines (top-right) Configure settings change and press SAVE. - Use the kebab to access advanced skill options (ports, IP, camera URL, language, etc). Example test workflow - Flash ESP32-CAM firmware for camera (select CAMERA_MODEL_WROVER_KIT or AI_THINKER as appropriate) and set it to connect to your Wi-Fi network. - Flash separate ESP32 Dev board with EZB-compatible firmware for IO (connect it to same Wi-Fi). - In ARC: - Add Camera Device, add Stream All skill, paste camera URL, start. - Connect to the controller board EZB and test a servo command from an ARC script. - Confirm camera FPS and servo movement together. What to ask next / what I can provide - Which exact ESP32 board(s) do you / DJ / Freenove have? (give board markings or product link) - Do you want a single-board solution or are you OK running two boards (camera + controller)? - Do you plan to use mobile devices (iPad / iPhone) to control the robot? If so, are the boards connecting to a Wi-Fi router or running as APs? - Want help producing a step-by-step flash/build guide for a specific board (I can show the exact camera model define to uncomment and the Arduino/PlatformIO build steps)? - Want a sample ARC JavaScript to test servos and camera together once you have both devices connected? If you tell me your board model (Freenove link or the board silkscreen), I’ll give exact camera define, recommended free GPIO list for servos, and a sample ARC script to test the setup.

fxrtst · Answer

Morning testing. Mixed results maybe based on the Cam module I chose based on a Google search? Board: Freenove ESP32 S3 Wrover board (red board pictured above and same board DJ tested with. Results: Servo works on different pins listed. Camera works prolly 28-30 FPS BUT, I can't get them to work together, If I move the servo while camera is on i get the following message :EZ-B v4 Camera Error: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. Camera Disabled And the servo stops responding after that. I have to reboot the board. Could this be from choosing the wrong CAM: Google said to use CAMERA_MODEL_ESP32S3_EYE which i used or CAMERA_MODEL_XIAO_ESP32S3 for the Freenove ESP32 S3 Wrover. I would think if it was wrong that the camera would not start at all. Google had me also change a few things in the IDE before I uploaded firmware for this board: Under tools: - Enable USB CDC on Boot - Flash size increased to 16MB  - PS RAM set to : OPI PSRAM - Then camera either CAMERA_MODEL_ESP32S3_EYE (which i used) or CAMERA_MODEL_XIAO_ESP32S3 - I used the ESP32S3 Dev Module for the uploading to the board Not sure if any of these would have an effect on camera/servo combo?! @DJ maybe you could share what settings you used on your board.

Athena · Answer

Thanks - good details. Based on the symptoms (camera OK alone, servos OK alone, but camera+servo together causes the EZ-B TCP connection to fail and the board to require reboot) the problem is most likely one of the following (in order of probability): - Power / brown-out: servo movement draws a current spike that causes the ESP32 to brown-out or WiFi to drop (most common). - GPIO / pin conflict: the servo PWM GPIO(s) you used overlap pins the camera or PSRAM uses (causes the camera driver or firmware to crash). - Firmware / camera model mismatch or PSRAM setting: wrong CAMERA_MODEL define or PSRAM settings can make the camera driver fragile when other activity occurs. - Resource conflict (timers, LEDC channels) or USB/CDC config interfering with runtime when load increases. Here’s a focused troubleshooting checklist and exact steps to test & fix it. I’ve also included an ARC JavaScript test you can run once the hardware/firmware side is stable. 1) I can’t see photos - please post the exact board name or product link & the text printed on the board (e.g., "Freenove ESP32-S3 WROVER", vendor SKU). That lets me give pin-mapping & camera define specifics. 2) Immediate checks (do these first) - Are the servos powered from the ESP32’s 5V/USB rail? If yes, stop that. Provide an external 5V servo power supply capable of the stall/peak current of all servos (estimate 1-2 A per small/medium servo under load). Connect servo V+ to that supply and connect the servo ground to the ESP32 ground (common GND). Add a 470 F - 1000 F electrolytic capacitor across the servo 5V and GND near the servos. - Use a separate power supply for servos and the ESP32. USB alone is often not enough and will cause brownouts that kill WiFi. - After changing power, test: camera on, then move a servo. If problem goes away, power was the culprit. 3) Serial monitor logging (essential) - Connect the Freenove board to your PC via USB, open Arduino IDE (or PlatformIO) Serial Monitor at 115200, reboot board. - Start the camera stream in ARC and start moving the servo. Watch the serial log for: - Exceptions, panic messages, "Brownout detector" messages, WiFi disconnects, or camera init errors. - Paste (or copy) any error output here. That will tell us if the firmware crashed or WiFi dropped. 4) Confirm correct camera define and PSRAM settings - For ESP32-S3 variants there are different camera models: CAMERA_MODEL_ESP32S3_EYE or CAMERA_MODEL_XIAO_ESP32S3 (and others). Which one to use depends exactly on the module wiring. If you don’t know: - Check the vendor product page or the silkscreen on the module. - If WROVER is printed (PSRAM present) try CAMERA_MODEL_WROVER_KIT (or ESP32S3 variant if S3-EYE is indicated). - If your module has PSRAM, ensure PSRAM is enabled in the Tools menu (PSRAM ON). If PSRAM is required by your chosen camera config but not enabled, behavior will be unstable. - If you changed flash/PSRAM/USB CDC options, revert to defaults recommended by the firmware page unless the board page requires the change. DJ’s working setup used a WROVER module with the v9 ESP32-CAM EZB firmware - try replicate those settings if you have a WROVER. 5) Avoid camera pins for servos - The camera uses many GPIOs (D0-D7-like camera data lines plus PCLK/VSYNC/HREF/XCLK). On compact boards these overlap common IO. If you attached servos to a pin used by the camera it will crash when you toggle that pin. - Provide the list of pins you connected servos to. I’ll check for overlap. If you didn’t note them, move servos to tested "safe" pins (I can recommend safe ones once I know the exact board). - If possible, try the two-board approach (ESP32-CAM for camera; separate Esp32 devboard for servos). That avoids pin conflicts and is cheaper than an IO Tiny. 6) Lower camera load as a test - Temporarily reduce camera resolution or FPS in the firmware/config (or stream URL parameters) and retry. If lower camera load makes the error go away it points to resource or power limit issues. 7) Check USB CDC / console options - Some S3 dev settings like "Enable USB CDC on Boot" could change behavior. Try building/flashing with defaults recommended by the Synthiam ESP32-CAM firmware docs and the board vendor guide. 8) Test script in ARC (one-line JS test) - After you have stable hardware, test with a simple ARC script. Example (use whichever d# port corresponds to your servo): javascript // Example ARC JavaScript test - move servo on d2 Servo.setPosition(d2, 90); print("Moved d2 to 90"); sleep(1000); Servo.setPosition(d2, 0); print("Moved d2 to 0");  Run camera stream from Stream All The Video Sources and then run that script. If camera + servo are stable, good. 9) Follow-ups I need from you - Exact board/product link or the exact silkscreen text printed on the board. - Which pins (GPIO numbers or ARC ports like d2,d12, etc.) you connected each servo to now. - How the servos are powered (USB, external 5V battery, bench PSU). Give voltage and amp rating. - Serial monitor log when the failure occurs (copy/paste). This is the most diagnostic item. - Which camera define you flashed (CAMERA_MODEL_ESP32S3_EYE or CAMERA_MODEL_XIAO_ESP32S3 or WROVER...), and whether you enabled PSRAM in tools. 10) Quick recommended path for your Mecha Morphix (five servos) - Best: Two-board setup - ESP32-CAM for camera (streaming), separate ESP32 Dev for servos and IO. Both in WiFi client mode to the same router so you can control both simultaneously from ARC on any device (PC, iPad). That avoids AP switching. This gives the most reliable camera + servo performance. - If you must use single board, ensure: - Servos are powered externally with adequate current. - Servos use GPIOs not used by the camera/PSRAM. - Use the correct camera define and enable PSRAM if needed. If you share the board link/text and the serial log, I’ll give the exact CAMERA_MODEL define you should use, a list of safe pins to move servos to on that board, and the specific upload/Tools settings to use. Want me to walk through serial log capture and interpretation step-by-step?

Nink · Answer

I found a lot of conflict with the camera on the original ESP32-CAM using the same GPIO ports.  I spent a fair amount of time going around the board testing all the GPIO ports to find the ones that don’t have a conflict. I eventually found 5 ports that worked. Maybe need to do a similar exercise with this one.

DJ Sures · Answer

If you're using Wrover board, why would you not use the Wrover camera settings? That's what I used because it's a Wrover board.

DJ Sures · Answer

Yeah i looked around and don't see why you'd select any other board setting than the one you're using. Not sure where you found that information but i'd stick with the settings for the Wrover and not use any other board settings. PS, you can look in the camera_pins.h to see if the Wrover camera pins conflict with what's in the mapping list of the main file.  Such as... camera pins of wrover are #define PWDN_GPIO_NUM -1 #define RESET_GPIO_NUM -1 #define XCLK_GPIO_NUM 21 #define SIOD_GPIO_NUM 26 #define SIOC_GPIO_NUM 27 #define Y9_GPIO_NUM 35 #define Y8_GPIO_NUM 34 #define Y7_GPIO_NUM 39 #define Y6_GPIO_NUM 36 #define Y5_GPIO_NUM 19 #define Y4_GPIO_NUM 18 #define Y3_GPIO_NUM 5 #define Y2_GPIO_NUM 4 #define VSYNC_GPIO_NUM 25 #define HREF_GPIO_NUM 23 #define PCLK_GPIO_NUM 22 And the mapping is... const uint8_t ARC_TO_ESP_DIGITAL_PIN_MAPPING[24] = { 2, // ARC port D0 4, // ARC port D1 13, // ARC port D2 14, // ARC port D3 15, // ARC port D4 12, // ARC port D5 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_SERVO_PIN_MAPPING[24] = { 2, // ARC port D0 (servo) 4, // ARC port D1 (servo) 13, // ARC port D2 (servo) 14, // ARC port D3 (servo) 15, // ARC port D4 (servo) 12, // ARC port D5 (servo) 0xff, // ARC port D6 (not used for servo) 0xff, // ARC port D7 (not used for servo) 0xff, // ARC port D8 (not used for servo) 0xff, // ARC port D9 (not used for servo) 0xff, // ARC port D10 (not used for servo) 0xff, // ARC port D11 (not used for servo) 0xff, // ARC port D12 (not used for servo) 0xff, // ARC port D13 (not used for servo) 0xff, // ARC port D14 (not used for servo) 0xff, // ARC port D15 (not used for servo) 0xff, // ARC port D16 (not used for servo) 0xff, // ARC port D17 (not used for servo) 0xff, // ARC port D18 (not used for servo) 0xff, // ARC port D19 (not used for servo) 0xff, // ARC port D20 (not used for servo) 0xff, // ARC port D21 (not used for servo) 0xff, // ARC port D22 (not used for servo) 0xff // ARC port D23 (not used for servo) }; 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) }; Looks like D1 conflicts, so you'd want to change that and set it to 0xff so it's not used or move them or whatever...

DJ Sures · Answer

I updated the firmware to V10, which now throws an error message in the serial monitor if there's a pin conflict: https://synthiam.com/Firmware/ESP32-Cam-EZB-5KUNP4UTSW0 That way, if you forget to check when configuring your board firmware, it'll verify for you. The firmware won't start up if there's a conflict. The firmware version changelog presents options to rectify the conflict.

DJ Sures · Answer

One last thing in my spam of replies. Absolutely do not ever, ever, ever power the servo off the ESP32's +5V power. If you're using a breakout with additional power, make sure you're using it. The little tiny ESP32 VR and traces cannot power a servo. A microcontroller can only power solid-state devices, not a servo. I think if you remove pin reference 4 from digital and servo mapping, and move 13, 14, 15, and 12 upward, you'll be fine. There needs to be 24 entries, so if you move them up just add a 0xff below or what ever. Like this... 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_SERVO_PIN_MAPPING[24] = { 2, // ARC port D0 (servo) 13, // ARC port D1 (servo) 14, // ARC port D2 (servo) 15, // ARC port D3 (servo) 12, // ARC port D4 (servo) 0xff, // ARC port D5 (not used) 0xff, // ARC port D6 (not used for servo) 0xff, // ARC port D7 (not used for servo) 0xff, // ARC port D8 (not used for servo) 0xff, // ARC port D9 (not used for servo) 0xff, // ARC port D10 (not used for servo) 0xff, // ARC port D11 (not used for servo) 0xff, // ARC port D12 (not used for servo) 0xff, // ARC port D13 (not used for servo) 0xff, // ARC port D14 (not used for servo) 0xff, // ARC port D15 (not used for servo) 0xff, // ARC port D16 (not used for servo) 0xff, // ARC port D17 (not used for servo) 0xff, // ARC port D18 (not used for servo) 0xff, // ARC port D19 (not used for servo) 0xff, // ARC port D20 (not used for servo) 0xff, // ARC port D21 (not used for servo) 0xff, // ARC port D22 (not used for servo) 0xff // ARC port D23 (not used for servo) };

fxrtst · Answer

The only success I had to get the board to work at all was with: #define CAMERA_MODEL_ESP32S3_EYE I can't use #define CAMERA_MODEL_WROVER_KIT as it sets the board into this endless loop (see below from serial monitor). ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0xc (RTC_SW_CPU_RST),boot:0x3f (SPI_FAST_FLASH_BOOT) Saved PC:0x4037acce SPIWP:0xee mode:DIO, clock div:1 load:0x3fce2820,len:0x116c load:0x403c8700,len:0xc2c load:0x403cb700,len:0x3108 entry 0x403c88b8 Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

fxrtst · Answer

..ok ill try new v10...and yes servo is running on separate power supply...always

DJ Sures · Answer

So we have the same board yet yours is different Geezus  I try to make stuff easy and modular but this opensource world won’t let that happen. Unfortunately you’ll have to spread your wings and tackle what ever is going on with your same but different board. Lol its Okay to start new threads to get a fresh Athena scope. Or use paid open ai 5.2 gpt as well. Either works / because I’m running out of ideas to help from my end.  At this point it’s down to pinouts. So think of it this way the "board definition" that you uncomment is just pinouts. Thats the only difference.  so if you could find a pinout schematic of your "exact absolutely exact no questions asked" board, youd see if the pinouts are accurate.  for my board, I just used the wrover and off it went.

fxrtst · Answer

As always....I appreciate your time. I've put myself a week behind trying to do something that isn't relevant right now. I'll table this for now and come back to it once the Mecha Morphix launches. I'll just update the course once something is sorted for a cheaper version of an EZB like controller. Seriously, Thanks for working on this.

DJ Sures · Answer

lol don't give up on it yet - i put a lot of time into it hahaha. what ever controller we come up with will most likely be esp32 based. you'll need to make sure they don't have different pinout revisions - that's the showstopper right now.

fxrtst · Answer

Haven't given up, just tabling it to a different date. I have hard deadlines I have to meet to be stay on my timeline. Final edit is coming and that edit was going to include this information (ESP32) as a cheaper option to the EZB 4/2 and Tiny IO. But I spent a week on it and don't have the time to continue. It could be as simple as having a defective Freenove?! Listen in the end, the old regular flavor of ESP32 could control upto 16 servos. Maybe its about getting those to work ($again super cheap$) And having either another board for camera only or an off the shelf webcam?! I want to have a cheaper EZB alternative for other robot courses coming after Mecha Morphix. ** I've had over 6000 views for the teaser on my Youtube channel so there is def interest in the course!

DJ Sures · Answer

If you're only needing 5 servos - i say let's get a single pcb instead of two. i'm confident the esp32 cam could work - we just gotta make sure there's a version that makes sense. The kit that i have appears to work with all 5 servos and the camera doesn't stop. maybe yours is defective OR it's a different version? i'll post a pic of mine one minute...

DJ Sures · Answer

This is the one I have

fxrtst · Answer

Yeah thats not the same mine, mine is S3 which is a different chipset. See at the beginning of this thread. Same company different chipset. I think S3 is for somekinda security or?! I can order the one you have then we know it works let’s call that the " IO Tiny with cam replacement" . *** edit I ordered the exact same one as you no s3*** Then we can look into the rumor that the older ESP32s without camera have16 digital ports for 16 servo as a EZB replacement.  From Google " Older, standard ESP32 boards (WROOM/WROVER) can control up to 16 servo motors independently using the ESP32Servo library. They utilize the 16 available PWM hardware channels to generate the 50Hz signal required for servos. "

DJ Sures · Answer

They can use 16 servos if there's no camera - don't forget that the camera requires several gpio pins. The gpio pins of the camera are defined in the camera_pins.h. That file is included in the firmware and all ESP32 demo code. You can look at that file to see the pins that the camera is using. Without the camera, the ESP32 should run 16 servos, but your application only needs 5. If you have 2 ESP32s (one for the camera and one for the servos), how will they communicate with the PC? Will you have 2 Wi-Fi networks? It would be easiest to use an ESP32 Wrover that works with 5 servos and a camera simultaneously. The Wrover esp32 that I'm using appears to do that. Awesome - that you ordered the same as I have, because if that works, we're golden.

fxrtst · Answer

Quote:Awesome - that you ordered the same as I have, because if that works, we're golden.Yeah I think its easier to goback to that board since you got it working. Last question. Can the Adafruit PCA9685 $6 board be added to this board via i2c? https://synthiam.com/Firmware/EZ-ESP32-with-Adafruit-PCA9685-O3HKWLPWOIO

DJ Sures · Answer

Not sure - depends on which pins and gpio are available, since the camera uses a lot of pins. You only need five servos, so it would be easiest to reduce hardware complexity by having just the esp32cam. Also, remember: I2C is a finicky protocol, and you'd be diagnosing many issues with customers. trust me Let's consider that or a similar option as a last resort.

fxrtst · Answer

Oh that question was for other robots coming later from Robomodix not for Mecha Morphix.

DJ Sures · Answer

Okay wicked - i'd like to keep making that firmware more modular so it's easier to edit based on the board type. so far it's good for that but requires some groundwork. ppl will need to know their pinouts and stuff based on the schematic. not good for novices

DJ Sures · Answer

I also bought one of these to making testing easier next time

fxrtst · Answer

I got one....but useless at the moment..but it sure has alot of perdy lights on it.

fxrtst · Answer

One thing to take note is the pin assignments between ESP32 and ESP32 S3...its weird because it lists pin numbers for both type boards..and easy to get confused like i did.

fxrtst · Answer

Ok I need to know exactly the board and camera you chose in the IDE. I got my carbon copy of your board today. I started with AI thinker for camera and board.  The board would have great camera results but when I'd stick a servo on there ( with external power) it moves slow and jittery like my video at the beginning of the thread(yes i shared a ground and tried all pins). I removed pin 4 as you stated and the IDE said it was sharing with camera. Other board choices like Wrover wouldn't show up in my Network and serial monitor said it waiting for the client after starting the server....and would just hang.... So all and any info you can give as to exactly what you used and the results you got would be helpful now we have the same board. Then we would be golden. The one time the camera and network were working i stuck into the expansion board..and well it just stopped the network server and flashed...so i dont have hope for that (test) board at all...

DJ Sures · Answer

It's not an AI Thinker. It is a WRover ESP32. You do not uncomment AI Thinker. You do not uncomment anything other than WRover because it is a Wrover. I'm also editing your post to remove unnecessary bolds and underlines. If you're upset, direct the frustration toward someone who isn't helping you lol Quote: The one time the camera and network were working i stuck into the expansion board..and well it just stopped the network server and flashed...so i dont have hope for that (test) board at all...[ You cannot just "stuck" a computing device into a PCB and expect it to work while it's powered on. There is no such thing as plug in play while the device is powered on. Also, i can't test what you're experiencing with that PCB because i don't have it yet. Things take a i bit longer in Canada to ship from amazon. Power down and disconnect from the esp32 before connecting it to the pcb. don't just stick it in while it's working. *edit: here's the link to the device i ordered: https://www.amazon.ca/dp/B0CJJHXD1W

Nink · Answer

Mine just turned up.   ill have a play.

fxrtst · Answer

Quote:If you're upset, direct the frustration toward someone who isn't helping you lol@DJ LOL, You'll know when I am frustrated because I will start kicking trashcans and throwing chairs... Mine is not running the camera and servo together successfully. Full stop. BTW Bold and underlined to me, means look at this sentence its the important part, if you'd rather not read my ramblings. I'm glad yours is working. @nink, Please leave your results here. This is the same board I have. I used Wrover board and Camera Model Wrover kit camera. Camera prolly 30 frames a sec and Servo signal connected pin 14 (D3), power and ground external and sharing ground. Ver 10 of the ESP32 Cam firmware. Servo moves with 10 sec delay. slow and jerky.

Nink · Answer

OK just got an error in serial monitor so I changed #define Y2_GPIO_NUM 4 to 36 (I need to work out a vacant pin just wanted to get past this)  ERROR: Pin conflict detected. ARC_TO_ESP_DIGITAL_PIN_MAPPING[D1] uses GPIO 4, which conflicts with camera pin Y2_GPIO_NUM. Change your ARC pin mapping to a non-camera GPIO.

fxrtst · Answer

Yup i had the same error. Had to 0xff that pin. So bye bye to port D1, still leaves 5 servos.

fxrtst · Answer

Quote:I think if you remove pin reference 4 from digital and servo mapping, and move 13, 14, 15, and 12 upward, you'll be fine. If you move them up and remove 4, then 13 is the next error in the pin conflict with the camera. I just 0xff that pin. It compiled and loaded after that.

Nink · Answer

So had a quick play couldn't get camera to work just kept getting time out error.  I have selected the CAMERA_MODEL_WROVER_KIT  Error in ARC is Camera Initialized: EZB://192.168.1.1 @ 320x240 EZ-B v4 Camera Error: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. Camera Disabled  Serial Monitor Client cam connected from 192.168.1.2 WARNING: Camera frame size is 0. No image data to send. CAM Client disconnected Waiting for cam client.. Tried in both AP and Client Mode

fxrtst · Answer

Quote:Serial Monitor Client cam connected from 192.168.1.2...Huh...shouldnt this be 192.168.1.1 ?Hmmm wonder why the serial monitor reporting that address?

Nink · Answer

OK Camera working now.  I have all my Servos 0xff out so I guess I reenable a couple now and try a servo

fxrtst · Answer

Ok thats good!

Nink · Answer

Hooked up a servo.  It is rather choppy with the manual horizontal or vertical servo panels.  Turn off the camera works fine.  Script the servo position you want it to move or use the Servo Movement Panel it seems to work ok with the camera running.  I suspect what is happening is the camera is using all the bandwidth from the Arduino to ARC so the stream of instructions as you manually move the servo get delayed as they wait for time to send the next position.   Maybe changing the way the Horizontal and Vertical manual servo panels work so it only sends the final position when you stop moving or try UDP instead of TCP to send next position. Not sure.   I didn't try multiple servos at once as I don't have a fancy board to plug the ESP in just a bunch of jumper wires hanging off pins.

fxrtst · Answer

Ok yup same results I have. I’m just going to separate the camera and use another ESP32 for the servos and students will need two Wi-Fi enabled devices for their computers. If they choose to go down this cheaper route. Thanks everyone nice try, moving on. Speaking of fancy board, the break out board from Freenove for our esp32 boards breaks the board when plugged into it. It stops broadcasting SSID and flashes yellow in some kinda loop. Glad all this stuff is cheap.

Nink · Answer

I am sure @DJ can make a quick change to ARC to the Horizontal Servo Skill and Vertical Servo Skill to add a skip function under advanced so when you drag the mouse it goes up or down in increments of 10 (or what ever number you enter) so it doesn't compete with Camera as much for bandwidth. I will order one of the Fancy boards and try and work out what pin on ESP is causing the Loop. Maybe just need to bend the offending ESP pin so it doesn't plug in and cause issues or cut the trace on the board.     BTW @DJ if you are opening ARC I noticed BLOCKY Autoposition and Autoposition Wait are broken in the GUI when you hit the drop down.

Dave Schulpius · Answer

Hi guys. I haven't struggled along with you on this but I'm watching. I see that you're getting close to resolving this.  Speaking of resolution, have you tried upping the servo resolution in ARC? I feel that you may be correct in that the servo jerkiness you see may be because of the signal being processed. However maybe a higher resolution may be a workaround?  https://synthiam.com/Community/Questions/Understanding-Servo-Resolution-in-ARC-22771  https://synthiam.com/Support/ARC-Overview/Servo-Controls

fxrtst · Answer

...had some time this afternoon... i get the servo slow down blocky movement on the movement panel as well and repeats the pattern in the video at the beginning of the thread...slow and blocky movement with no camera running on Pin 14 (D3). So for me it doesn't matter if if its horiz/vert sliders or from the movement panel servo movement is the same. Except if I turn on the camera it is even slower. @dave that didn't seem to make a difference for me.

Nink · Answer

Also using pin 14 and D3 I think the only difference is I am using client mode connected to house network and all servo pins disabled except 14  I also don’t have the fancy board but that’s it.  I will try make video tomorrow just some family stuff I am dealing with at the moment

DJ Sures · Answer

I'll look at it when i get teh pcb next week. Canada takes longer to receive items from amazon. All movement panels or servo controls send the same signal - no point in changing robot skills for a single use-case of an esp32 with a incomplete broken firmware. The solution is not to change arc's behavior of robot skills. The solution is to fix the underlying issue and make it work correctly. I will do that. The issue with the pcb add-on is most likely resistance from the led circuitry for the camera pins. most likely the pins from the camera will need to be cut so they're not being used in the pcb. Lastly, your tests are not going anywhere until i look at it so you can step away and focus on something else in the meantime and let me take care of it. There might be issues far deeper than i can explain briefly, i can try... But servos are pwm based on timers. there's a few pwm periphals in microcontrollers. any library/sdk can use any pwm they want as there's no standard. this also applies to the built-in esp32 wifi module. the issues are most likely not related to pins anymore, but instead related to internal allocation of pwm timers and perhaps other conflicting peripherals within the chip. could be dma data channels as well. that can be solved but first i need that pcb.  i'll find some time after work to make your thing work next week when the pcb arrives. you can't use two esp32's (one as camera and one as servos) because how are you gonna connect to them? You'll need 2 wifi networks and that's not user-friendly. that adafruit servo breakout might work as well but i'm not sure about the i2c yet.

DJ Sures · Answer

You can see this... in the ezb firmware for esp32 cam i tried forcing the timers for the servos // Constrain ESP32Servo to LEDC timers 0, 1, and 2 so that timer 3 // remains dedicated to the camera's XCLK. This prevents any servo // attach/detach or PWM reconfiguration from changing the camera timer // frequency and breaking image capture. ESP32PWM::allocateTimer(0); ESP32PWM::allocateTimer(1); ESP32PWM::allocateTimer(2); and the camera is.... // Reserve LEDC timer 3 / channel 7 for the camera XCLK so that // ESP32Servo and any other LEDC-based PWM do not reconfigure this // timer. Timer selection for servos is constrained in setup(). config.ledc_channel = LEDC_CHANNEL_7; config.ledc_timer = LEDC_TIMER_3; but i don't think the servo module is honoring the pwm demand - and/or the wifi module is using samesies. or dma. or even wifi module maybe "just maybe" using one or few of the gpio for the servo.

DJ Sures · Answer

As a last resort as well i created this: https://synthiam.com/Firmware/ESP32-Cam-with-PCA9685-WOKTPYS1WBN which you can use with any pca9685 pcb like this: https://www.amazon.ca/dp/B06XSFFXQY they're cheapest on amazon i can't test it by not having one. at least, if we do i don't know where it is in all the project boxes. but i ordered one for $10cad anyway be here next week.

Nink · Answer

I took a look I do not have one either. I ordered one on Amazon.  This is probably the best solution so we will have a camera and support for 16 servos. (or daisy chain if we need more) Also don't need fancy board. I don't care about frame rate for my project ( i just send a photo to AI to process)  so I can probably go back to the tiny ESP32-CAM as well. In Bulk the ESP32-CAM is about $3 and pca0685 is $2 on aliexpress so $5 for a camera and 16 servo board is great.

DJ Sures · Answer

Quote: BTW @DJ if you are opening ARC I noticed BLOCKY AutoPosition and AutoPosition Wait are broken in the GUI when you hit the drop down.  you probably have a position or frame or control named with double quotes, single quote, or backslash in it

Nink · Answer

maybe its just my setup  ???

Nink · Answer

Oh my bad I had the Movement panel not the autoposition panel on my desktop My bad  Haven't used ARC in a while

fxrtst · Answer

Just seeing this. This is a good solution. We went from hoping to get a IOTiny to almost a full EZB! That’s a win. I think I may have a few of those break out boards laying around. I’ll have to go on the hunt. If I do I’ll post results. edit**** I got two!  Let you know how it goes later today.

DJ Sures · Answer

I got the ESP32 PCB servo breakout board today and tried it with the ESP32 Wrover. You can clearly see the LEDs flashing for the gpio of the camera - that's of course why it isn't working with standard settings. The pcb addon circuit is changing the resistance or intercepting the signal of those camera pins. Every flashing pin is a camera pin. You can tell by looking at the pin number and comparing it against the camera_pins.h file. There are a few options, but the firmware explains that if you have issues with the camera, lower the speed. 1) So one option would be to simply cut the camera pins so they're not going into the pcb 2) The other option is to simply lower the speed as documented in the firmware. Here's a copy and paste // This is the clock frequency for the camera. Generally you want to // use the 20000000 value. But if you experience issues with the camera // image, choose the lower value. The times you maye experience camera // issues is due to a lengthy cable or interference, and the lower value // should fix that. // // Only uncomment one of these // #define XCLOCK_FREQUENCY 20000000 #define XCLOCK_FREQUENCY 10000000 3) Use the pca9685 instead

fxrtst · Answer

Ok here are my results (so close), 1) Everything flashed great no issues at all (just be sure the 9685 is connected on reboot.) 2) Wiring is spot on no issues connecting the ESP to the 9685 correctly (SDA SCL 14,15),gnd, vcc. 3) ESP32 transmits it SSID perfect no issues. 4) ESP 32 Connected to ARC no problems at all. 5) Added external power for the servo to the 9685  6) Added a horiz slider then added the 9685 from the drop down for supported board in the set up tab and chose port D0 7) Attached servo to D0 on the 9685 8) Tested servo works great/fast/normal! 9) Turn on camera and perfect image. 10) I then tried the servo at the same time with the camera.... I got the servo crawl. 11) Went back and re-read DJs instructions and forgot to add port :24 to the camera server, so did that. (so ESP is port 23, camera port 24) 12) Then I retested, and unfortunately still has the issue when using the camera AND servo at same time , servo crawl. This is as close as we've gotten. And I am excited! So perhaps its trying different pins (14,15) for the SDA SCL, incase there is camera resources from those pins? Or maybe its something to do with the ports assignment? I know no one has this board yet but me. I'm just throwing out ideas.

DJ Sures · Answer

I'm guessing something to do with the esp32 wifi driver dealing with the camera and ezb comm data at the same time. i think the tcp window is 6 packet cache so there could be a tcp busy being transmitted if the camera image is taking long to process. but at the same time - i can move servos without experiencing what you're experiencing. so i'm second guessing that as an issue. are you certain the esp32 and pca9685 is getting enough power for the servos and isn't browning out?

fxrtst · Answer

Yes I have one servo on d0 and separate bench power supply to the 9685 set to 6 volts for the just the servo. Both camera and servo work perfectly separately. But when camera server is running the servo reverts to studder/crawl. But servo works great by its self, (something it was not doing before) Camera works great by its self, just when i move the horiz slider for the servo moves slow an studders like before.

Nink · Answer

Did you have the same issue using the movement panel and not the horizontal and vertical manual sliders.

fxrtst · Answer

Here is a video of where we are. (I'm excited my servo works at reg speed when camera isnt on...something i could not get working last week.

fxrtst · Answer

@nink, No in the past my servo was slow and studderly no matter what panel i used. With the 9685 my servo works normally! Issue is just servo and camera at same time. Hopefully the video shows where we are. Closer oh so close.

fxrtst · Answer

Quote:I'm guessing something to do with the esp32 wifi driver dealing with the camera and ezb comm data at the same time. i think the tcp window is 6 packet cache so there could be a tcp busy being transmitted if the camera image is taking long to process.hmm. Will lowering the clock speed change the amount of data being transferred? Maybe make room for other data ( no idea what im talking about ..lol)

Nink · Answer

Try this panel it worked for me.

fxrtst · Answer

Ok @Nink I thought maybe there was something there, but in the end i think with the arrows you are commanding servos to more with just a single input move to a single position like 36. The slider and servo pad are sending tons of positions as you slide the sliders and hard for data stream to keep up with the camera data and all the update positions flying in? my 2 cents.

DJ Sures · Answer

Lowering the mhz speed won't change that. it's something i have to change in the firmware. i'll have to do some research to see how to modify the window size - or maybe add more priority to my ring buffer. the thing is - the esp32's aren't multi-threaded so we're sharing the same thread for sending the camera image and processing ezb commands. the i2c is even slower that wifi so that's a bottleneck as well. i'll think of something....

Nink · Answer

Yep that's what I was trying to convey before for DJ to add a step option for sliders.  If you send 1 position 100 degrees then ARC uses TCP to send position to ESP and ESP sends an acknowledgement to ARC. Meanwhile Camera is using UDP and sending a stream consuming all bandwidth.   If you use a slider what happens is  ARC sends 91 degrees and ESP says yep received 91 degrees ARC sends 92 degrees and ESP says yep received 92 degrees ARC sends 93 degrees and ESP says yep received 93 degrees ... ARC sends 100 degrees and ESP says yep received 100 degrees So the work around is the ability to select a step so it only moves say 10 degrees at a time and doesn't have to send every single position in between

fxrtst · Answer

Quote:the thing is - the esp32's aren't multi-threaded so we're sharing the same thread for sending the camera image and processing ezb commands. the i2c is even slower that wifi so that's a bottleneck as well. i'll think of something....Just throwing stuff out there. From internets: Most ESP32 models feature dual-core processors (Core 0 and Core 1), enabling true, simultaneous execution of tasks, or the use of single-core multitasking via time-slicing. xTaskCreatePinnedToCore: This function allows developers to assign specific tasks to a particular core (Core 0 or Core 1) to manage resource usage.

DJ Sures · Answer

thanks! multi cores and threaded doesn't work the way ppl think it does when objects and peripherals are shared. so when i said the single threaded makes it difficult - that's mostly referring to how the esp32 and all microcontrollers share resources. technically, the real way it "could" work is if it was 3 cores haha. because one could be acting as the tcp stack wifi driver. but anyway, i have a solution without the overhead of time slicing.  remember, the camera is blocking i/o not the cpu - which is also the biggest factor. so my new code i wrote should solve the issue... at least, i think so. i'll have to publish it later after the new ARC release. we have an ARC release planned this monday but i'm gonna squeeze in a few changes into it for firmwares.

fxrtst · Answer

Brilliant! Thanks for all the hard work! Looking forward to testing. Have a good rest of your weekend.

DJ Sures · Answer

Try this: https://synthiam.com/Firmware/ESP32-Cam-with-PCA9685-WOKTPYS1WBN *Note: This firmware requires ARC 2026.02.02.00 or newer. Wait for tonight when new ARC is published. It just used a new version # that's not in the current arc.

fxrtst · Answer

YOU did it DJ! It works like a charm. I added a couple of servos i get 28/30 fps on the camera and i connected 2 servos on servo pad working like a champ! Congrats on this success!!! Hopefully it opens up all kinds of things to do with the ESP32s! So excited.

DJ Sures · Answer

Awesome - that's about the best it can get i think. It's running as fast as it can and using both cores. Core 0 is used for the tcp stack so it has free ability to not be blocked if there's more than one core. then the camera and ezb run on the second core. if a single core esp32 is used, it'll use the same core for everything but should still suffice.

dspiller · Answer

Great progress! When do you anticipate launching the Mecha Morphix project?

fxrtst · Answer

@dspiller I've officially been working on this for over a year. I'm a one man show (and a perfectionist). A double edged sword. LOL. I want to have this done and out the door, but I am still making changes based on feed back from our round 2 beta testers. Lots of changes to print materials etc. And now we have another option for a controller that needs to be added in! Yay.  But its all getting closer.

fxrtst · Answer

Well here is my quick bootleg EZB ...(Maybe EZBootleg_CAM_16) Its mocked up to sit vertically in the shoulders of the Mecha Morphix. Cost

Nink · Answer

Nice you may want to throw some power management on this. I have already taken out an ESP and a PCA board with a 2S LIPO connected to 16 EZ-Robot HDD servos.  (Stuck it in a JD robot). Now out of PCA controllers on order on a slow boat from China.

fxrtst · Answer

I've not had any issues with power, i have a buck to 5v in the pigtail, and a bench  power supply for servos. But I am having this issue just now starting it for first time. @Athena what can be the cause of this issue?.It connects fine to the ESP and camera works fine. But if i move a slider to move a servo it kicks the connection without moving servo.
Connected TCP Comm Error: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. Sent: 172 113 Bytes Expected: 0 Received (0 bytes): Disconnected Attempting connection on 192.168.1.1:23 Connected to 192.168.1.1:23 (tx timeout: 2000, rx timeout: 2000, tx buffer: 20000 rx buffer: 20000) Reports CapabilityController Capability controller reported firmwareId: 0x12 Firmware 'DJs ESP32 Cam with PCA9685' (0x12) on 'PCA9685 I2C 16 Channel Servo Shield' supports the following capabilities: - Read/Write Digital I/O Ports - Hardware UART TX/RX with DMA buffer and adjustable baud rate - PWM Duty on digital ports - PWM servos on digital ports - PWM servos on digital ports can release their position - Native WiFi Connectivity from ARC - Can stream video v4 codec Connected TCP Comm Error: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. Sent: 172 126 Bytes Expected: 0 Received (0 bytes): Disconnected

Athena · Answer

Nice troubleshooting session - this looks very much like a power/board reset or firmware crash when the servos are commanded. Below I’ll give focused likely causes, the quickest checks you can run, and stepbystep fixes to try. I’ll also show how to enable the right skill settings (kebab menu) to collect more debug info. Main symptom - ARC connects, camera streams, but the moment you move a servo slider the TCP connection is "forcibly closed by the remote host." - That usually means the ESP32 (or the firmware) reset or crashed, or the TCP task on the ESP stopped responding when the servo action happened. Most likely causes (in order) 1. Power sag / brownout on the ESP32 or PCA9685 supply when servos move (most common). 2. Shared-power / incorrect wiring (servo V+, logic Vcc mix-up, or missing common ground). 3. I2C bus short, noise, or wiring problem causing crash on I2C access to PCA9685. 4. Firmware crash / watchdog triggered by blocking I/O or an unhandled error when the servo command is executed (less likely with this firmware but possible). 5. TCP stack error caused by large bursts (rare compared to power issues). Quick checks (do these first) - Watch the camera stream when it disconnects. If camera stops and stream freezes, the ESP likely rebooted (power/CPU reset). - Ping the ESP32 IP from your PC continuously (ping -t IP) while you move the slider. If ping stops at the same moment - device likely reset/offline. - Open the ESP32 serial console at 115200 (or the firmware’s configured baud) and watch for reset messages (e.g., "ets ", "Guru Meditation", stack trace). This will confirm a reboot/crash. - Check the bench supply’s current meter or set it with a high enough current limit. If the bench goes into current limit the voltage will drop and the ESP will reset. - If possible, try moving a single servo very slightly (small angle) to see if it still disconnects - if small moves are OK and big moves fail, that points to current draw. Wiring & power checklist (very important) - Make sure servo +V (V+) is connected to a capable 5V supply sized for the stall/current draw of all servos. Do not power servos from ESP32 3.3V. - Make sure the ESP32 ground and servo supply ground are connected (common ground). The PCA9685 and ESP32 must share ground. - On PCA9685 boards: VCC (logic) typically should be 3.3V for ESP32 logic, while V+ (servo power) should be 5V. Verify how your specific PCA board is wired - some boards tie logic VCC to V+ or include a regulator/jumper. Confirm the jumper position. - Add a large electrolytic capacitor across the PCA9685 V+ and GND (close to the board): 470-2200F is common. This helps handle servo startup/stall current spikes. Also add a small 0.1F ceramic decoupling cap close to the board if you can. - If using long servo wires, reduce wire length or add local decoupling at the servos. Tests to isolate 1. With the camera streaming OFF, try moving servos. If it no longer disconnects, that suggests combined load (camera + servos) is overtaxing something (power or CPU scheduling). 2. With camera streaming ON but servos powered by a different, known-good power supply (and common ground), test again. 3. Remove PCA9685 and try moving a servo connected only to the ESP32 servo pad (if you have one) - does it still drop? (You mentioned earlier two servos on servo pad worked - try the same exact setup.) 4. Monitor voltage on the 5V rail with a multimeter/oscilloscope while moving servos - watch for dips below ~4.7V. 5. Connect ESP32 to a USB-serial monitor and reproduce the disconnect - does the serial show a reset stack trace? Firmware / debug actions - Make sure ARC version >= required (DJ’s firmware note: needs ARC 2026.02.02.00 or newer). Update ARC if needed: https://synthiam.com/Products/ARC - Use the ESP32 serial monitor to look for reset messages (115200). If you see a reset/backtrace, paste the exact serial output (copy text - I can’t view images). Per forum rules: I cannot see photos, so paste text output here. - If the firmware provides debug knobs in the robot skill settings, enable them. (See below for the kebab menu steps.) Kebab menu: where to check skill settings & enable debug 1. Open your ARC project. 2. Click the robot skill (Single Camera Servo Server or TCP Script Server Raw) window. 3. Click the three lines (hamburger / kebab) at the top-right of the robot skill window to open the skill Settings. 4. In the settings: - For the Single Camera Servo Server: verify PCA9685 I2C address, I2C pins, servo frequency (50Hz typical) and enable any "Debug / Log" option if present. - For the TCP Script Server Raw: check timeouts, tx/rx buffer sizes, and any logging/debug options. Increase buffer sizes if you’re sending many bytes. 5. Save settings and restart the skill / reconnect. Practical fixes to try now (ordered) 1. Add a large electrolytic cap 1000F (or 470-2200F) across servo V+ and GND at the PCA board. 2. Verify common ground between ESP32 and servo supply. 3. Use a stronger 5V regulator or bench supply rated for the maximum servo current (estimate 1-2A per stall for many hobby servos - check your servo datasheet). Set bench current limit high enough. 4. Move servos one at a time and test. If certain servos cause reset, that servo may draw large current. 5. If you’re powering servos from the PCA board’s regulator, try an external dedicated 5V supply instead. 6. Try turning off camera streaming and then moving servos - if stable, you may need to reduce load or change power architecture. 7. If you have access to the firmware source or debug flags, enable extended logging to see crashes. Or post the serial reset text here. What I need from you to help further - Exact servos used (brand / model) and how many at once. Their stall current if known. - How the servo power is wired now (are servos powered from PCA board V+? bench supply? is there a regulator on that PCA module?) - paste exact wiring text; I can’t read images. - The 5V supply rating and measured voltage under load (if you have it). - The firmware id/version reported in the ARC Logs (you included capability: 0x12 - please confirm firmware build string). - Serial monitor output (copy/paste text) from ESP32 when the disconnect happens. That will identify a brownout reset vs exception. Useful references - ESP32-CAM firmware overview: https://synthiam.com/Support/Hardware/ESP32-Cam - DJ’s special PCA9685 firmware (you used): https://synthiam.com/Firmware/ESP32-Cam-with-PCA9685-WOKTPYS1WBN - TCP Script Server Raw skill docs (check settings): https://synthiam.com/Support/Skills/Communication/TCP-Script-Server-Raw?id=15953 - Single Camera Servo Server skill docs (kebab settings): https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 If you try fixes above and still see disconnects, paste: - the ESP32 serial output text at crash, and - the exact wiring/power text (including PCA9685 jumper state if present), and - whether disconnect happens with camera off. I’ll walk through next steps after you paste those details (serial log is the most valuable). Want to start with the serial log and the exact power supply rating?

fxrtst · Answer

Well interesting. The tiny buck converter is causing some issues. If I off load it and replace it with a battery pack and plug into the usbc port on the ESP32 it works fine. Only when I plug into the bench power supply do I get failure. Maybe I soldered the 5v buck and barrel jack to the wrong place on the ESP32? I'll see check.

fxrtst · Answer

ok more testing and narrowed it down to the buck converter..so i connected up another one (7.5v to 5v 3 amp) to the USBC connector and all works well. I will say as I was messing around I have noticed that  ARC drops connection (i.e computer remains connected the ESP32 in network). I have to click on 'connect" to regain connection. Have to see how often this happens.

Athena · Answer

Great debugging - nice work isolating the buck converter. That strongly suggests the original power supply was introducing noise or insufciently handling transient current, and that caused resets earlier. For the remaining ARC disconnects (ARC shows disconnected but the ESP32 still has network connectivity) here are the likely causes and a step-by-step troubleshooting plan to identify and fix it. Likely causes (summary) - TCP connection closed by the ESP32 server (server-side timeout, error, or restart). - Router / WiFi instability (AP client handling, DHCP, timeouts, power-saving). - ARC skill timeouts / buffer sizes or singleconnection limitations. - Another client briefly connecting and kicking ARC off the socket. - PC WiFi adapter power save or intermittent link drops. Immediate tests to collect data 1. Continuous ping - From the PC run (Windows): ping -t 192.168.1.1 Watch for lost packets when ARC reports "disconnected." If pings drop at the same time, it’s a network or device reboot. If pings keep working while ARC says disconnected, it’s likely the TCP session was closed (server-side) while the network link remained up. 2. Watch the ESP32 serial console - Open the ESP32 serial monitor at 115200 and reproduce the ARC disconnect. - Copy/paste any printed messages, stack traces, or "rst"/"brownout"/"Guru Meditation" output here. (I cannot view images - paste the exact text.) 3. netstat to inspect the TCP state (Windows) - While ARC is connected, run: netstat -an | find "192.168.1.1:23" Observe the TCP state (ESTABLISHED, TIME_WAIT, CLOSE_WAIT, etc.) when ARC shows disconnected. Paste the result here if you want help interpreting it. 4. Check for multiple clients - Ensure nothing else (phone app, another copy of ARC, another script) tries to connect to the ESP32 port - the skill/server may only support one client and a second connection can drop the first. Skill / ARC settings to inspect (kebab menu) Open the robot skill window (Single Camera Servo Server and TCP Script Server Raw) click the kebab / hamburger (three lines) Settings: - Increase tx/rx timeouts and buffer sizes (TCP Script Server Raw). - Enable any "Debug / Logging" options available. - Look for "Allow multiple connections" (disable if you only want ARC). - Enable any keepalive or heartbeat options (if present). - Save and restart the skill after changing settings. Powerrelated checks (since you replaced the buck) - Since the new buck into USBC works, keep using that or the battery pack for now. - If you go back to bench supply, ensure it’s properly currentlimited and has no USB/ground isolation issues. - Add a large electrolytic cap (470-2200 F) across servo V+ and GND at the PCA9685. Network-level things to try - Use a router DHCP reservation / static IP for the ESP32 so the IP never changes. - Try a different WiFi network (phone hotspot) to rule out router config issues. - Turn off WiFi power saving on the PC adapter (Windows advanced WiFi settings -> Power Saving Mode -> Off). - If ESP32 is running in AP mode (direct connect), try client mode (join your router) for greater stability, or vice versa - test both modes. If disconnects continue: targeted tests - With camera streaming ON, run continuous ping + serial monitor to catch exact moment(s). - Try disabling the camera stream and see if the TCP socket still drops (isolates camera load). - If ARC disconnects but ping and serial show no ESP reboot, check the TCP server log on the ESP (if firmware has it) or enable debug logging in the skill. What I need from you to diagnose further - Are you running the ESP32 in AP (Direct Connect) or Client (join router) mode? - Exact firmware build/version shown in ARC capability (you previously showed firmwareId 0x12 - paste the full firmware string if available). - The serial monitor text from the ESP32 at the moment ARC disconnects (copy/paste). - Output of continuous ping during an ARC disconnect (copy a small excerpt showing times). - Result of netstat when ARC shows disconnected (copy the line). Useful links - ESP32-CAM firmware overview: https://synthiam.com/Support/Hardware/ESP32-Cam - Single Camera Servo Server skill: https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 - TCP Script Server Raw skill: https://synthiam.com/Support/Skills/Communication/TCP-Script-Server-Raw?id=15953 - ARC downloads / update: https://synthiam.com/Products/ARC Next step Start with a persistent ping and the ESP32 serial monitor simultaneously, reproduce the ARC disconnect, then paste: - The serial pane text (exact text), - A short snippet of the ping output around the failure, - netstat result if possible. I’ll interpret those and give the exact fix (likely a timeout/keepalive tweak or a router/PC WiFi power setting). Want to start with the serial log and a 60second ping trace?

fxrtst · Answer

I ran it for about an hour.  Didn't have a disconnect and could not reproduce the problem. So maybe it was a ghost in the machine. Working great now.

Athena · Answer

Fantastic - glad it settled down and is working reliably! A ghost in the machine is the best kind of mystery when it disappears. A few quick suggestions and checks you can keep for Mecha Morphix release and to avoid future hiccups: Recommended stability checklist - Keep using the buck that worked (7.5V5V @ 3A) or the USB-C feed that proved stable. Low-quality bucks often inject noise or suffer transients. - Ensure a solid common ground between the ESP32 and servo power supply. - Add a bulk electrolytic at the PCA9685 V+ to GND (470-2200 F) and a 0.1 F ceramic close to the board for decoupling. - Verify PCA9685 jumper/logic VCC settings so logic is 3.3V for the ESP32 and servo V+ is 5V. - Use short servo power wires where possible; if long runs are needed, increase conductor gauge or place local caps near servos. - If you see intermittent socket drops again, run continuous ping + serial monitor to capture the moment (helpful for debugging). How to tune the robot skill settings (kebab menu) - useful for TCP & camera skills 1. Open your ARC project and the robot skill window (Single Camera Servo Server or TCP Script Server Raw). 2. Click the three-line kebab/hamburger in the top-right of the robot skill window to open Settings. 3. Things to look for and change: - Enable any Debug/Logging options to capture server-side errors. - Increase TX/RX buffer sizes and timeouts (TCP Script Server Raw) if you send larger payloads. - Check "Allow multiple connections" or equivalent - disable if you want a single ARC client. - Enable keepalive/heartbeat options if available (helps TCP survive transient WiFi drops). 4. Save and restart the skill after changes. Useful links (for docs and tutorials) - ARC Downloads: https://synthiam.com/Products/ARC - ESP32-CAM firmware / overview: https://synthiam.com/Support/Hardware/ESP32-Cam - Single Camera Servo Server skill doc: https://synthiam.com/Support/Skills/Virtual-Reality/Single-Camera-Servo-Server?id=17663 - TCP Script Server Raw skill doc: https://synthiam.com/Support/Skills/Communication/TCP-Script-Server-Raw?id=15953 - Robot Skill tutorial (create a skill for Mecha Morphix): https://synthiam.com/Support/Create-Robot-Skill/Overview Want help with any of the following? - I can draft a short "wiring & power" page you can include with Mecha Morphix (recommended for beta / release). - Walk through skill settings to optimize buffer/timeouts/keepalive for your final setup. - Convert any control scripts for Mecha Morphix into ARC JavaScript (I prefer JS over EZ-Script). Anything you want me to prepare first - wiring doc, skill settings checklist, or a simple control script for the five servos?

fxrtst · Answer

@Athena There is a robot skill that uses with the SSC-32, Would it be possible to connect a ESP32 wrover to the Ssc-32 via uart?  The one pictured below is $14 on eBay..looks like a Chinese knock off. But can’t the servos on the SSC-32 be controlled via Vxx ( virtual ports) in ARC?

Athena · Answer

Short answer: Yes - you can connect an ESP32 WROVER to an SSC-32 over UART and have ARC control the SSC-32 servos as virtual ports, but you need the right wiring, levelshift or voltage checks, and a bridge/firmware so ARC can talk to the SSC-32 over your chosen transport (USB serial, direct UART via a controller, or TCP over WiFi). Below I’ll give: - Two practical options (wired and wireless) - Wiring & power cautions (most important) - How to make the ESP32 act as a simple TCP UART bridge (example firmware) - How to expose SSC-32 servos to ARC as Vx (skill setup / kebab menu) - What I need from you if you want me to make a tailored firmware or skill configuration 1) Two practical ways to make this work - Option A - Easiest / most robust (wired) - Connect the SSC-32 to the PC (USB/serial) or connect SSC-32 to an Arduino/EZB that’s connected to ARC. ARC’s SSC-32 skill can then connect directly to the COM port. No extra firmware needed. - Use this method for development and verification. - Option B - Wireless via ESP32 (what you asked about) - Use the ESP32 as a serial bridge (WiFi UART). ARC connects (TCP) to the ESP32, ESP32 forwards bytes to/from the SSC32 UART. - Two ways to do the bridge: 1. Flash the ESP32 with Synthiam-compatible firmware (if you implement the exact protocol expected by the ARC robot skill - more work). 2. Use a raw TCP UART forwarder on the ESP32 (much simpler). ARC must be configured to talk raw to that TCP socket (or you use a robot skill that supports raw TCP to the servo controller). This is a practical wireless approach. 2) Wiring, signal levels, and power (critical) - SSC-32 serial lines are TTL-level serial. Check your exact SSC-32 board manual for the UART voltage (many are 5V TTL). The ESP32 is 3.3V logic - don’t assume 5V-tolerant inputs. - If SSC-32 TX is 5V and ESP32 RX is not 5V tolerant, use a logic-level shifter (bidirectional or unidirectional) between them. - If SSC-32 TX is 3.3V tolerant, you can connect directly (TXRX cross) but verify in the SSC-32 docs. - Cross the UART lines: - ESP32 TX -> SSC-32 RX - ESP32 RX  UART bridge (Arduino IDE) // - Adjust AP or WiFi credentials as needed. // - Set UART pins and baud to match SSC-32. // - Use appropriate level shifting for signal safety. #include  const char* ssid = "YourSSID"; // or create AP mode const char* password = "YourPass"; // set empty "" for open AP WiFiServer server(23); HardwareSerial &sscSerial = Serial1; // Serial1 on many ESP32 modules const int uartRX = 16; // ESP32 RX1 (change if needed) const int uartTX = 17; // ESP32 TX1 (change if needed) const int sscBaud = 115200; // set to your SSC-32 baud WiFiClient client; void setup() { Serial.begin(115200); delay(1000); // Init UART to SSC-32 sscSerial.begin(sscBaud, SERIAL_8N1, uartRX, uartTX); // Connect to WiFi (station mode) WiFi.mode(WIFI_STA); WiFi.begin(ssid, password); Serial.print("Connecting to WiFi"); int tries = 0; while (WiFi.status() != WL_CONNECTED && tries++ = 0) sscSerial.write((uint8_t)c); } // Forward from UART to TCP client while (sscSerial.available()) { uint8_t b = sscSerial.read(); if (client && client.connected()) { client.write(b); } } // tiny delay to yield delay(2); } ``` Notes on that sketch: - Change ssid/password or switch to AP mode as you prefer. - Change uartRX/uartTX pins to ones that work for your board. - Set sscBaud to the SSC-32 baud (confirm settings on your board). - This is a raw bridge. ARC must open a TCP socket to the ESP32 IP:23 and send SSC-32 command strings. If your SSC-32 ARC skill expects a COM port, ARC may not support connecting to a raw TCP socket for SSC-32 - read next section. 4) How ARC expects to talk to the SSC-32 and how to expose servos as Vx - ARC SSC-32 skill supports: - Direct COM/USB serial connection on the PC (recommended, simplest). - Connection via a controller with UART (EZ-B / Arduino) if you route serial through that controller. - Virtual Ports: - Once the SSC-32 skill is configured and connected, ARC exposes the SSC-32 channels as V0..V31 (virtual ports). Other ARC robot skills can then move Vx servos just like normal servos. - If you use the ESP32 TCP bridge above: - ARC’s SSC-32 skill may not have a built-in option to open a TCP socket. If it doesn’t, ARC won’t talk directly to the ESP32 TCP server unless you: - Expose the ESP32 bridge as a COM port on the PC (use a TCP->Serial driver on PC like com0com + com2tcp or socat on Linux to create a virtual COM linked to TCP), or - Modify/extend ARC skill to support TCP targets, or - Use a custom robot skill that speaks raw TCP to the ESP32 and forwards SSC-32 commands - then map Vx inside that skill. - Recommended approach for wireless with ARC: - Option 1 (less work): Connect SSC-32 to an Arduino/EZB that implements the custom servo controller firmware ARC expects. The Arduino/EZB handles UART to SSC-32 and ARC connects to that controller (wired or wireless). - Option 2 (intermediate): Run the ESP32 TCP bridge, then on the PC create a virtual COM port bound to that TCP server. ARC’s SSC-32 skill can connect to the virtual COM port. (Search for "COM over TCP" tools for your OS.) - Option 3 (best integration): Port the "Custom Servo Controller" firmware used by ARC to run on the ESP32 (modify the example Arduino firmware provided in the Custom Servo Controller docs). That firmware implements the protocol expected by the ARC skill so ARC will connect to the ESP32 as if it were the controller. The Custom Servo Controller docs include example firmware you can adapt. Link: https://synthiam.com/Support/Skills/Servo/Custom-Servo-Controller?id=22238 5) How to configure the SS C-32 or Custom Servo Controller skill (kebab menu steps) - Open your ARC project. - Add the SSC-32 Servo Controller skill (Project Add Robot Skill SSC-32 Servo Controller) or Custom Servo Controller skill. - Open the skill window, click the kebab/hamburger (three lines) in the top-right Settings. - Configure: - Connection Type: Direct COM (if using USB-to-SSC on PC) OR "UART through controller" (if going through EZ-B/Arduino). - COM Port / Baud Rate: match your SSC-32 settings (if direct COM). - If using Custom Servo Controller: select the Vx mapping (which servo channels map to V0..Vn). - Enable debug logging to see the raw commands. - Save, Connect. The skill should report connection and expose virtual ports V0..Vn for use by other ARC skills. 6) Troubleshooting checklist (if things misbehave) - Confirm common ground between ESP32 and SSC-32. - Confirm UART baud & parity match. - Use a logic level shifter if levels are mismatched. - Keep servo power separate and sized for stall current. Add bulk caps. - If ARC can’t connect to TCP directly, use a TCPCOM bridge on the PC or port ARC firmware protocol to ESP32. - Use the Serial Monitor on the ESP32 to watch incoming/outgoing bytes while you move a slider in ARC. - If you want me to adapt the Custom Servo Controller firmware to run on your ESP32 WROVER, tell me: - Desired max servos count (e.g., 16, 32) - SSC-32 serial baud - Whether you want the ESP32 to be AP or STA (connect to router) - Whether you want the ESP32 to implement EZB / Synthiam capability (more work) or just a raw TCPUART forwarder Follow-up questions for you 1. Do you want wired (COM) or wireless (WiFi) control for SSC-32 from ARC? 2. Is the SSC-32 UART 5V TTL or 3.3V TTL on your board? (Check the board or post the exact model text - I cannot see images.) 3. Do you want me to prepare a ready-to-flash ESP32 sketch that implements: - a raw TCP UART bridge (quick), OR - a port of the Custom Servo Controller firmware for ESP32 so ARC can connect directly over TCP (more integrated)? 4. Which baud rate is your SSC-32 set to? If you want the quick wireless route, I’ll finalize the ESP32 bridging sketch with AP mode and an example of how to create a virtual COM on Windows to let ARC use the SSC32 skill straight away.

fxrtst · Answer

If its within the guard rails of TCP then I would prefer it to be wireless. Can The ESP32 handle 32 servos via wifi?

DJ Sures · Answer

i am pretty sure athena is super confused with all the topics of this thread. whlie some of what she's saying is ok, it's not accurate.  a new thread would be useful becuase it's an entirely new topic. llm's are fancy auto-complete. and they gravitate toward a common subject/topic. humans have alot more ADHD than llm's haha. llm's benefit from single topic with single defined outcome. llm's work toward an outcome that's pre-defined. so this conversation has many outcomes and she's gonna give weird feedback. new threads are useful for situations like this. more threads is better than cluttered threads if u know what i mean so to answer what she kind of got right... the esp32 has a uart and it's exposed in the firmware as UART 0 in ARC. so YES you can use the ssc-32 manual and connect it to the uart pins of the esp32. verify with the firmware that your uart pins are exposed and usable

fxrtst · Answer

It makes since now to do these new threads for Athena. I can see some drifting. LOL. I often find it hard to come back to all these threads to find what I am looking for especially when many months go by. So like the old days I try and keep all the content for what I am asking or trying to do into one thread, but can see how its confusing for Athena.

DJ Sures · Answer

haha ya... llm's are sooooooo powerful when you wrap your head around how to use them. they speak so well that it's easy to take for granted that they're not humans. although, with llm's we learn to manage our projects and outcomes a lot clearer for other humans. i've noticed a benefit within synthiam's organization on how we clearly define outcomes rather than mushing them all together. it doesn't hurt to have lots of threads. honestly, there's nothing wrong with that. the forum is a place for discovery and problem solving. i learn a lot by reading the threads haha

fxrtst · Answer

Quote:Beginner note: ARC does not generate servo signals directly. ARC sends serial commands through a connection (USB/COM port or via UART from an EZB or Arduino), and the SSC-32 generates the servo PWM signals that actually move the servos.@DJ thanks for the update on the SSC32 skill and the detailed instructions!!! One last Q. If the ESP32 is not doing the heavy lifting but is just passing serial commands via UART 0, can the camera still operate at the same time? (if the esp isnt using the TX/RX pins for camera)?  ARC over wifi ----> ESP32 with camera-----> SSC32. (And by the way, all these similar controllers with their E's and 32's is making my dyslexic brain work hard )

DJ Sures · Answer

yup the camera will still work if the uart pins are not used for the camera

fxrtst · Answer

@DJ is the ESP32plus the new firmware for all ESP32s? There are so many flavors now I'm getting confused.

DJ Sures · Answer

Unfortunately, there is no such thing as ESP32 firmware (or any code for any ESP32 breakout board from anyone on earth) that works on all ESP32s. Anyone can make an esp32 breakout and change the pins as they wish. There is no standard in the DIY/opensource/hippy world. You will have to make any port changes necessary for your version. As documented in the ESP32 manual and firmware, you must change the ports in the INO file to match your schematic/version/breakout (or whatever it's called) that hosts the ESP32. The top of the INO file contains clearly labeled #define variables that need to be changed for your version.  [opt:hardware:18272]

fxrtst · Answer

I don't understand what ESP32 plus is? Just audio support?

fxrtst · Answer

Quote:Unfortunately, there is no such thing as ESP32 firmware that works on all ESP32sSorry, that's not was I was asking. What is the purpose of ESP32 PLUS vs the other firmware versions. Its confusing to me. Especially in the descriptions. If i am confused others might be.

DJ Sures · Answer

Firmware is a firmware that you load on hardware Hardware is hardware that you load firmware onto You can see the words "firmware" and "hardware" in your screenshot.

DJ Sures · Answer

This page might help you: https://synthiam.com/Support/Hardware/Hardware-Overview if you scroll down on that page, you'll see there's two types of esp32 hardware. there's one with a camera and one without. there's different firmware for each because the esp32 cameras are different. an esp32 with a camera is different than an esp32 without one. one has a camera and one doesn't have a camera so the pcb and schematic and firmware and everything is different

fxrtst · Answer

@Athena I am connecting the ESP32 Cam to SSC-32 controller. Can you tell me what UART to use in the SSC-32 Skill? The skill was updated to version 2 yesterday. Is this skill a download or is it just simply built into the newest version of Arc. There is no notation within the skill of what version it is.

DJ Sures · Answer

Athena can't see firmware or code that isn't posted. it's UART 0

DJ Sures · Answer

i updated the esp32 cam firmware description to specify UART0 is the UART used in arc // ---------------------------------------------------------------- // Serial Expansion UART Configuration (in ARC this is UART #0) // ---------------------------------------------------------------- // Serial2 RX (receive) port on the ESP32 #define SERIAL2_RX 12 // Serial2 TX (transmit) port on the ESP32 #define SERIAL2_TX 13

Athena · Answer

Short answer: use UART 0. Details and steps - The ESP32-CAM firmware (the Synthiam build) exposes the serial expansion on Serial2 which is mapped in the INO to: c #define SERIAL2_RX 12 #define SERIAL2_TX 13  ARC/your SSC-32 skill should use UART #0 to talk to that Serial2 port. In other words: in the SSC-32 skill choose the UART connection and set the UART index to 0. Wiring checklist (exact pins based on the firmware above) - ESP32 GPIO13 (SERIAL2_TX) -> SSC-32 RX - ESP32 GPIO12 (SERIAL2_RX)  SSC-32 GND (shared ground required) - Do NOT power servos from the ESP32. Power the SSC-32 servo rail from a proper external power supply. Skill configuration (step-by-step) 1. In ARC top ribbon: Project -> Add Robot Skill -> find and add "SSC-32 Servo Controller v2" (or open it if already in your project). Skill page: https://synthiam.com/Support/Skills/Servo/SSC-32-Servo-Controller-v2?id=23147 2. Open the skill settings (three-line/kebab menu on the skill window). 3. Set Connection Type to UART (or EZB UART depending on UI). 4. Set UART Index to 0. 5. Set the Baud Rate to match your SSC-32 hardware (check your SSC-32 docs - common rates are 9600, 38400, 115200). If unsure, check the SSC-32 board or its manual and set the same baud in the skill. Important notes & troubleshooting - Camera pin conflicts: some ESP32-CAM GPIOs are used by the camera. The Synthiam ESP32-CAM firmware chooses safe pins for the serial expansion (see the SERIAL2 defines), but if you have a different board revision you may need to change the #defines in the INO to match your board. See: https://synthiam.com/Support/Hardware/ESP32-Cam - If servos are jittery or the SSC-32 is unresponsive: check TX/RX crossing, shared ground, and that the servo power supply is adequate and properly connected. - If you changed the firmware pins, be sure the firmware's SERIAL2_RX/TX match the physical pins you connected. Is the SSC-32 skill built into ARC? - Robot skills are part of ARC and the latest versions are included in recent ARC updates or available from the Robot Skill Store: https://synthiam.com/Products/Controls - If you updated ARC recently you should have the SSC-32 v2 skill. If you do not see it, Add Robot Skill -> search the store/skills list. One more thing - I can’t view images posted here. If you pasted any text from a firmware screen or a board silkscreen, please paste the exact text (pin numbers, model name, or baud rate) and I’ll verify which pins to use and whether any conflicts exist. Would you like: - A plain wiring text you can copy into your course video notes? - Help checking which ESP32-CAM board variant you have (paste the board/model text) so we can confirm the safe pins?

DJ Sures · Answer

I think athena is confused because there's 24 pages of posts and the topic is all over the place. i'm gonna disable her for this thread because she's not providing any useful feedback. create new threads for questions to athena because that'll give her a nice clean empty slate to work from

fxrtst · Answer

Yeah good idea with Athena. The ESP32 connected to the SSC32 connects great. When the camera is on and I have a servo moving, there is quite a long lag in both the servo and the camera as can be seen in the video below. Kinda like we had at the beginning of the ESP 32 testing. With camera off servo moves perfect. (not seen in the video) 115200 baud all around. Same Freenove ESP32 Wrover we've been using. Newest ARC with this firmware:

DJ Sures · Answer

yeah most likely that's gonna happen because the scc-32 baudrate is super slow (115200bytes) vs (10mb+ or whatever) compared to the speed of the ezb wifi protocol. like all things, you're limited to the slowest part of the assembled components. you should probably use a firmware like esp32plus and offload the camera to another esp32 you guys keep saying "ezbv4 has an old micro etc etc" but you're forgetting the ezbv4 micro is 10 times what the esp32 is. the esp32 is $1 because it's super duper lightweight. you're expecting a lot from it. comparing a monster truck to a pedal bicycle lol

Synthiam Support · Answer

What firmware and version are you running btw?

Synthiam Support · Answer

Oh, and also the Arduino serial monitor shows you log information if something weird is happening.

DJ Sures · Answer

Yeah good point - Will's firmware could be older, he didn't specify. Will what version and firmware are you using on the esp32cam? I tested on my bench here and there's no camera delay or servo delay. Seems to work pretty good here even with the low baudrate of the UART0

DJ Sures · Answer

oh yeah re-read the post and he did specify it's v12 in an edit. that's the latest.  maybe something's browning out? maybe the incorrect camera is specified in the #define? not sure

DJ Sures · Answer

Did you verify that your board and library versions also match what's in the INO file before uploading the firmware?  Compiling Instructions: - This was designed with.... Board: ESP32 by Espressif Systems Version 3.3.7 Library: ESP32Servo by Kevin Harrington Version 3.1.3

DJ Sures · Answer

Athough i do see it happen with the servo pad vs horizontal servo control. looks like the two tasks running on each core can't keep up. maybe yeilding the task while transmitting the uart or something might help. the esp32 is such a peice of #$#$@

fxrtst · Answer

Sorry fellas was away for dinner. Yeah I noticed the same thing with the slider vs servo pad. Yeah sorry the ESP32 is a piece of do-do. But its incredible what you've done in such a short time with the ESP32 series of boards. This was a big ask with the SSC32 as it would create a wireless Mega EZB..lol. I can still do the ole ESP32 camera separate and another ESP32 connected to the SSC32, if i can make room. EDIT: the libraries strikes again, i checked against my compile and using the wrong version ESPressif ...updating now. EDIT #2 updated libraries and it actually seems to shudder more on the servo but a bit better on the camera frame rate.. Maybe Lynxmotion needs to update the SSC32. This card is 9 years old. A faster baud rate would help. I'll look and see if Ali express has something more upto date based on the SSC32.

fxrtst · Answer

..ok there are several faster chips sets but the baud rate remains the same 115200 max. And the prices starts to go up too.

DJ Sures · Answer

Okay, I just spent the whole night rewriting the ESP32CAM firmware... here it is [opt:firmware:20265] 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 the hardware peripheral. - 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 A) more esp32's chained together B) a different micro that costs more and has more power C) 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.

fxrtst · Answer

First of all thank you for all the time spent on this. We all owe you a beer or 10. Absolutely think you are on the right path. We are trying to make them do to much. So make each one a unit performing a task like a cluster. They are so fricking cheap and so are the servo controllers. I’m all on board with this I’ll give the new firmware a spin in the morning! Again thanks!

DJ Sures · Answer

Haha I’ll take the beers thanks.  did you try v13? Did it make a difference? [opt:firmware:20265]

fxrtst · Answer

Ran out of time last night. Will test today after I drop off my kids to school.

fxrtst · Answer

No rush on this at all. Just getting around to trying ver 13. * ESP32-Cam (ver 13) * ARC ver 2.19.01 * SSC-32 - After I connect to the ESP32, I can move a servo on the SSC-32 - After I connect camera frame is frozen and camera drops with error message in the video. (new) - The connection to the ESP 32 soon after drops as well. (new)  ARC error message is a s follows: Connected TCP Comm Error: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. Sent: 4 6 9 0 35 48 80 49 52 57 52 13 10 Bytes Expected: 0 Received (0 bytes): Disconnected