Building a Walking Bipedal Humanoid

[Thomas Messerschmidt]

Hi everyone,

I'm kicking off a new personal project: building a life-size walking humanoid robot, similar in spirit to what Tesla and Figure have demoed. My plan is to lean heavily on open-source hardware and software rather than designing everything from scratch, and to document the whole process, partly for my own learning and partly as material for a future book.

I seem to recall that a few members here have worked on, or completed, dynamically balanced bipedal walking robots of their own. If that's you, or you know who it is, I'd really love to connect. Specifically I'm hoping to learn from:

- Actuator and joint choices that actually worked for dynamic balance (versus ones that didn't)
- Any open-source reference designs or code you built on or would recommend
- Lessons learned around simulation, control, or sim-to-real transfer
- Pitfalls or dead ends worth avoiding, so I don't have to rediscover them the hard way

I'm happy to trade notes, share what I learn as I go, or just buy someone a coffee and pick their brain for an hour. If you've got a biped in some state of progress, finished or not, I'd love to hear about it.

Feel free to reply.

Thanks,

Thomas Messerschmidt

[Chris Albertson]

I too would like to hear from anyone who has even started to think about this.

I’m kind of working on this too.   I say “kind of” because my plan is that the LAST thing you do is assemble parts to build a robot.

The “build it first, then figure it out” plan works for simple wheeled robots but not for anything that walks using dynamic balance.

What I did is first build a simple “dog bot” and learned a ton from it.   I learned that you need a surprising amount of power and speed and that “weight REALLY matters” and also “mass distribution matters almost as much as total weight.”

Here is the big problem when designing this:  In order to decide the motor size and performance, you need to first know the robot’s size and weight, but the choice of motor influences the robot’s size and weight.   Then the mass distribution kills you because the WORST place to add mass is in the ankles and feet.   Nature designed humans with ankles that are much smaller in diameter than the upper legs,  but notice the ankles have to support more weight than the knees.   Humans are well-designed, but copying this in a robot is not easy.     Basically you need to do the mechanical design iteratively, and only after many versions will one look good.   It is frustrating because as soon as you make one part stronger, then it becomes heavier and now every other part has to carry that weight and the motors need more power which makes everything heavier and it needs more strength and you never win.    So you think “OK” aI will reduce some weight and then use cheaper/lighter motors, " and then you don't like the performance.      It takes a long time as every gram matters.

So, the way I’m working is how “everyone” works now.  They call it “sim-to-real”. You build a simulated robot to work on design iteration, but you make both the robot and the simulation as real as possible.      No “fake” robots in the simulation you use; the actual design files from CAD to create the sim.  You let your CAD calculate the center of mass and add the masses from the BOM.     And on the other side, you use a very realistic physics sim like Nvidia Isaac or MuJoCo.       The sim has to be accurate.

This means a bit of the learning curve.   You need to be good enough at mechanical engineering to create parts that are near optimal and can be CNC machined without requiring stupidly exotic machining technology or impossible-to-print parts. And the detail has to be fine enough so you know how wires and cables are routed. and the mass of each part.

If you start by picking motors, you waste time because you might pick something that lacks good control latency.  (Don’t even think about serial-connected servos.) Or is either under of over sized.

The hard part is the controller and deciding on the overall architecture.    You need this first because the controller needs to go into the simulation.   The simulated robot uses the real controller software, not some stand-in.    So this part needs to be done first.

This is where I am thinking hard right now.    I have some options, and if anyone wants to make suggestions, more than welcome.  Let’s start VERY SIMPLE.  The first version of the controller has only one function called “stand”.   The robot will stand and not walk.  It will lean to shift its balance to remain upright if some small force is appled or if the floor is tilted up to about 5 degrees. Later, we will improve this so the robot can hold objects with its hands and lean backward to maintain balance if it places its hands forward. Then what if it moves arms quickly while standing? It has to compensate by moving other parts of the body to counter the reaction forces.   I want this all solved BEFORE we try moving the feet to walk.  This is the most basic starting place:  "Dynamic stability while standing still.”

Basically a robots “moves it’s feet” in X,Y to resist side forces.  But the quotes mean the feet don’t realy move but the body moves r rotates over the feet.

This is where I am now.  How to architect this.  Several options.

1) Assume the motors all can be commanded to a specified torque and a specified position.    Is a velocity or acceleration command required?

