DIY Bipedal Robot CBR-II V3: Smoother Gait, Taking On Single-Leg Balance

Title

DIY Bipedal Robot CBR-II V3: Smoother Gait, Taking On Single-Leg Balance

Meta Description

Reddit user shares progress on the DIY bipedal robot CBR-II V3: gait jitter noticeably reduced, attempts single-leg balance, success in simulation but still a gap in reality. Hardware bottlenecks cause repeated joint failures and GT2 belt breakage, putting the project on hold.

Article Content

A Reddit user has shared progress on the third iteration (V3) of his DIY bipedal robot CBR-II. Compared with the previous two versions, V3 shows a clear improvement in walking stability and has begun attempting more challenging maneuvers such as single-leg balance. However, hardware bottlenecks have also brought the project to a temporary stopping point.

From V1 to V3: A Clear Reduction in Gait Jitter

The author posted two comparison videos: Clip 1 shows V3's walking performance, and Clip 2 shows the original V1 version. According to his description, V3 "walks with much more confidence and far less jitter." For a DIY bipedal robot, gait jitter is the combined result of the control algorithm and the mechanical structure, so achieving visible improvement in this area indicates that the author made effective adjustments to gait planning or joint control.

The only still rather "harsh" moment comes when a "forward" command is immediately followed by "stop"—the robot lands on its forefoot and then slams heavily into the ground with considerable noise. This impact during start-stop transitions is very common in bipedal robots and usually needs to be mitigated with more refined foothold trajectory planning and impact absorption mechanisms.

Gait jitter in bipedal robots typically arises from two levels: first, the control level, where the joint trajectories output by the gait planner are not smooth enough, or the joint controller lags or overshoots when tracking position/torque commands; second, the mechanical level, including joint backlash, linkage flexibility, and sensor noise. DIY projects often use servos or low-cost brushless motors with limited encoder resolution and low closed-loop bandwidth, making periodic jitter during walking easy to produce. Improving jitter generally requires approaches such as trajectory interpolation (e.g., spline smoothing), higher control frequency, low-pass filtering, or feedforward compensation.

The "heavy stomp" during start-stop transitions is related to foothold trajectory planning and impact absorption. While walking, the robot has momentum; if a sudden stop command is not accompanied by a deceleration trajectory and center-of-mass adjustment, the foot will contact the ground with a large vertical velocity, producing impact loads. Mitigation methods include planning buffered foothold trajectories, adding elastic elements at the ankle joints, or achieving soft landings through torque control.

Single-Leg Balance: Perfect in Simulation, Struggling in Reality

Clip 3 shows V3 attempting single-leg balance. The author admits that in the simulation environment this maneuver succeeds every time, but in reality it is "far from perfect." Still, he adds, "you can totally tell what it's trying to do."

This gap between simulation and reality is a long-standing problem in robotics. Simulation models often simplify factors such as friction, clearance, and flexible deformation, while the joint backlash, belt elasticity, and ground reaction forces of real hardware dramatically increase control difficulty. Being able to discern the intent from the motion itself already shows that the control framework is working; only precision and robustness still need refinement.

The sim-to-real gap is a classic challenge in robot control. Physics simulators usually simplify contact friction, joint clearance, structural flexibility, and actuator dynamics: for example, treating joints as ideal torque sources and ignoring backlash and friction hysteresis; simplifying ground contact as rigid-body collision and ignoring microscopic deformation. In real systems, GT2 belt drives introduce elastic stretching and backlash, servos have dead zones and response delays, and ground reaction forces are more complex than in simulation. These unmodeled dynamics are amplified in underactuated, low-margin tasks such as single-leg balance, causing controllers that are stable in simulation to become unstable in reality. Common countermeasures include domain randomization, system identification and residual modeling, and designing control laws that are more robust to disturbances.

Hardware Bottlenecks: Joints Fail Three Times, Belt Breaks

The author states clearly that the project may end here, at least for this year. He had originally considered jumping motions and even "secretly dreamed of a backflip," but the hardware is simply too fragile. During just one day of testing, the joints broke three times, and a GT2 timing belt snapped—and not at the curved section around the pulley, but in the middle of a straight run, breaking directly under tension.

A GT2 belt breaking in the middle of a straight section usually points to excessive tension or problems with belt quality/wear. For a robot pursuing dynamic motions such as jumping, the transmission system needs to withstand instantaneous loads far higher than those of walking, and the existing hardware clearly has no margin for such operating conditions.

GT2 timing belts are a common transmission component in 3D printing and DIY robotics, with a 2 mm pitch, transmitting power through tooth engagement. A timing belt breaking in the middle of a straight section usually indicates that the tensile stress on the belt body exceeded the material strength. Possible causes include: excessive preload, too small a pulley diameter causing bending stress concentration, fatigue of the fiber layer after long-term use, or insufficient tensile capacity of the selected belt specification (e.g., glass fiber reinforced vs. steel wire reinforced). For dynamic motions such as jumping and backflips, the transmission system must transmit impact loads several times body weight within an extremely short time, and peak tension is far higher than in constant-speed walking conditions. If the hardware design did not include a safety factor for peak loads, a straight-section break is a typical overload failure mode.

A Reasonable Endpoint for a DIY Project

The CBR-II V3 update demonstrates a typical path for a personal robotics project: from being able to walk, to walking steadily, to attempting dynamic balance. The gait improvements and single-leg balance attempts deserve recognition, but the physical limits of the hardware also realistically define the current boundary of capability. The author's choice to pause here and leave jumping and backflips for a future, sturdier hardware version is a pragmatic decision.

For those interested in DIY robotics, this project offers a valuable reference: control algorithms can run successfully in simulation, but real-world mechanical strength, assembly precision, and material fatigue are often harder constraints.

One-line Summary

DIY bipedal robot CBR-II V3 has a steadier gait and attempts single-leg balance, but fragile hardware forces the project to pause.

Paragraph Summary

A Reddit user shared progress on the third iteration (V3) of the DIY bipedal robot CBR-II. Compared with V1, V3 shows markedly reduced walking jitter and a more confident gait, though sudden stops still produce a heavy forefoot impact with the ground. Single-leg balance succeeds every time in simulation but is far from perfect in reality; still, the motion's intent is visible, reflecting a typical sim-to-real gap. Hardware has become the main bottleneck: during a single day of testing, joints broke three times, and a GT2 timing belt snapped in a straight section under tension. The author has therefore decided to stop the project, at least for this year, leaving dynamic motions such as jumping and backflips for a sturdier hardware version. The project illustrates a typical progression for DIY bipedal robots from walking stability to attempting dynamic balance, and shows that real mechanical strength is often a harder constraint than control algorithms.