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.

[Pito Salas]

Thanks, Chris, interesting to read about your process and analysis. 

Best,

Pito Salas

Boston Robot Hackers &&

Computer Science Faculty, Brandeis University

On Jul 9, 2026, at 4:09 PM, Chris Albertson <alberts...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/18CF7822-666A-400A-9A28-2DE6CF9FF460%40gmail.com.

[Wayne Gramlich]

Thomas:

You might get some inspiration looking at a Google project that was shut down
a couple of years ago, that they open sourced on github.com:

* https://github.com/google-deepmind/barkour_robot

Note that they have open sourced their EtherCAT servo controllers and all of the
software that talks to them.

Regards,

-Wayne

[Chris Albertson]

I keep explaining what I’m doing in the hope that someone will tell me there’s a better way. Unfortunately, it appears that humanoid robots are complex and require considerable engineering to even do the basics of walking on a flat floor.

But the question was about motors.  So,...

As for the motors and such, EVERY current humanoid uses the design first presented in a paper from 1998. It is very easy to read. The paper has been cited over 1,000 times and is a “must-read” because it explains how every modern walking robot works.

The authors applied this to a quadruped, but the ideas are even more important for a biped. This is what everyone does now. Optimus, Atlas, and all of the Unitree robots are basically the “MIT Cheetah 3” morphed to different sizes and shapes

If nothing else, read “II. Design / A. Overview” from the paper linked below

The key design ideas are

1. Identical motors on each degree of freedom at a joint

2. Backdrivable gears (this is essential)

3. Very low gear reduction, at 6:1 or 9:1 at most

4. Very high-torque motors that produce high torque at zero RPM

5. Local hardware control of the PD control loop at high control loop frequencies. (Today every uses FOC)

6. Very low-inertia limbs.

Later papers show how the motors and gears were made in detail, but today you can buy them already assembled cheaper than DIY.

Look at the Stedywin company in China.   Here is a link to their Cheetah quadruped sized moter but they make all kinds, up to 1,200 Watts. This smaller motor might work for humanoid arm/shoulder joints; I don’t know.   Simulation will say.     These are about $80 on AliExpress, and you need 12 of them for a quadruped.

Steadywin has specs online, but very importantly, they share the ".step" 3D CAD files online too.  You can directly import .step files to your CAD software.

Most every humanoid today uses six moters like these to build a pelvis.   3 on the left and three on the right where each motor’s axis to 90 degrees to the others on the x,y,z axis Sometimes, they rotate the entire assembly 45 degrees; this allows all three motors to share the load for (body relative) X-motions.   (In 2D I can see that rotating the axis by 45 degrees gives 1.4x better power in one direction and I THINK this generalizes to 3D space.). But who cares — it looks cool. (See Unitree R1 for example.  RI uses 45 deg. rotated hip axis but “stright’ shoulders design.  I think this allows for a stronger stride because more motors are moving.)

[Chris Albertson]

Wayne,

That’s for posting this.   The engineering details are over the top.  I can see they spent thousands of hours of design labor on this.

First off “EtherCAT " is a very good option for a humanoid.  It is simple and has great bandwidth.   For those who don’t know, it uses an Ethernet cable, but It works more like a CAN bus.  For a humanoid with 28 motors, they can all go on one daisy-chained cable.

This robot seems to be a very good 3D printable re-implementation of the MIT Cheetah.   If I wanted to build another dog-bot and cared nothing about cost,   I’d try this.  But I can see why Google ended the project.  The BOM cost for the motors alone is about $6,000, and then you need the structure and the NUC computer, a few CNC machined parts, a power system, and so on.    This would cost more to build than buying a Unitree R1 Humanoid.   

