Reflections on Optimizing Robot Balance Through Hardware Design 6
In the previous discussion, “Reflections on Optimizing Robot Balance Through Hardware Design 5” (hereafter referred to as Hardware Design 5), we explored insights gained from observing human running. Two key takeaways were:
- The configuration where the support structure is centralized while dynamic structures are distributed on either side seems worth considering.
- The spine sometimes combines with the “muscle” on either side to form a new structure, resulting in a mass and inertia imbalance that creates a dynamic interplay of forces. This interplay minimizes drag and static friction, enabling smoother movement.
However, the illustrations and explanations in Hardware Design 5 mainly served to introduce these new concepts rather than offer concrete solutions for robot torso design. For example, in Figure 3 from the previous discussion, I deliberately included a black line representing the spine. While the human spine provides structural support, robot muscles (power structures) on either side are made of steel and inherently provide support. Would this mean the spine could be omitted altogether? Could the dynamic forces and qualities achieved by a “spine + one-sided muscle” combination be replicated simply through differential force, torque qualities, and movement angles of the two power structures on either side?
If we remove the spine entirely, could the space it occupies instead house something else? For instance, in Figure 3 of Hardware Design 5, the black line resembling a spine could instead represent a bundle of fiber optics, neural pathways, or wiring conduits. Alternatively, it could even be a series of connected lithium batteries, much like the “energy capsules” held by robot enemies in some video games.
In my vision, the robot might have two spines, capable of rotation and lateral sliding along a horizontal track located at the level of the “belt” or the “dan tian” (core) area. These spines could also be connected via a frame from the heart to the shoulder blade height, providing a base for attaching the neck and head components.
Alternatively, instead of two spines, the robot could wear a rigid shell resembling a chest cavity, onto which the neck and head components are directly mounted. This idea was inspired by the structure of a turtle’s shell. (Don’t search for images of turtle anatomy—it can be unsettling!) One might assume that a turtle’s spine is independent and sways inside the shell, but in reality, the turtle’s spine is more like a relief sculpture fused to the inner surface of the shell, with the neck bones attached directly to the shell.
Conclusion
From the perspective of modifying action figures or robot prototypes, the existing distribution of joints along the central axis effectively recreates human postures. However, when designing robots to reproduce human movement as a functional goal, too many centrally aligned joints could result in a “static stability” that feels overly rigid. For example, a robot trying to stand independently on a moving bus or executing dynamic motions like running and jumping may experience its components becoming unexpected dead weight during motion, disrupting fluidity and even causing the robot to topple over.
If we embrace this “philosophy” of design, must robots have two spines? Or could the internal weight distribution within a rigid chest cavity be divided into two mobile, sliding, or rotating segments that can dynamically adjust to maintain balance? The key is that the chest cavity should not simply be a static, heavy “mini-fridge” within the robot’s torso. Encouragingly, many modern bipedal robots already split their hip components into two separate units, often resembling two small motor cans placed on either side of the pelvis. I believe this approach is correct. So why not apply the same concept above the waist, enabling dynamic interaction between left and right components?
The link below contains some interesting robot waist designs. In particular, from Figure 01 to Figure 02, the dual-spine-like design, similar to the one discussed in this article, was removed. Was it not effective enough? Or was the maintenance cost too high?
[https://youtu.be/T6KtiOmRkn8?si=BShVJ89oSGYdOr17&t=195]