TCP Script Server Raw icon TCP Script Server Raw TCP server for ARC accepting EZ-Script, JavaScript or Python commands, letting controllers send commands and receive line-terminated responses Try it →
Asked

ESP32 CAM ADC Jitter With PWM Servo Feedback

Using an ESP32-CAM (AI Thinker) flashed with the Synthiam firmware as my EZ-B over Wi-Fi (client mode), I’m trying to get positional feedback from a modified MG996R into ARC with the PWM servo Feedback (ADC) skill while also streaming video via the Camera Device. The servo signal is on D5 and the feedback wiper goes through a divider to an ADC D-port: 5.1k in series to the ADC pin, then 10k from ADC to GND (common ground with the 5V servo rail), plus a 0.1 F cap to ground for smoothing. In the skill I selected the corresponding ADC port and did Auto-Calibrate.

Symptoms: with the Camera Device streaming, the ADC value in the skill jitters wildly 0-4095 or flatlines near max. If I pause/disable the camera skill (or disconnect video), the readings become much more stable and track the servo position as expected. I’ve tried moving the ADC to different D-ports, separate 5V supply for the servo (grounds tied), AP vs client Wi-Fi, and adding a bit more RC filtering. Same behavior. A quick JavaScript loop shows the issue too:

while (true) {
  var v = getADC("D14");
  print(v);
  sleep(100);
}

I’m aware some ESP32 ADC channels don’t play nicely with WiFi, and the ESP32-CAM also ties up a lot of GPIO for the camera module. For anyone who has this working: which D ports in the ESP32-CAM firmware actually map to ADC1 channels that remain usable with WiFi active, and is there a proven wiring/calibration approach to make the PWM servo Feedback (ADC) skill stable while the Camera Device is streaming?



Related Hardware (view all EZB hardware)
ESP32 Cam by Espressif
ESP32-CAM as an EZB for Synthiam ARC: stream video, control GPIO/servos, AP/Client WiFi, and ARC D0-D23 to GPIO pin mapping.
Wi-Fi
Servos Varies
Camera
Audio
UART Varies
I2C
ADC Varies
Digital Varies

Related Robot Skills (view all robot skills)
Camera Device by Synthiam
Use PC or robot cameras for vision tracking: color, QR, glyph, face, object, motion; record video/data, control servos and movement, run scripts
Add ADC positional feedback to hobby PWM servos via minor mod to EZ-B/Arduino; enables real-time position readout, calibration and puppet mirroring

ARC Pro

Upgrade to ARC Pro

ARC Pro is more than a tool; it's a creative playground for robot enthusiasts, where you can turn your wildest ideas into reality.

Author Avatar
PRO
Canada
Twitter YouTube GitHub
#1  

Yes - what you’re seeing is very consistent with the ESP32 ADC/Wi-Fi interaction, not just ARC or the camera skill.

Short answer

For an ESP32-CAM with Wi-Fi active, you want to use ADC1-only pins.
ADC2 pins are not reliable while Wi-Fi is running, and the camera stream can make the timing/noise problem look even worse.

On the ESP32 family, the safe rule is:

  • Use ADC1 channels only
  • Avoid ADC2 entirely when Wi-Fi is active

Why it happens

Your setup has two stressors at once:

  1. Wi-Fi/video streaming
  2. Analog feedback reading

On ESP32, ADC2 is shared with Wi-Fi hardware, so readings can become:

  • noisy
  • stuck high
  • erratic
  • randomly near 0 or 4095

That matches your symptoms exactly.

What to use on ESP32-CAM

For the common AI Thinker ESP32-CAM, the practical ADC1 candidates are limited because many GPIOs are already used by the camera, flash LED, SD slot, or boot functions.

In general, the ADC1-capable GPIOs are:

  • GPIO32
  • GPIO33
  • GPIO34
  • GPIO35
  • GPIO36
  • GPIO39

But on the ESP32-CAM board, not all of those are conveniently broken out or safe to use.

Important note

Synthiam ARC ports on this firmware are mapped to GPIOs by the firmware, so the exact D-port to GPIO mapping depends on the ESP32-CAM firmware build and board model config.

You’ll want to verify the pin mapping in the ESP32-CAM firmware notes here:

Best practical recommendation

For stable feedback with Wi-Fi and video running:

  • Use an ADC1 pin only
  • Prefer a pin that is:
    • not used by the camera module
    • not used by boot strapping
    • not used by the flash LED or SD circuitry

If your current D14 maps to an ADC2-capable GPIO, that would explain the instability.

What I’d try first

1) Confirm the D-port maps to ADC1

Check the firmware’s port mapping for the AI Thinker build and pick a D-port that maps to one of these ADC1 GPIOs:

  • 32
  • 33
  • 34
  • 35
  • 36
  • 39

2) Don’t use getADC("D14")

In ARC JavaScript, use the port constant directly when possible, not a string.

Example:

while (true) {
  var v = ADC.get(D14)
  print(v)
  sleep(100)
}

If you’re using a port that the firmware maps to a bad ADC channel, the syntax won’t fix the underlying issue, but this keeps the command aligned with ARC constants.

3) Slow the sampling a bit

If the servo feedback is mechanically noisy, sample at 50-100 ms instead of faster.

4) Add software filtering

Even with the right pin, servo feedback pots are inherently noisy. A simple moving average helps a lot.

Example JavaScript smoothing:

var samples = []

while (true) {
  var v = ADC.get(D14)
  samples.push(v)

  if (samples.length > 10)
    samples.shift()

  var sum = 0
  for (var i = 0; i < samples.length; i++)
    sum += samples[i]

  var avg = Math.round(sum / samples.length)
  print(avg)
  sleep(100)
}

Wiring notes

Your divider/filter idea is reasonable, but a few cautions:

  • Keep the servo power separate from the ESP32-CAM supply if possible
  • Common ground is required
  • Ensure the feedback wiper never exceeds the ADC input range
  • On ESP32, ADC behavior is often better with:
    • a small series resistor
    • a capacitor to ground
    • clean 3.3V-reference-friendly scaling

Also, the ESP32 ADC is generally less linear and more finicky than an AVR or many other controllers.

Best long-term solution

If you need video streaming + stable analog feedback + servo control at the same time, the ESP32-CAM is often not the best board for the analog feedback job.

A more reliable architecture is:

  • ESP32-CAM = camera + Wi-Fi + robot control
  • Separate EZ-B / controller with better ADC behavior = feedback sensing

Or use a digital feedback servo driver / smart servo solution if you want cleaner positional data.

ARC works very well when the underlying hardware provides stable feedback.

If you want to keep this on the ESP32-CAM

Then the key is:

  1. Use ADC1-only pins
  2. Verify the firmware port mapping
  3. Avoid ADC2 pins entirely
  4. Filter in software
  5. Minimize servo power noise

Follow-up question

If you paste the exact D-port mapping from your ESP32-CAM firmware or your firmware #define pin table, I can help identify which specific ARC ports are ADC1-safe on your build.


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