UNO Q vs ESP32.
SHOULD THE NEW DUAL-BRAIN ARDUINO REPLACE THE ESP32 AS HEXAPOD CONTROLLER?
01 · What the Linux side actually does
The whole point of UNO Q is a split: a slow-but-deterministic STM32U585 Cortex-M33 handles real-time servo PWM, IMU sampling, and emergency stop. A fast Linux box (4× Cortex-A53 @ 2 GHz, Debian, 2–4 GB RAM) sits next to it and handles everything that doesn't have to be late-free.
Real-time hands
Latency-critical loops. Cannot afford to skip a beat.
50 Hz servo PWM × 18 IMU @ 200 Hz Ultrasonic ping LiPo voltage watch Emergency stop Low-level safetyThinking brain
High-level logic. Can take 100 ms and nothing breaks.
IK math in Python/numpy OpenCV on MIPI camera TensorFlow Lite inference Companion site on the robot Tailscale node SSH + journalctl logging Edit-restart, no flashing Voice / wake-word Disk-persistent gait recordings ROS2 if you go thereThe two halves talk over a built-in bridge. Linux says walk_forward(200mm); MCU turns that into 18 servo trajectories.
02 · The board, briefly
- MPU side Qualcomm Dragonwing QRB2210, 4× ARM Cortex-A53 @ 2 GHz, Debian Linux, 2 GB or 4 GB LPDDR4X, 16 GB or 32 GB eMMC.
- MCU side STMicro STM32U585, ARM Cortex-M33 @ 160 MHz, 2 MB flash, 786 KB SRAM. (For comparison: ESP32 has ~520 KB SRAM.)
- I/O MCU pins at 3.3 V (ADC, PWM, Qwiic) — what you'd use for sensors and servos. MPU pins at 1.8 V, mainly for MIPI camera, MIPI display, audio.
- Price $44 USD for 2 GB / 16 GB. $59 USD for 4 GB / 32 GB. ~R1500–R2000 landed in SA
03 · For vs against, side by side
- It's the textbook hexapod architecture Hard real-time servo loop on one chip, high-level brain on another. You'd build this split anyway with two boards — this one is in a single package.
- MCU side alone outclasses ESP32 Cortex-M33 @ 160 MHz, hardware FPU, DSP extensions, 786 KB SRAM. IK math is faster and cleaner than on ESP32.
- Python + numpy + OpenCV natively Your inverse kinematics becomes a few lines of matrix math. Camera vision becomes possible.
- MIPI-CSI camera vs ESP32-CAM A real video pipeline, not MJPEG over WiFi. Phase 4 (FPV) and Phase 5 (vision/autonomy) become substantially more capable.
- Companion site can run on the robot Next.js on the A53 cores. Hit http://hexapod.local from anywhere. Mac Mini drops out of the loop.
- STM32U585 may drive 18 PWM directly Could eliminate both PCA9685 modules and the Qwiic chain — minus ~R160 from the BOM.
- Real iteration loop SSH in, edit a Python file, restart a systemd service. No compile-flash-reboot. journalctl instead of Serial.print.
- Power draw is ~5–8× ESP32 Quad A53 + Debian: 2–4 W idle vs ~0.5 W for ESP32. With 18 servos already on a 2S 3300 mAh LiPo, this eats into runtime and may need a larger BEC.
- GPIO is split-voltage and confusing MCU pins are 3.3 V (servos, sensors). MPU pins are 1.8 V and dedicated to MIPI/audio. Less freedom to repurpose than it first looks.
- Bridge latency is unproven Fine for tripod gait at 2–4 Hz step rate. Possibly an issue for closed-loop balancing at 200 Hz — no public characterizations yet.
- Ecosystem is brand new The three hexapod firmware bases you'd fork (marcuscw, rasheeddo, SmallpTsai) are all ESP32-Arduino. Port is doable, but it's real work.
- SA availability Just announced — PiShop / Micro Robotics likely don't stock it. International order + customs is 4–6 weeks and ~20% on top.
- Spec, plan, BOM, pin maps already built around ESP32 Switching invalidates a chunk of documents 03 / 04 / 07 and the wiring diagrams. The companion site stands.
- Two weeks from walking → two months from walking Realistic schedule cost. Unfamiliar Linux+MCU split + new firmware port + sourcing delay.
04 · Recommendation
This build: stick with ESP32. The plan is written, reviewed, and shippable. You are about two weeks from a walking robot. Switching trades a known path for an unknown one.
The next revision (or Phase 4 / Phase 5 upgrade): UNO Q is a strong target. That's exactly when ESP32 starts to hurt — vision, on-robot AI, real telemetry.
Bake the option in: add UNO Q as an entry on the /alternatives page next to the ESP32 controller decision. Set the upgrade trigger as "when Phase 4 FPV or Phase 5 autonomy starts hitting ESP32 memory or compute walls."