YukiBotLab
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)
Related Robot Skills (view all robot skills)

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:
Why it happens
Your setup has two stressors at once:
On ESP32, ADC2 is shared with Wi-Fi hardware, so readings can become:
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:
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:
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:
2) Don’t use
getADC("D14")In ARC JavaScript, use the port constant directly when possible, not a string.
Example:
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:
Wiring notes
Your divider/filter idea is reasonable, but a few cautions:
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:
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:
Helpful links
Follow-up question
If you paste the exact D-port mapping from your ESP32-CAM firmware or your firmware
#definepin 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.