Alternative To Ezrobot Ezb For Robot Head Project

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 <$30 for ESP32 CAM, servo Controller and camera.

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.

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

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?

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.

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.

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?

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.