Stepping Aside: My Intensive Robotics Primer

By Rob Bercik | September 25, 2026

The Software Paradox

I identify as a "software guy." For a quarter-century, I've been writing code, but the last nine months have been a revelation. I've pivoted entirely toward LLM-driven development, and the results have been staggering: I have produced more software in the last nine months than in the preceding 25 years combined.

Currently, my personal GitLab is home to 41 projects. Most aren't just experiments; they are functional products utilized by myself, my friends, and my family.

However, this productivity surge brought a strange side effect: intangibility. When discussing my work with non-technical people, the profound shift in our world—the reality that we are living in a different era than we were a year ago—seems to go unnoticed. I particularly wanted my children to grasp this transformation. We attempted some game development, but they were more interested in playing the games than coding them. To bridge this gap, I decided they needed something they could physically touch and see.

The solution? A robot arm.

The Hardware Stack

Because my free time is limited, I opted for convenience over a "from-scratch" build. I purchased a preassembled, 3D-printed LeRobot SO-101 kit.

Budget Breakdown

Item	Description	Cost
SO-101 Kit	Preassembled arm + batteries	$415
Webcam	Additional overhead reference point	$50
Raspberry Pi 3	Found in a drawer (8 years old)	$0
Total		$475

Note: If you possess the patience and time, you could certainly assemble this for significantly less. I simply couldn't be bothered to build it myself until I proved it could actually do something useful.

Initial Configuration

The project began with a trip through my old electronics drawers. I unearthed a Raspberry Pi 3 that had been dormant for half a decade. After finding a compatible micro-USB cable, I realized the OS was five major versions behind, necessitating a fresh flash of the SD card.

Setup Checklist

Flash latest Raspberry Pi OS to SD card
Use Codex to provision the Pi as a robotics controller
Install LeRobot control software
Configure python and essential dev tools
Deploy a web dashboard for camera monitoring and arm control

Safety and Calibration

With Codex (Astra) managing the foundation, we adopted a "crawl-walk-run" philosophy. A significant portion of the initial code focused on servo protection. We implemented logic to ensure that if an overload was detected, the system would immediately cut torque and power to prevent hardware failure.

To handle spatial awareness, we utilized AprilTags (visual markers similar to QR codes). We placed these tags in two locations:

On the table surface to establish geometry.
On every joint of the robot arm so the camera could track the arm's own position.

Technical Hurdles & Tool Swapping

The journey wasn't seamless. We encountered a frustrating bug where the serial link would drop, but only when the motors were active. After some debugging, we realized it was a power issue: the supply could handle one servo, but not the entire array simultaneously. I ordered a beefier power supply, but in the interim, I had to limit movement to one servo at a time.

Around this time, I hit my weekly Codex credit limit. To avoid expensive API rates, I transitioned the project to Fable 5.1.

Pro Tip: One of the best features of this handoff was the ability to share the entire ChatGPT transcript. This allowed the new LLM to build its own context from the full history rather than relying on a condensed summary.

The Failure of Manual Mapping

With the foundation set, I attempted a sophisticated approach to movement. The plan was to let the LLM map the environment through calibrated runs and use Inverse Kinematics (IK) to execute actions.

The math looked like this in theory: $\text{Position} = f(\theta_1, \theta_2, \theta_3, \dots, \theta_n)$

I spent hours manually posing the robot, measuring the distance from the base to the pinch point, and feeding those heights back to the AI.

~~I believed we were on the verge of success.~~

![Early Calculations](https://via.placeholder.com/600x400?text=Figure+4:+Early calculations that promised success but failed in practice)

In reality, the executions were wildly inaccurate. The system was relying on calculated coordinates without using the camera for real-time feedback to adjust the arm's path.

Removing the "Meat Proxy"

I realized that I was the bottleneck. I had to leave to coach my daughter's volleyball practice, which provided the perfect opportunity to remove the human element from the loop.

Before leaving, I used /remote-control to give Claude a new directive. I shifted the goal from "perfect mapping" to "functional result."

The Prompt: "Is it possible to zero out the gripper on the table and stop the servo when it encounters resistance and then using that as the zero point?

A similar approach could be used to guess and check the location of the block. We should also be using the camera to determine correct location and adding resistance feedback rather than constantly stopping and measuring.

The goal is to pick up the block and drop it in a marked location; let's focus on that rather than calibrating and mapping the space."

While I was at the gym, Claude spent the afternoon autonomously testing resistance and stop mechanisms to determine the zero level.