A Wi-Fi-controlled 6-DoF robotic arm with custom firmware and a browser-based controller.
Started in 8th grade as a return to an old LEGO question — instead of assembling a kit, I built the mechanics, wrote the firmware, and programmed the controls myself.
In sixth grade, I built a grabber out of LEGO. It could reach and grip, but it couldn't really bend. That bothered me more than it probably should have — years later I still wanted a better answer to that one small missing joint.
In between came the basics: a blinking LED to start, then sensors, an Arduino car, and a first web page that could control servos from my phone.
In 8th grade I came back to the original question — instead of only asking how to build something similar, I decided to build the whole system myself: the mechanics, the electronics, and the programming.
The main controller is an Arduino UNO R4 WiFi, connected over I²C to an Emakefun Motor Driver V5.2 at address 0x60, which drives eight TD-8120MG servos — a six-degree-of-freedom arm plus a gripper, with one twin support servo on the lift.
The firmware is written in C++ for the parts that make it feel like one machine: per-servo offsets to fix horns that never sat perfectly straight, speed control, S-curve motion so joints glide instead of snap, a reset, and an emergency stop.
The browser controller is plain HTML, CSS, and JavaScript. It is the entire interface — no pre-built robotics app — and it talks to the UNO over Wi-Fi.
After a fried board, a missing I²C device, and strange servo channels, I stopped changing code until something worked and started collecting evidence instead.
When the motor driver went quiet, the answer was a small test, not more changes to the main program. I wrote a tiny I²C scanner — it found the board exactly where it was supposed to be, at address 0x60.
The same method caught the servo-horn misalignments too: one assumption at a time, then software offsets to calibrate each servo individually instead of repeatedly rebuilding the joints. Wire-by-wire checks along the way did the rest of the teaching.
Every command follows one path through the system — simple on purpose, easy to trace when something goes wrong.
A browser interface I wrote in HTML, CSS, and JavaScript sends the command — from a phone or laptop, over Wi-Fi.
An Arduino UNO R4 WiFi receives it and runs my motion-control firmware.
Over I²C, the UNO drives an Emakefun Motor Driver V5.2 at address 0x60, which powers all eight servos.
The servos move the base, arm, wrist, and gripper while the firmware handles calibration, speed, and smooth motion.
The control path is simple: Browser → Wi-Fi → Arduino UNO R4 WiFi → I²C Motor Driver → Servos → Robotic Arm.
Moving is not the same as seeing — the distinction between the two lists above matters, and I expect to keep updating it as the vision work progresses.
None of this came from a tutorial. It came from testing things one at a time until guessing stopped being an option.
A tiny I²C scanner, one servo brought up alone, each channel and assumption checked separately — every tangle that stopped me was really three smaller problems stacked on top of each other.
Some servo horns were slightly misaligned. Instead of rebuilding the joints over and over, I added software offsets so each servo could be calibrated individually.
The hardest part was not making one servo move. It was getting mechanics, electronics, firmware, Wi-Fi, and the browser interface to work together reliably.
The arm that works today is still far from the arm I first imagined. Saying that out loud keeps the next steps honest — and the next steps real.
Next: finish the Vision AI exploration, then keep exploring how the arm can do simple tasks with less help from me — one testable step at a time. In parallel, a clear bench photo of the arm goes on this page.
I wrote these two notes during — and right after — the hardest stretch of debugging on Ashtavakra.
I started with a LEGO grabber that could not bend. A few years later, I was building my own Wi-Fi-controlled robotic arm, writing the firmware and web controller, and learning that the hardest part of robotics is often everything between "it moves" and "it works well."
I started by changing code until something worked. After a fried board, a missing I2C device, and strange servo channels, I learned a better way to solve: isolate one problem, test one assumption, and collect evidence before changing anything.