But the design ideas are great.  Look at the part they call ”Combined Faceplate”.  It is the only substantial metal part, and two identical parts are used.   It looks to be about 1/8th aluminum plate that needs only basic 2D CNC milling to make.   This is an idea to use for a humanoid.  Use a plate to take the concentrated point loads and distribute them into the stressed plastic skin. 

 I especially like the design of the 3D parts.  They do what I have been preaching for years — use compound “organic” shapes and eliminate flat/planer surfaces, and you get much better rigidity.   This is a professional design, and it shows.    Because they choose to use plastic, the stress is all on the body skin, and there are no internal “bones” or frame.    This is the way to use plastic.  Whereas metal is best used with an internal frame design.

It is rare to see this level of engineering in an open source design.   Most use simpler prismatic shapes simply because they are easier to draw.

Direct link to the CAD so you can study the parts: https://gdm.onshape.com/documents/2587dbf423d784b45437b14a/v/b07bb08c3dc8b02bae21b866/e/bdcd5797385cee9e4f78dfef?aa=true

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/14c9a0cb-4d75-40c0-9de6-c6b735cbaee4%40gmail.com.

[Martin Hegedus]

I'm working on a small RC robot with my daughter for fun.

If this club is like a job where people SHOUT at each other, that sucks and count me out.

I'm assuming that if individuals are smart enough to make robots, then ALL CAPS and bold are not required.

My naive guess is that if the desire is to build a humanoid robot, a team is required.  In general, bullying doesn't go over well when people are volunteering time.

Martin Hegedus

--
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/43C40AF1-7D6E-482A-BAC2-8DC846019CBE%40gmail.com.

[Dave Everett]

On Fri, 10 Jul 2026 at 04:29, Thomas Messerschmidt <thomas...@gmail.com> wrote:

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.

I think there is a distinction to be made between "real walking" and "walking just enough". Take the Tesla robot for example, have you seen it walk up or down stairs? Or over rough terrain? I haven't, I have only seen it walk on very flat hard surfaces. In this case a rolling robot would make more sense. While solving a walking on hard flat ground is an achievement, it doesn't require legs.

Therefore I feel that walking should focus on real world situations involving stairs and uneven ground. We see Boston Dynamics doing this and we saw Asimo do this to some extent. This is the real value of legs. 

A walking robot would need enough force in each leg to climb stairs, so it would need to be able to perform a a single knee bend of some kind.  

Back in about 96 I built a small humanoid robot out of slim servos. They had just become available at a reasonable cost, I think they were $30 each. Naturally they were pretty bad and had a lot of backlash. I did get it to work, but it looked like it suffered some kind of motor neuron disease. It taught me, don't skimp on quality motors. 

If you are working on a  humanoid just because you want one, that is fine and educational, but you might be better to buy an off-the-shelf humanoid as a basis. Someone else will have solved many of the problems and it will probably be cheaper. Camp's G1 looks like a good starting point. I've often wondered how G1 performs on stairs and rough terrain.

Dave

[Thomas Messerschmidt]

Thanks Dave. 

Thomas Messerschmidt

-  

Need something prototyped, built or coded? I’ve been building prototypes for companies for 15 years. I am now incorporating generative AI into products.

Contact me directly or through LinkedIn:   

https://www.linkedin.com/in/ai-robotics/

On Jul 10, 2026, at 6:19 PM, Dave Everett <daveev...@gmail.com> wrote:



--
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/CAG61pbcBHv2pqJCVOx%2B7QcM2%2BBB6BWqD3TBzjd2ducdNrp%2BMyQ%40mail.gmail.com.

[Chris Albertson]

Yes.  100% agree.      I used the Tesla example only to show that modern robots do not have to be “algorithmic” or contain any “if this then that” kind of logic.    

But I agree.  I have no interest in those old toy robots that used huge, weighted feet.    I think the goal should be to do anything most healthy humans can do. like outdoor paths with some potholes and rocks, easy stepping stones, stairs and curbs and slopes up to maybe 30 degrees.  Waling on a moving train or airplane     Also running.    Runing is defined as having both feet off the ground at some point.   Most peple can at lest run a few steps.       