2) I assume I can do balance using only an IMU, joint encoders, and pressure sensors on the feet.  Can I get by without more than that?

3) How fast must the balance control loop run?   Most people say 100 Hz, but can 50Hz work.     ThePID loops for #1 above are in hardware inside the motor controller and run at well over 1,000 Hz.  But I just assume that is part of the motor, not the robot controller.

4) BIG QUESTION:  Should balance be done with an RL-trained neural network?   This is “doable” because unlike an LLM, this balance model might have only a thousand or so parameters and is “tiny” by modern standards.  I could train it in a week using a normal computer.       Or should I simply “hand-code” the balance loop in Python using linear algebra and inverse kinematics like I did with the hobo-dog?  Do I need a hard-coded safety system or can I trust a network?

5: Real question:  #4 above might end up being a compromise or “hybrid” of hand-coded and RL-trained.  Where to draw the interface?

NEXT, I want this to walk on flat indoor floors.      I’ve already decided I want to base the walk motion on a biologically inspired “GPG” (Cyclic Pattern Generator), but is this software or a ring of simulated neurons?    Or is it one CPG for each body part, and we keep them all phase locked?     Or again, is this a hybrid code/model?  It seems EVERY robot uses the hybrid  CPG design, but they all do it differently.

I think what I will do is first get any generic humanoid model to run in a Mujoco simulation (I could use Isaac, but Isaac requires a Linux PC with a minimum $1000 Nvidia GPU, and I already own a comparable Apple Mac).   But I COULD run Isaac on rented time on a cloud server for about $2 per hour.  But I’d burn up 1,000 hours really fast.    Also, I like the idea of open source, and that’s Mujoco https://mujoco.readthedocs.io/en/stable/overview.html

I’m thinking the design will be “layered,” with the foundation being a very robust balance system and layered over that a CPG-based locomotion system.     The loco system will accept the full suite of ROS2 velocity and pose commands:

1. Speed (moving feet) in X (forward)

2. Speed (moving feet) in Y (left/ right)

3. Rotation (by moving feet) about Z (turn to the left or right)

4. Pose body (with no foot movement) in X, Y, Z.    This means lens in all directions as well as crouching or standing tall

5. Rotate body (with no foot movement) about X, Y ,Z (this covers all possible twists and bends at the waist)

My Robot dog can do all of this simultaneously, and it is not as complex as it seems. It is hand-coded, not trained, and only takes a few matrix multiplies.  It is important to remember that waking robots have considerable range of motion independently of what their feet do.

The way to make it work is (1) simulate a simple robot that does only 1% of what you need.  (2) Make the sim better. (3) Repeat as required.

THEN at some point, the simulation will provide realistic measurements of torque and velocity on the joints.  Buy a motor with those specs and get just one joint to work.  Connect it to the simulation so it moves in real time.

Notice that there is no mention of arms and hands yet.  I think object manipulation is another field that is almost independent of locomotion.

Summary:  

1) “everyone” does sim-to-real now and for a good reason

2) “everyone" seems to use some kind of hybrid hard-code and neural net.  No one directly connected neurons to MOSFET gates.

3) Simply standing while being resistant to external force and not falling is 90% of the game.

One more thing:  Cost seems to be related to the 3rd power of height.   Because volume is length cubed and mass tends to follow volume, and required power follows mass.    So, shorter robots are dramatically cheaper to build.    Maybe define “full size” as the lower end of adult female range.        

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CADyjTyYt0FNNEkN_31nc1%2Bt%3DaTsRHu-EfJp4MWs2ho-9yuP6Mg%40mail.gmail.com.