DelftTinkr
I’m running ARC on a Windows laptop and using a Raspberry Pi 4 over Wi-Fi as my EZB server (DJ’s EZBPi image). The Pi handles a PCA9685 for 12 servos and an MCP3008 for battery sensing on A0. To troubleshoot laggy servo twitches during moves, I added the Benchmark skill and set it to Read ADC on A0. Over Ethernet, the Benchmark reads per second sit solid around 380-410 with almost no drops, but over 5 GHz Wi-Fi I see 150-220 with periodic dips to near 0 for 200-500 ms every 10-30 seconds. Those dips line up with small servo twitches in Auto Position sequences.
What I’ve tried: moved the Pi within 2 m of the access point; switched between 2.4 and 5 GHz; dedicated SSID for the robot; disabled camera streaming in ARC (when Camera Device at 320x240 15 fps is on, the dips get worse; off reduces but doesn’t eliminate them); disabled Wi-Fi power save on the Pi (iw dev wlan0 set power_save off); checked CPU (5-25% on the Pi, 10-20% on the PC); changed the router channel; and tested with only Benchmark connected (no other skills) vs a fuller project (Auto Position + Camera + Speech Synthesis). Ping from PC to Pi is stable at 5-7 ms with no loss even when Benchmark dips.
It feels like small bursts of latency/packet buffering on the EZBPi side, but I’m not sure if there are ARC connection options, EZBPi tweaks, or wiring changes (e.g., moving the MCP3008 to shorter SPI leads, adding ferrites near the Pi/PCA9685) that would help; before I move the I/O to an ESP32 as the EZB and use the Pi just for ARC, is there a recommended way to stabilize Benchmark over Wi-Fi on EZBPi without disabling the camera stream entirely?
Given this setup, what specific ARC or EZBPi settings or wiring changes would you recommend to stabilize the Benchmark reads per second over Wi-Fi without resorting to Ethernet?
Related Hardware (view all EZB hardware)
Related Robot Skills (view all robot skills)
Yes - the pattern you’re describing sounds much more like Wi-Fi latency/jitter bursts than an ARC benchmark problem or a pure CPU bottleneck.
A few things stand out:
That combination usually means the Pi is being interrupted briefly by network buffering, Wi-Fi contention, or the way the EZB server and camera traffic share resources.
What I’d recommend, in order
1. Keep the camera off the Pi Wi-Fi path if possible
Since camera streaming makes the dips worse, the best fix is usually to avoid sending video over the same Wi-Fi path as control traffic.
Options:
Even though ping stays good, video traffic can still create short bursts that affect control traffic.
2. Use the Benchmark as a symptom test, not the root cause
The Benchmark skill is useful here because it shows the comms stalls clearly, but the actual issue is likely the EZBPi server’s response timing under Wi-Fi load.
ARC Benchmark docs:
3. Check whether the Pi is running any background network services
On Raspberry Pi-based EZB servers, I’d look for:
If DJ’s EZBPi image has service options, disable anything not required for the robot test.
4. Shorten and clean up the local wiring on the Pi side
Your idea about wiring is reasonable, especially for the MCP3008 and PCA9685.
For the Pi side:
What I’d prioritize:
Ferrites can help in some builds, but I’d treat them as a secondary fix after power/wiring cleanup.
5. Verify the servo power supply is not causing Wi-Fi brownout noise
Even if the Pi itself isn’t rebooting, servo current spikes can inject noise into:
If the servos are on the same supply path, try:
This is a very common cause of "random twitches" that look like network hiccups.
6. In ARC, reduce anything that causes burst traffic
If the robot behaves better when you disable extra skills, that’s a clue.
Try:
7. Test Wi-Fi on 2.4 GHz as well as 5 GHz, but favor stability over speed
You already tested both, which is great.
In robotics, 5 GHz is not always better if the AP has short burst buffering behavior or if the client has weaker signal handling under load. Sometimes a clean 2.4 GHz link is more consistent for control traffic, even if slower.
8. If the Pi is acting as both EZB server and video source, that’s the main architectural limit
Honestly, the setup you’re pushing is right near the edge of what I’d expect to stay perfectly smooth over Wi-Fi with servo control plus video.
If you want the most robust setup, Synthiam’s own guidance for Raspberry Pi robotics usually favors:
That doesn’t mean you must switch immediately, but it is the cleanest long-term solution if smooth servo motion is the priority.
Raspberry Pi support page:
Best practical fixes to try next
If I were tuning your setup, I’d do this sequence:
About ARC settings
For this specific issue, there isn’t usually an ARC checkbox that fixes Wi-Fi burst latency on an EZB server. The big wins are usually:
A couple of questions that would help narrow it down
If you want, I can also help you build a minimal ARC test project to isolate whether the jitter is coming from:
The ARC AI Assistant inside ARC can also help rewrite or simplify your test scripts quickly if you’re adjusting polling or auto-position logic: https://synthiam.com/Products/AI-Assistant