On Jul 10, 2026, at 6:19 PM, Dave Everett <daveev...@gmail.com> wrote:

On Fri, 10 Jul 2026 at 04:29, Thomas Messerschmidt <thomas...@gmail.com> wrote:

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.

I think there is a distinction to be made between "real walking" and "walking just enough". Take the Tesla robot for example, have you seen it walk up or down stairs? Or over rough terrain? I haven't, I have only seen it walk on very flat hard surfaces. In this case a rolling robot would make more sense. While solving a walking on hard flat ground is an achievement, it doesn't require legs.

Therefore I feel that walking should focus on real world situations involving stairs and uneven ground. We see Boston Dynamics doing this and we saw Asimo do this to some extent. This is the real value of legs. 

Yes, the entire point of a humaniod robot is that it fits into the same spaces as humans.    I’d like the robot to climb a tree or ride a bicycle too.

A walking robot would need enough force in each leg to climb stairs, so it would need to be able to perform a a single knee bend of some kind.  

It needs a lot more.   You can’t look at the steady state.   You have to look at required accerations.   Velocity is not constant.   Then there is the energy needed simply to stand and balance on one foot.  That is not small.   But already, if the robot can run even at only a slow jog, it needs about the same strength. There is actualy a formula for finding the required leg force.

Back in about 96 I built a small humanoid robot out of slim servos. They had just become available at a reasonable cost, I think they were $30 each. Naturally they were pretty bad and had a lot of backlash. I did get it to work, but it looked like it suffered some kind of motor neuron disease. It taught me, don't skimp on quality motors. 

If you are working on a  humanoid just because you want one, that is fine and educational, but you might be better to buy an off-the-shelf humanoid as a basis. Someone else will have solved many of the problems and it will probably be cheaper. Camp's G1 looks like a good starting point. I've often wondered how G1 performs on stairs and rough terrain.

I suggested that too.   Now you can buy an R1 cheaper then the G1.   But none of the cheap humaniods are programable.   They are just remote control toys.  Even so you could buy an Ri and dismantal it and remove/trash every bit of control electronics and computer and be money ahead.

I think what happens is that you say you want to build humanoid robots and then you get into it and some sub-problem becomes interesting and then you work on that.   One little thing like grasp planning could occupy a person for years.   Teaching a robot that its hand will not pass through the side of a refriderater or a pickel jar while reaching for the bear is not easy.    I doubt I will build a complete robot.   I am more interrested in the problem solving and engineering.  I have no need for a robot of the kind I could afford to build.

At work, I learned a lot about radar systems althought I never build a complete radar myself and I really don’t need my own air defence radar.    This is my plan with humanoid robots.     The best thing i to contribute to an open source robot design.    The hard part is getting such a project started.

[Dave Everett]

On Sat, 11 Jul 2026 at 09:51, Martin Hegedus <martin....@gmail.com> wrote:

I'm working on a small RC robot with my daughter for fun.

If this club is like a job where people SHOUT at each other, that sucks and count me out.

I'm assuming that if individuals are smart enough to make robots, then ALL CAPS and bold are not required.

My naive guess is that if the desire is to build a humanoid robot, a team is required.  In general, bullying doesn't go over well when people are volunteering time.

I'm not understanding this post Martin. I had not seen anyone shouting or bullying. I may have missed some posts. I have been a member for many years and have not experienced either issue.

Dave

[Dave Everett]

On Sat, 11 Jul 2026 at 12:47, Chris Albertson <alberts...@gmail.com> wrote:

Yes.  100% agree.      I used the Tesla example only to show that modern robots do not have to be “algorithmic” or contain any “if this then that” kind of logic.    

Right, I have no issue with your analysis, to be honest I had not read through the entire thread before throwing in my 2 cents :)

