Building a Walking Robot in 8 Months: A Developer's Iteration Path

A developer returned to Reddit after 8 months to share the iteration journey of his robotics project from MK5 to MK6. From the first generation that looked impressive but lacked torque, to MK6 V1 that actually took steps, to the evolution toward laser-cut legs and dual-arm/dual-leg humanoid machines, this timeline captures the real rhythm of personal hardware development: trial, scrap, and try again.

From MK5 V1 to V2: Looks First, Torque Remedial Course

MK5 V1 was described by the author himself as "looks impressive, but... yes, I lack torque." This line points to the most common trap in hobby robotics: visual completeness ahead of mechanical performance. The shell can be 3D-printed beautifully, but joint motor selection, gear ratio design, and power management—the things that actually determine whether the robot can move—often need a second or even third round to get right. MK5 V2 didn't come with much written explanation, but based on iteration logic, it most likely corrected torque and structural strength.

For developers wanting to build robotics projects, the lesson at this stage is direct: calculate the torque budget first, then design the exterior. The relationship among the rated torque of servos or motors, linkage length, and overall weight should be estimated with simple formulas during the modeling stage—not discovered after assembly when the leg can't lift.

Torque budget is a core concept in robot joint design, referring to calculating the minimum output torque required for each joint given the overall weight and linkage geometry. For a simplified estimate, joint torque can be treated as the product of load weight, gravitational acceleration, and moment arm (the horizontal distance from the joint to the center of mass), then multiplied by a safety factor (typically 1.5–2). When selecting components, consider both the motor's rated torque and stall torque, and match the gear ratio—higher gear ratios amplify torque but sacrifice speed. A common mistake is selecting based on motor size or appearance alone, ignoring how weight distribution amplifies torque requirements. Listing each joint's load and moment arm in a table during modeling exposes torque shortfalls early and avoids rework after assembly.

MK6 V1: The Moment It Walks

"it walks!! it walks!! it walks!!" paired with a dog emoji—MK6 V1 is clearly the highlight of the whole project. Achieving gait in a biped or quadruped robot usually means the developer has crossed three thresholds: mechanical structure, motor control, and posture feedback. Even if it walks unsteadily, it's already a qualitative leap. A common follow-up in Reddit comments is what control scheme was used and how the sensors are configured, but the original post didn't expand on technical details, leaving only this emotionally charged milestone.

From open-source community experience, getting a robot to walk for the first time often doesn't require complex reinforcement learning or model predictive control—a simple open-loop gait with servo timing can achieve "it walks." The real challenge is walking stably, quickly, and resisting disturbances. MK6 V1 is closer to the former.

Open-loop gait refers to a walking method that drives joints according to a preset timing without relying on real-time posture feedback. For servo-driven biped or quadruped robots, developers often generate foot-end trajectories via inverse kinematics, then map them to angle-time sequences for each joint, playing them in a loop to achieve "it walks." Its advantages are simple implementation and no need for expensive IMUs or force sensors; the downside is lack of disturbance compensation—instability arises on uneven ground or under load changes. In contrast, closed-loop control introduces IMU, foot contact switches, or encoder feedback, adjusting gait phase via PID or a state machine. The transition from open-loop to closed-loop is often the key watershed where a personal robotics project moves from "demo" to "practical."

MK6 V2 and Dual-Arm/Dual-Leg Humanoid: Laser-Cut Legs and WIP

The highlight of MK6 V2 is "laser-cut legs," with the author using a sunglasses emoji. Laser cutting means structural parts shift from 3D printing to sheet material processing, which typically brings higher rigidity and lower per-part cost, and signals the project is starting to consider reproducibility and mass-production potential. Also appearing are WIP (work-in-progress) projects in two directions: a "dual-arm human" and a "dual-leg human," indicating the developer's interest is expanding from a single motion platform to humanoid configurations.

One detail: the original post mentions that those who want to see it in person can do so in Seoul, suggesting the author may have offline demonstration or exchange channels there. For readers following personal robotics development, such offline settings are often the best opportunity to see physical details and discuss motor selection and structural design.

Laser cutting is commonly used in robot structural part fabrication for acrylic, wood, or thin metal sheets. Compared with 3D printing, laser-cut parts have good in-plane rigidity, uniform thickness, low per-part cost, and fast processing—suitable for frequently iterated linkages and frames. Design considerations include compensation for cutting tolerances (typically 0.1–0.2mm), mortise-and-tenon or bolted connection design at joints, and the effect of sheet grain on strength. For leg structures requiring high rigidity, laser-cut laminated or sandwiched plate designs can significantly reduce deformation during walking and make it easy for community members to reproduce from drawings—this is exactly the common process switch path for personal projects moving from "exclusive" to "replicable."

What This 8-Month Timeline Shows

The iteration rhythm from MK5 to MK6 reflects the typical cycle of personal hardware development: a version often takes weeks to months from concept to demo, and completing four or five minor versions in eight months isn't slow. MK5 with looks first, V2 with torque remediation, MK6 V1 achieving gait, and V2 shifting to sheet structures—each step solves the specific problem exposed by the previous version rather than starting over.

For developers also working on robotics projects, three references can be drawn: first, treat "can demo" as a version milestone rather than pursuing perfection in one go; second, calculate the budget for mechanical structure and motor selection early; third, switching structural processes (3D printing to laser cutting) can significantly change overall performance and cost structure. The original post didn't provide code or drawings, but the iteration approach itself offers value to the community.

One-line Summary

Developer iterates robot from MK5 to MK6 over 8 months, achieving walking and shifting to laser cutting and humanoid configurations.

Paragraph Summary

A developer shares the 8-month iteration journey of his robotics project: MK5 V1 looked great but lacked torque, exposing the common problem of visuals preceding mechanical performance in hobby development; MK5 V2 likely remedied torque and structural strength; MK6 V1 achieved walking, crossing the three thresholds of mechanical structure, motor control, and posture feedback; MK6 V2 shifted to laser-cut legs, improving rigidity and reducing cost, pointing toward reproducibility; meanwhile dual-arm and dual-leg humanoid projects are in WIP. The article distills three references: treating "can demo" as a version milestone, calculating torque budgets early, and structural process switches changing performance and cost, emphasizing the value of the iteration approach to the community.