About Zone Robotics

Fifteen years.
One platform.

A senior project became a hobby, the hobby became a long line of prototypes, and the prototypes eventually became something worth shipping. This is how a modular ESP32-S3 robotics platform came out of fifteen years of chasing the same idea: open a web page and drive.

THE JOURNEY / 01

It started as a senior project.

As a computer engineering grad student, our final project was a small tracked robot that could follow a line, stream video, run headlights and pick up magnetic objects with an electromagnet. Drive it with a remote, rescue the target. Fun.

Fifteen years ago that meant two separate systems: one to control the robot, another to capture the video. A weird analog receiver, a computer to convert it, 433 MHz for control, UART commands back and forth. By the time we shipped I knew this was what I wanted to keep building.

What kept the idea alive was remote presence. Could you make a robot that somebody thousands—or millions—of miles away could drive to do mundane things? Playing Doom and Quake as a kid shaped how I thought about it. Controlling something in a remote environment is fun on its own. You can't see everything, you don't always know what will happen. That unpredictability is what makes it interesting.

Fifteen years of Zone Robotics prototypes and experiments — Fifteen years of prototypes, dead ends and lessons learned.

PROCESSING / 02

The chip search.

Before the ESP32 existed I ran through PIC microcontrollers and landed on the STM32F4 Discovery. That board was amazing at the time — cheap, easy to extend with a stacked add-on board for motors and hardware. I built a compact command protocol, Modbus-inspired: [function] [subfunction] [data]. Fast and easy to memorize, obvious limits once payloads got complex. That led to Protocol Buffers.

Then Raspberry Pi, Orange Pi and WRTnode changed the landscape. The Pi Zero at $5 ran Linux and a web server — huge. We designed a custom STM32F4 board with power management and motor control on it, but each board cost around $100 to make and camera ribbons, antennas and Wi-Fi kept becoming their own problems. The Pi version worked, but camera drivers were fragile — a version bump could be the difference between real-time video and nothing.

We built a WRTnode robot too. If you search YouTube for "wrtnode robot", some of those results are ours. Interesting board — Linux, routing, firewall built in — but similar version churn and it never grew a Pi-sized community. The $5 Pi Zero was almost always sold out; new SBCs kept appearing in different form factors. Complexity kept piling up.

The ESP32-S3 Sense from Seeed Studio finally felt just right. Fast, robust, onboard battery charger, camera, microphone and PSRAM. Enough compute for HTTPS + camera streaming + everything else. Plenty of GPIO. You can even run small AI models directly on it. Not affiliated with Seeed — just genuinely like their hardware.

MECHANICAL / 03

From clunky to LEGO Technic.

Over the years we've built tracked robots with Pololu kits, Tamiya kits, LEGO tracks and plenty of custom designs. LEGO-compatible tracks won — the other systems worked but were expensive and came with parts we didn't need.

We tried a lot of shapes. Some were large and clunky. Some had aluminum enclosures — great looking, terrible for Wi-Fi. Some used precisely laser-cut acrylic that fit together beautifully (Inkscape does great work here). We built one WRTnode design that couldn't stay upside down — its tracks were arranged in a triangle, WALL-E style, and the camera section could rotate. Interesting, but a lot of moving parts.

Today we favor simple. More parts means more things break. Simpler designs are easier to understand, build, repair and modify. We settled on car and tank reference builds and left the rest of the shape open to whatever you can put together with LEGO Technic.

SOFTWARE / 04

Open a web page and drive.

We started with Windows MFC and C. Moved to Java + Swing with a topic/subscriber server. Solid, fast, historical data, hooks for Python — but it looked like a Java app and users had to install and configure it. Wrong Java version and you're done.

Android next. Phones were finally powerful enough. New Android versions every few months, per-device testing, Play Store maintenance — and the obvious question: what about iPhone users? What about someone on a laptop?

That's when I gave up on native apps entirely. Web was the only answer. Locally we use WebSockets and low-latency streaming for a highly responsive drive. Across the internet we use WebRTC for near-real-time video. Same goal either way — open a web page and drive.

THE BUILDING BLOCKS / 05

The chips we kept.

Every project needs the same handful of things: power, motor control, servo control, GPIO, and a way to bolt on more hardware. Power was the hardest early on — most PMICs were designed for phones and expensive with a pile of passives. For smaller projects, overkill.

We settled on the IP5306 for power. Cheap, simple, charging and battery indicator built in, eight-pin package, few external components. Perfect fit for a platform like this.

For servos we started with direct GPIO. When we hit an eight-servo spider-like walker the ESP32-S3 ran out of pins for everything else. Enter the PCA9685. Normally used for PWM LED control, but excellent for servos too — fine-grained, cheap, easy to solder, well established. It also introduced the bigger idea we run with now: I²C expansion. Plug a module in, connect to the bus, go. The robot is an old computer — instead of PCI, it's I²C.

For motors we tried L298 (heat-sinks needed, inefficient), L9110 (works, easy to burn on overcurrent) and landed on the DRV8833. Robust, efficient, handles the voltages we need, easy to source, easy to solder. Those are the qualities we pick on.

CAMERAS + COMMS / 06

Getting the video out.

Cameras haven't changed as dramatically as the rest of the hobby. We started with the OV2640. The newer ESP32-S3 Sense boards ship with the OV3660 — solid upgrade. Back in the STM32F4 days we interfaced directly with the camera's DCMI: HSYNC per line, VSYNC per frame. Raw RGB isn't practical for real-time, so we told the camera to output JPEG and worked from there.

A favourite trick: the JPEG comment field. Instead of a separate telemetry channel, we stuffed GPIO state, servo positions, speed and sensor data into the JPEG comment. Telemetry rode along with the video. You could play back an MJPEG recording later and see not just what the robot saw, but what its hardware was doing at the time.

For streaming we spent time with HC-05 Bluetooth (~700 kbps, ~11 fps with a double-buffered interrupt-driven camera pipeline I'm still a bit proud of), then ESP8266 for Wi-Fi, then landed on the ESP32-S3 for the whole thing. The S3 also has ESP-NOW — fast, long-range peer-to-peer — which opens up base- station-plus-robot architectures we plan to explore.

THE QUESTION / 07

What should the robot be?

Initially I wanted something you could build by gutting a cheap RC car and driving it from your phone. Then I wanted video. Then I could never settle on a single shape — locking versatile hardware into a fixed shell always felt like a waste.

"If only it had this..." "What if I added that..." "This new chip is better and cheaper..." That's why I kept building new versions.

First I thought the platform should support three types — a car, a tank, a WALL-E-style walker. Then: why stop at three? LEGO Technic compatibility means users can build almost anything. A car and a tank are our reference builds; the rest is whatever you can put together — pet feeders, walkers, excavators, tractors, monitoring rigs, something entirely new. The hardware is a platform. What you build with it is up to you.

THE SHORT VERSION / 08