But I agree.  I have no interest in those old toy robots that used huge, weighted feet.    I think the goal should be to do anything most healthy humans can do. like outdoor paths with some potholes and rocks, easy stepping stones, stairs and curbs and slopes up to maybe 30 degrees.  Waling on a moving train or airplane     Also running.    Runing is defined as having both feet off the ground at some point.   Most peple can at lest run a few steps.

Recently I have been seeing promos for a robot called "RUMI" that appears to run amongst other things. The company appears to have made several humanoid robots , so it might be real. The performance seems very good with a claimed runtime of up to 3hrs between charges. It's of course as useless as all the rest of them, not even fake hands on this one, but the engineering seems very good.

It's always been my opinion that 6 DOF are a minimum for a humanoid leg, with a 7th being a toe section that can help with walking. I had first assumed Rumi had only 4 DOF, but on slowing the videos to 25% it's clear that 6 are in use.

If you are working on a  humanoid just because you want one, that is fine and educational, but you might be better to buy an off-the-shelf humanoid as a basis. Someone else will have solved many of the problems and it will probably be cheaper. Camp's G1 looks like a good starting point. I've often wondered how G1 performs on stairs and rough terrain.

I suggested that too.   Now you can buy an R1 cheaper then the G1.   But none of the cheap humaniods are programable.   They are just remote control toys.  Even so you could buy an Ri and dismantal it and remove/trash every bit of control electronics and computer and be money ahead.

Which I think is still a good option. I will have to look into R1 now. 

I think what happens is that you say you want to build humanoid robots and then you get into it and some sub-problem becomes interesting and then you work on that.   One little thing like grasp planning could occupy a person for years.   Teaching a robot that its hand will not pass through the side of a refriderater or a pickel jar while reaching for the bear is not easy.    I doubt I will build a complete robot.   I am more interrested in the problem solving and engineering.  I have no need for a robot of the kind I could afford to build.

At work, I learned a lot about radar systems althought I never build a complete radar myself and I really don’t need my own air defence radar.    This is my plan with humanoid robots.     The best thing i to contribute to an open source robot design.    The hard part is getting such a project started.

I have been involved in many group robot projects over the last 30 years. inevitably, I found people wanted to argue over "operating systems" rather than deal with the hard problems. I usually left these projects at that point. The hard problems are where progress still needs to be made and where hobbyists could still make a difference. While it looks like we are on the cusp of true home/ small business robots, we have been there before and once the hard problems hit, companies tend to fall. Look at all the ROS-based robot companies even recently like Fetch robotics, or Dyson's robot division, where are they now. I've been watching them fall since the 1980s and while mechanical and computational advances have been made, the real problems remain.

I realise this post has not really added value to the discussion, but I've typed it now :)

Dave

[Alex Sy]

Chris, have you tried out the SteadyWin GIM6010-8?  Does anybody have actual experience with them?

 

I got some and found that they are really only good for quadrupeds or arms, since they are only rated for 5NM of torque at 24V.  They have other larger models that provide more torque at much higher prices and less available.  Another company I have not tried is Robostride but harder to get.

 

The documentation is also incomplete and conflicting, often referencing Odrive, Cybergear and MIT commands and parameters but then not conforming to it.   This is a particular issue with setting it's parameters.   I am trying to find out if all their parameters can be configured purely thru the Canbus (not mix of USB and Canbus) and how to do so.  I prefer to get a known good command protocol.. 

 

The other problem I have is that each time I order some, they do not behave the same way because the firmware has changed and even though I got units with the dual encoder, they require initialization to know their pose, which could hurt somebody.  Even different batches initiallize differently even when given the same commands.  I suspect that the firmware has to be modified or updated before it can be used.

 

Absolute worst case, I may have to create a firmware for it but it is a major digression.

 

We can start another thread if people are interested or have experience on it.

--
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/43C40AF1-7D6E-482A-BAC2-8DC846019CBE%40gmail.com.

[Chris Albertson]

On Jul 10, 2026, at 8:46 PM, 'Alex Sy' via HomeBrew Robotics Club <hbrob...@googlegroups.com> wrote:

