Alternative To Ezrobot Ezb For Robot Head Project

@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.

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

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

// UDP servo Test for ESP32 DevKit v1 (LEDC PWM, no servo library)
#include <WiFi.h>
#include "esp_wifi.h"
#include <WiFiUdp.h>

#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 << LEDC_RES) - 1);
  if (dutyf < 0) dutyf = 0;
  if (dutyf > ((1UL << LEDC_RES) - 1)) dutyf = ((1UL << LEDC_RES) - 1);
  return (uint32_t)dutyf;
}

void setup() {
  Serial.begin(115200);
  delay(200);

  // Init LEDC PWM
  ledcSetup(LEDC_CHANNEL, LEDC_FREQ, LEDC_RES);
  ledcAttachPin(SERVO_PIN, LEDC_CHANNEL);

  // WiFi
  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) < 20000) {
      delay(200);
      Serial.print(".");
    }
    Serial.println();
    Serial.print("STA IP: ");
    Serial.println(WiFi.localIP());
  }

  // Disable WiFi power save to avoid TX aggregation latency
  esp_wifi_set_ps(WIFI_PS_NONE);

  udp.begin(UDP_PORT);
  Serial.printf("UDP listening on %d\n", UDP_PORT);
}

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 "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\n", packetBuf, pulse, duty);
    }
  }
}

PC test client (Python) - measures RTT

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.

@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.

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.

// 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,<millis>"

#include <WiFi.h>
#include <WiFiUdp.h>
#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 << LEDC_RES) - 1));
  if (dutyf < 0) dutyf = 0;
  if (dutyf > ((1UL << LEDC_RES) - 1)) dutyf = ((1UL << LEDC_RES) - 1);
  return (uint32_t)dutyf;
}

void setup() {
  Serial.begin(115200);
  delay(100);

  // WiFi
  if (USE_AP) {
    WiFi.mode(WIFI_AP);
    WiFi.softAP(ap_ssid);
    Serial.print("AP IP: ");
    Serial.println(WiFi.softAPIP()); // default 192.168.4.1
  } else {
    WiFi.mode(WIFI_STA);
    WiFi.begin(sta_ssid, sta_pass);
    Serial.print("Connecting to STA ");
    unsigned long t = millis();
    while (WiFi.status() != WL_CONNECTED && millis() - t < 10000) {
      delay(200);
      Serial.print(".");
    }
    Serial.println();
    if (WiFi.status() == WL_CONNECTED) {
      Serial.print("STA IP: ");
      Serial.println(WiFi.localIP());
    } else {
      Serial.println("Failed to connect to STA");
    }
  }

  // Disable WiFi power save to reduce latency (aggregation)
  esp_wifi_set_ps(WIFI_PS_NONE);

  // Setup LEDC for servo
  ledcSetup(LEDC_CHANNEL, LEDC_FREQ, LEDC_RES);
  ledcAttachPin(SERVO_PIN, LEDC_CHANNEL);

  // Start UDP
  udp.begin(UDP_PORT);
  Serial.printf("UDP server started on port %d\n", UDP_PORT);
}

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 "0,1500"
    int comma = s.indexOf(',');
    if (comma > 0) {
      int pulse = s.substring(comma + 1).toInt();
      if (pulse < 500) pulse = 500;
      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\n", 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.

# 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?

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.

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.

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)