Chris, have you tried out the SteadyWin GIM6010-8?  Does anybody have actual experience with them?

No.  I pointed them out because every robot seems to be using motors like them.     It would be easy to buy 12 Cheetah motors and build a Cheetah, and I know what performance I would get.    But what I worked on for a long time was trying to get the same performance at 1/2 or 1/3rd the price.      And yes, I have loads of firsthand experience with the cheaper parts one might use.  Some work, some don’t.

But if someone says “I want to build a humanoid robot,”   while I think I could build a dog-bot with cheaper methods and reduce the cost from $1,200 to about $500, I have no confidence at all that the method could scale up.   The problem is that a humanoid needs an incredible amount of power in a small space.  You only get that with metal planetary reduction gears and a 3-phase BLDC motor with integrated FOC control.       Buy that from SteadWin or Untree or some others.   All my DIY ideas result in a lower energy density suitable for small dog-bot.

If you are at the point in your project where you have simulation data in hand, know the velocities and torques required, then I think the next step is to spend a few hundred bucks on sample motors and beat them up on test stands, measure them, and run them 24x7 for weeks under load.    See if you blow mosfets or bearings or stator coils and how good their customer service is.     Do your own testing BEFORE committing to buying dozens of motors.

The company SteadyWIn does seem to be the largest supplier.   Maybe the only one selling at a personally affordable price.

A ballpark BOM cost for a humanoid is 28 motors and between $150 to $600 each.   Let’s say 8 of them at the high end (knees and hips) and 20 of them at the average $200 price point.   That is on the order of $10,000.    Not bad, but you still need structure of CNC metal, power system, and computers and sensors.   Maybe $20K total.     

With a $20k project, it is reasonable to spend 5% on some sample motors and beat them to death (literally) on test fixtures.    I did that with my cheap parts, and 80% of the stuff broke or failed.  I think this is normal.   If you are into motors like this, the SimpleFOC project’s forums are filled with real experts.

My next step is to get a humanoid into a simulator.   I’m going to use the Untitree R1 as my “version one” robot.   An exact ripped-off copy of the R1 and then over time modify it into something more hobby buildable.    But today, I’m packing for a trip.

[Chris Albertson]

On Jul 10, 2026, at 8:43 PM, Dave Everett <daveev...@gmail.com> wrote:

I have been involved in many group robot projects over the last 30 years. inevitably, I found people wanted to argue over "operating systems" rather than deal with the hard problems. I usually left these projects at that point. The hard problems are where progress still needs to be made and where hobbyists could still make a difference. While it looks like we are on the cusp of true home/ small business robots, we have been there before and once the hard problems hit, companies tend to fall. Look at all the ROS-based robot companies even recently like Fetch robotics, or Dyson's robot division, where are they now. I've been watching them fall since the 1980s and while mechanical and computational advances have been made, the real problems remain.

I realise this post has not really added value to the discussion, but I've typed it now :)

Yes.  You have added value.     A discussion of why projects fail is really needed.       I hate to say it, but the big problem is that many hobbyists lack

 the skill set to attack hard problems.   So they discuss only what they know.   I’m as bad at this as the next person.    

The problem is how to organize a project so as to make use of a very flat skill pyramid.  Organization is usually the killer problem.

But here is what is exciting (to me). Newton saw an apple fall (that really happened) and then thought “why does the Moon not fall?”  My point here is that the question was so simple that anyone could think of it.

What’s frustrating is that I’m sure the next big advance in AI will be triggered by something equally simple that anyone could have thought of, and the answer is hidden in plain sight.  I am sure it is.   I see many clues, if only I could put them together or even read about someone who did.

Newton’s answer, of course, is that the Moon is falling; that is how orbits work.    

[Sergei Grichine]

"... A discussion of why projects fail is really needed..."

Here is some YouTube wisdom from a fighter pilot:

Best Regards,

-- Sergei

--
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/82564A42-0B29-4A97-B287-6532BAECCE64%40gmail.com.

[Chris Albertson]

On Jul 23, 2026, at 2:58 AM, Chris Albertson <alberts...@gmail.com> wrote:

My first attempt at training a very simple biped using RL.

https://youtu.be/UIj_hIuH7Uo


If you reward the robot for forward motion of the torso, RL quickly finds the best quick solution: Fall forward on your face.

If you add in another reward for remaining upright for a longer time, it modifies the fall on your face trick by breaking the fall by placing a foot forward and regaining an upright stance. It ends up doing a hop-skip and jump dance. But this is what we do, kind of. Walking is a continuous falling forward. Gravity pulls us over the leg.

I have a very primitive setup. Running on an older M2-based Mac Mini with a 10-core CPU and using only one CPU core. No GPU. The simulation runs at roughly 30 times faster than real time, and I’m using about 1/2 gigabyte of RAM.

The neural network model is tiny. The input and output layers have one order of about two dozen parameters, and there is one hidden layer with 64 nodes. It is a simple CNN. Basically, the simplest thing that could possibly work.

TheRobot itself is also the simplest possible thing, and all motion is constrained to the (X,Z) plane, so only forward/back and vertical motion is possible.

Using PyTorch and Mujoco.

What you see is the result of only a few minutes of training. Better walking might take many hours.

Plan is to very incrementally improve complexity and realism while learning how to use more than one CPU core and how to use GPUs.

Advice to others: START SIMPLE. This is the simplest thing that could be called “bipedal walking,” and it took me about two hours to get all the software parts installed and a simple Python script to glue the parts together. I know only the very basics; lots of reading still to do. Lots of code to write.

A real robot will be more complex, with 24 joints (motors) requiring 48 numbers for torque and position. Input includes joint position, IMU output, joint forces, foot force sensors, and commanded walking speed. The CNN processes this input vector 100 times per second, requiring three hidden layers and a 20X larger overall CCN, still manageable on a moderate home computer.

Training a robot to RL feels a bit like those old Soviet factory stories. For instance, when the government told a glass factory they’d get a bonus for how much glass they made, they went for super-thin glass, even though nobody wanted it. My robot will try to get the most reward, even if it means acting like a stupid drunk. I can’t imagine what would happen if I rewarded a robot for delivering beer from the fridge. The door would probably come off, the fridge would tip over, and the beer bottle would end up on the kitchen floor. Then, it’d kick the bottle, and it would hit me in the head. You really have to be careful because you get what you ask for. Or rather, you get what you code the reward function for. It’s 3:00am, time to call it a day.

[Chris Albertson]

I am continuing on the humanoid robot project. I will slowly improve my RL training setup. But I find that I need to improve my understanding of exactly how a modern humanoid robot works and how humanoid controllers are architected. A first step is to understand how the motors work at the “kindergarten level”. These motors are far more complex than the gear motors we might put in a wheeled “floor bot.”

One way I can prove to myself I understand is to write papers to explain each concept that are tergeted to a (say) 13-year-old beginner who does not know much about robots. This is harder than writing to a professional audience where you can use technical jargon and fool yourself into thinking you know the subject only because you know the name for the subject.

For example, it is easy to say “Training the network using RL”. But what is a “network” and what are “weights” and how does one actually decide how a network in interally connected and what the weights should be and how in the world does this result in a motor being set to any angle or speed? Explaning is simple terms is harder than explaining using those big words. I learned this some years ago when I had a job teaching science to teenagers. I can say firsthand that my older engineering job was easier.

This first paper is the result of reading Unitree documentation and thinking about “what does this mean from the point of view of a person wanting to build a robot."

My next installment will cover “What the heck does a robot controller actually do?” Then, after that maybe cover how you might build a controller. I write this for myself as I figure it out. But maybe it will be useful to others. Let me know.

Here is paper #1