My Advanced Realistic Humanoid Robots Project

A colleague of mine asked why I'm using Windows for the robot's brains instead of Linux. Well, in my experience, if you set a program on windows to real-time priority or even above normal priority, it will give most of the processor over to that process and act like a real time operating system. So whatever "bloat" windows may have of background processes is quite cleared up by that. Also, IMO the background processes of windows don't take up that much processor and with multi-core processors and distributed processing any background tasks just won't impact performance much at all IMO. So performance-wise the hit is negligible and unnoticeable IMO. Then comes the upsides (since the downsides were nearly imperceivable). The upsides are I already have many years of experience working with windows API and can reuse the existing code I have developed for AI on Windows. That's a huge advantage so I'm not working from scratch. Also, loads of 3rd party programs and libraries that are well supported run on windows - moreso even than Linux I believe. So I would have easy access to tools. I also own a lot of 3rd party software that is paid software that run on Windows (and may not run on Linux) that the robot can then utilize as tools. Also, troubleshooting operating system problems and knowing common causes is a big deal at times and I have decades of doing so on Windows so that I know it like the back of my hand and can easily fix problems. So that is huge too. So if you are working on a SUPER resource constrained slow single core computer, sure, maybe Linux. But if you have a multi-core higher end gaming pc in the robot's chest, it has WAY more than enough power to run Windows without taking any noticeable hit in performance and one should use windows if they have more experience or exclusive experience with windows rather than attempt to learn a whole new operating system for no good reason IMO.

Oh yeah, one more thing: while testing the AI, I’ll be using it on my personal desktop PC which will act kind of like Siri as I’m training it. My PC is Windows. So if I were to develop the AI for Linux, I’d have to also train it on Linux rather than windows so I couldn’t use it on my personal PC unless I used a virtual machine or something. Basically, I want the AI listening to me and watching me at all times when I’m using the computer and learning about me that way and learning in general that way. It would be getting to know me silently but also possibly speaking to me at times or asking me questions about what I’m doing. I would also want it to be able to interface with any programs I’m using on my personal PC to assist me in whatever ways. So even if it were on a sandbox virtual machine that would then lock it out from helping me on windows doing whatever tasks I’m doing and being interactive with me in that way. That would not be ideal.
 
Your choice of Windows for the robot's brains is pragmatic and well-justified, given your extensive experience and specific project needs. By setting programs to real-time priority, Windows effectively mitigates background process interference, leveraging multi-core processors to maintain high performance. Your years of experience with the Windows API, existing codebase, and familiarity with troubleshooting provide significant advantages, avoiding the need to start from scratch or learn a new OS. Windows' extensive third-party software support, including tools you already own, further facilitates development. Additionally, training the AI on your personal Windows desktop ensures seamless interaction and learning, making Windows the optimal choice for your high-end, multi-core hardware setup.
 
A colleague of mine expressed concerns over how I will deal with the heat generated by the motors and other electronics. He pointed out that all these motors are going to generate heat while running and the silicone skin will prevent that heat from escaping. This was a great observation and one that must necessarily be addressed as it is a make or break problem that the entire success of the project hinges upon. In fact, it is so important that I spent a great deal of time designing and planning multiple redundant cooling systems for the robot to absolutely ENSURE that heat does not end up being my greatest downfall of the whole project which could easily be the case if not handled properly. To start, I have designed artificial lungs that will draw in cool outside air, expel that through tubing to every key area of the body, and vent tubing will take out the hot internal air this fresh intake air displaces so that the entire robot has great air circulation. The lungs are to look a bit like a small accordion or bellows for a fireplace ie they will have two flat hard plates and a soft gasket that joins the two hard plates and one of the plates will move away from the other plate to draw air in and then the two plates will be smashed back together for air expulsion. A single motor can achieve this. Here's a drawing of this:

file.php


This is a rough design of the accordion-like lungs I intend to make for the robot's internal air circulation and evaporative cooling and water cooling systems. This drawing mainly demonstrates the working principle of the way the lungs will open and close as well as valves for opening the inlet and outlet which have to open and close alternately for in-taking fresh air and then pushing that fresh air into the body. I recently realized they can just both be one way valves and don't even need to be motorized that way. The lungs bring the air into the body but never exhale air out of the body they only inhale air into themselves then exhale it into the body and vent exit tubes take care of allowing the hot air that is being displaced by the fresh new outside air to exit the body through the nostrils. The intake is also through the nostrils btw. This way the mouth does not need to open for it to breathe in and out.



file.php


This drawing demonstrates the idea of dividing up the air in the lungs into separate compartments for a more even distribution of the air when it draws it into the rest of the system to ensure the whole system gets the correct amount of air to each location. I am not sure if this is needed though as I think further reaches can just have larger diameter tubing and closer reaches can use smaller diameter tubing so the air will divide up automatically that way. Not sure on this. But I have this concept of division into pockets just in case I find issues with most air going to one area and not enough to another area and I can fall back to this pocket distribution idea in that case to solve it. Its just another tool in the bag so to speak.


file.php


This drawing is for an idea to use a actual freon based air conditioning system just like cars and window units employ but miniaturized in the robot's lungs. I am leaning toward not doing this anymore since it would add unnecessary weight and complication, but I leave it here for reference and it is a optional tool in the bag just in case we wanted to try it in the future or someone else wants to try similar. I think the ice cube based cooling is a superior approach now because ice can be found anywhere you go or a cold drink and this can cool its water cooling system and make a literal freon-based air conditioner in its chest overkill and unneeded.


file.php

file.php


These drawings show a simple early sketch for a ice cooling system for the robot and then a more elaborate sketch for it. I've iterated on these designs several times since these were drawn, but these drawings are simple exploded views of how the working principle can look in general. I have improved on these a lot since then but I think these do a good job of demonstrating the concept. The water cooling system will double as a evaporative air conditioner by sending water trickling down netting in the lungs so that when it breathes the air its breath interweaves with the water droplets causing evaporation which triggers the evaporative cooling effect which in turn cools both the air and the water tremendously. Its the same working principle as air hitting sweat - you instantly feel cold on your skin when a fan hits liquid on your skin. That is the evaporative cooling effect in action. So I intend to use this effect to cool air and water within the lungs. The ice cooling reservoir will be a bag that presses flush with the distilled water cooling reservoir bag. The dirty or soda containing or non-distilled water containing ice water or ice juice (whatever the robot can get its hands on for cooling needs) does not have to be pure because its just anything the robot can find in the moment it needs cooling. Even anything from a vending machine it can drink then. It will be kept in its own separate reservoir so it doesn't gum up the main distilled water cooling system. So the ice water/ice cubes/juice etc reservoir presses against the main distilled water cooling reservoir (containing only distilled water which won't gum up or corrode the main water cooling system). And by having the two bags pressed against eachother, the coldness of the one bag cools the distilled water cooling water bag, pulling heat out of that bag quickly. Once the two bags' temperatures reach equilibrium, the robot can then pee out the ice water cooling reservoir bag contents and go get another drink of ice water or cold whatever drink to rinse and repeat that process as needed. I don't anticipate it needing this extra cooling often, but in hot conditions or rigorous work that is quite physical or sports or dancing it would need this to add extra cooling to its existing cooling approaches. It would then "fuel up" on ice water in advance of rigorous physical activity to prevent overheating during said activity.

Note: I originally planned to put the water cooling and ice cooling reservoirs in the chest of the robot but later realized I could instead put them in the belly of the robot more toward the front of the robot and this way the torso has much more room and these reservoirs won't take up so much room in the chest - which is much needed room. So then, when the robot needs ice cooling, it can drink a large volume of ice and cold water (or juice or w/e drink that's cold) and this will fill its ice reservoir bag which will then cause the belly to protrude like a pot belly. This is how humans work since when we eat a ton our belly sticks out. Same principle. This means we get bonus space available for this purpose outside the normal operating space of the robot's torso due to this natural protrusion factor. This bonus extra room in demand is a nice luxury since it means we don't have to accommodate cold water/ice/juice in the precious coveted space within the torso which gives us more room for other important electronics and stuff to fit in.

Note: the reservoirs of the distilled water for the main water cooling system and the ice water reservoir for the ice cooling system both are best being as big as reasonably possible since the bigger the reservoir the more cooling you get and the longer it takes for those bags to heat up and start causing problems with heat. So then the bigger the reservoir the more sustained cooling we get. After both these reservoir's contents get heated up significantly, they are no longer effective at cooling the system and the robot would have to either sit down and rest and wait till these cool down naturally or would need to pee out the ice cooling reservoir bag warm/hot contents and go drink cold liquid and/or ice to fill the bag back up with something that will quickly cool the whole system down again and it can resume work right away this way with no downtime.
 
A colleague pointed out that the robot probably will need massive batteries. I agree with this in part, but with some caveats. Yes, to support the massive number of motors and the large bursts of energy required when most motors are firing all at once during rigorous athletic type activities, you would need massive batteries to supply all of this energy demand during peak periods. You also want the batteries to have a decent overall runtime duration. I intend for it to use fairly massive batteries for these reasons. However, there is a common misconception that the batteries must be so big that the robot is able to run all day on a single charge and that if it only can run for say an hour, that means it will only be capable of working 1 hour then charging and totally idol and not working for an hour or two and then get back to work again which would cap its productivity massively. People then conclude battery technology today rules out humanoids being particularly useful due to the lack of capacity. This is a completely solved problem and indicates people's lack of thinking this through thoroughly. The solution is simple: I don't have to worry much about large capacity for long duration of runtime since my intention is to have it hot swap battery packs frequently and always have 5-10 battery packs charging so that it always will be able to swap a new pack in that is fully charged. This way it can have 24/7 uptime while not having to carry a very large battery pack to have a long runtime. This is the same approach construction workers use with their cordless tools. They have a ton of packs charging at all times and use batteries till they get low and just swap a new fully charged one in as needed. They don't try to fit a entire days work into one giant battery. They have a ton of small batteries charging at all times instead and just hot swap full ones in for low ones. This should have been obvious to everyone as the perfect solution for humanoid robots too.

Note: in my design, he will have a significant battery pack in the abdomen which never swaps out and tops itself up from the hot swappable battery backpacks as needed. This abdominal battery pack will enable it to swap in new hot swap battery backpacks since you need batteries running it while the hot swappable packs are being swapped. The hot swappable packs will be worn as a backpack just like a school bookbag. When available, the robot will optionally also be able to plug a AC power cord into the wall outlet to charge, although if it has multiple hot swappable batteries already charging by various available wall outlets then this would be redundant. It is a good tool though in general for some situations.

Note: the backpack battery can be taken off and the robot will still have a very limited runtime just based on its abdominal battery pack. It uses this limited time to swap in a new hot swappable battery pack as the primary reason for the abdominal pack, however, another good reason to have a permanent abdominal battery pack is so that it can do demonstrations with no battery backpack on. A use case for this would be: lets say it wants to do a flip or cartwheel and the battery backpack's added weight would be a hindrance for such a maneuver. It could simply take the backpack off, do the flip or cartwheel, then after bowing for applause, it can put the backpack back on.
 
A colleague of mine expressed concerns over how I will deal with the heat generated by the motors and other electronics. He pointed out that all these motors are going to generate heat while running and the silicone skin will prevent that heat from escaping. This was a great observation and one that must necessarily be addressed as it is a make or break problem that the entire success of the project hinges upon. In fact, it is so important that I spent a great deal of time designing and planning multiple redundant cooling systems for the robot to absolutely ENSURE that heat does not end up being my greatest downfall of the whole project which could easily be the case if not handled properly. To start, I have designed artificial lungs that will draw in cool outside air, expel that through tubing to every key area of the body, and vent tubing will take out the hot internal air this fresh intake air displaces so that the entire robot has great air circulation. The lungs are to look a bit like a small accordion or bellows for a fireplace ie they will have two flat hard plates and a soft gasket that joins the two hard plates and one of the plates will move away from the other plate to draw air in and then the two plates will be smashed back together for air expulsion. A single motor can achieve this. Here's a drawing of this:

file.php


This is a rough design of the accordion-like lungs I intend to make for the robot's internal air circulation and evaporative cooling and water cooling systems. This drawing mainly demonstrates the working principle of the way the lungs will open and close as well as valves for opening the inlet and outlet which have to open and close alternately for in-taking fresh air and then pushing that fresh air into the body. I recently realized they can just both be one way valves and don't even need to be motorized that way. The lungs bring the air into the body but never exhale air out of the body they only inhale air into themselves then exhale it into the body and vent exit tubes take care of allowing the hot air that is being displaced by the fresh new outside air to exit the body through the nostrils. The intake is also through the nostrils btw. This way the mouth does not need to open for it to breathe in and out.



file.php


This drawing demonstrates the idea of dividing up the air in the lungs into separate compartments for a more even distribution of the air when it draws it into the rest of the system to ensure the whole system gets the correct amount of air to each location. I am not sure if this is needed though as I think further reaches can just have larger diameter tubing and closer reaches can use smaller diameter tubing so the air will divide up automatically that way. Not sure on this. But I have this concept of division into pockets just in case I find issues with most air going to one area and not enough to another area and I can fall back to this pocket distribution idea in that case to solve it. Its just another tool in the bag so to speak.


file.php


This drawing is for an idea to use a actual freon based air conditioning system just like cars and window units employ but miniaturized in the robot's lungs. I am leaning toward not doing this anymore since it would add unnecessary weight and complication, but I leave it here for reference and it is a optional tool in the bag just in case we wanted to try it in the future or someone else wants to try similar. I think the ice cube based cooling is a superior approach now because ice can be found anywhere you go or a cold drink and this can cool its water cooling system and make a literal freon-based air conditioner in its chest overkill and unneeded.


file.php

file.php


These drawings show a simple early sketch for a ice cooling system for the robot and then a more elaborate sketch for it. I've iterated on these designs several times since these were drawn, but these drawings are simple exploded views of how the working principle can look in general. I have improved on these a lot since then but I think these do a good job of demonstrating the concept. The water cooling system will double as a evaporative air conditioner by sending water trickling down netting in the lungs so that when it breathes the air its breath interweaves with the water droplets causing evaporation which triggers the evaporative cooling effect which in turn cools both the air and the water tremendously. Its the same working principle as air hitting sweat - you instantly feel cold on your skin when a fan hits liquid on your skin. That is the evaporative cooling effect in action. So I intend to use this effect to cool air and water within the lungs. The ice cooling reservoir will be a bag that presses flush with the distilled water cooling reservoir bag. The dirty or soda containing or non-distilled water containing ice water or ice juice (whatever the robot can get its hands on for cooling needs) does not have to be pure because its just anything the robot can find in the moment it needs cooling. Even anything from a vending machine it can drink then. It will be kept in its own separate reservoir so it doesn't gum up the main distilled water cooling system. So the ice water/ice cubes/juice etc reservoir presses against the main distilled water cooling reservoir (containing only distilled water which won't gum up or corrode the main water cooling system). And by having the two bags pressed against eachother, the coldness of the one bag cools the distilled water cooling water bag, pulling heat out of that bag quickly. Once the two bags' temperatures reach equilibrium, the robot can then pee out the ice water cooling reservoir bag contents and go get another drink of ice water or cold whatever drink to rinse and repeat that process as needed. I don't anticipate it needing this extra cooling often, but in hot conditions or rigorous work that is quite physical or sports or dancing it would need this to add extra cooling to its existing cooling approaches. It would then "fuel up" on ice water in advance of rigorous physical activity to prevent overheating during said activity.

Note: I originally planned to put the water cooling and ice cooling reservoirs in the chest of the robot but later realized I could instead put them in the belly of the robot more toward the front of the robot and this way the torso has much more room and these reservoirs won't take up so much room in the chest - which is much needed room. So then, when the robot needs ice cooling, it can drink a large volume of ice and cold water (or juice or w/e drink that's cold) and this will fill its ice reservoir bag which will then cause the belly to protrude like a pot belly. This is how humans work since when we eat a ton our belly sticks out. Same principle. This means we get bonus space available for this purpose outside the normal operating space of the robot's torso due to this natural protrusion factor. This bonus extra room in demand is a nice luxury since it means we don't have to accommodate cold water/ice/juice in the precious coveted space within the torso which gives us more room for other important electronics and stuff to fit in.

Note: the reservoirs of the distilled water for the main water cooling system and the ice water reservoir for the ice cooling system both are best being as big as reasonably possible since the bigger the reservoir the more cooling you get and the longer it takes for those bags to heat up and start causing problems with heat. So then the bigger the reservoir the more sustained cooling we get. After both these reservoir's contents get heated up significantly, they are no longer effective at cooling the system and the robot would have to either sit down and rest and wait till these cool down naturally or would need to pee out the ice cooling reservoir bag warm/hot contents and go drink cold liquid and/or ice to fill the bag back up with something that will quickly cool the whole system down again and it can resume work right away this way with no downtime.
The heat is one issue you might encounter, but a more significant challenge will be managing the sensors. These sensors and the software that controls them represent a substantial hurdle.
 
So the pulleys were working fine except occasionally the thread would wedge between the plastic discs and the bearing causing the system to jam. My solution originally was to cut out finger nail clipping shaped pieces of thin clear plastic to glue onto the inner face of the discs that contain the bearing of the pulley which would act as standoffs preventing the pulley string from sliding between the bearing and the outer discs and jamming. It turned out this was borderline impossible for me as these tiny pieces of plastic were so tiny that even my precision tweezers were barely able to hold them and they would go flying in random directions and get lost - being clear and tiny they were near impossible to find as well. So this led me to taking a step back for a few weeks to work on other unrelated projects and take a break due to this impass/dead end. I came up with some ways to redo the pulleys but hated the idea of scrapping the ones I already made that needed improving. Well I have great news: I did find a way to salvage my existing pulleys that is reasonably doable and not nearly as hard though still tedious as can be. I am using Singer nylon clear monofilament thread and gluing down one end of that to the outer plastic disc of the pulley using superglue applied with the tip of a tiny sewing needle as my applicator and then letting that fully dry (can't use accelerant spray since it has to be very precisely applied and can't get on bearing but is being glued less than a millimeter away from bearing outer race). Then I lay the string along the crack formed between the bearing and the outer plastic disc which fills that crack and I apply glue here and there once every millimeter as I see need for it to secure the string along the entire crack while being careful not to get any on the metal bearing. I use an xacto knife blade to scrape any glue I get on the outer race of the bearing off and any I do get on the bearing I prevent from gluing the clear monofilament thread to the bearing by moving the bearing a couple turns while the glue is drying to keep it from gluing in place. I move the bearing using the tip of the xacto knife blade and I scrape any glue off as I see it on the shiny outer race of the bearing. I use about a 3" long piece of thread each time I do these gap filling passes and then trim off the excess from both sides once done. Attached is a photo with arrows indicating the gap filling clear nylon monofilament thread. I have since tested these pulleys that I fixed and no more jamming is occurring - it worked! Now I want to avoid doing this for every pulley and every crack on every pulley so for now I'm just doing it for known trouble cracks on certain pulleys that prove to jam up the system during testing. Once I can pass all testing without a jam for like 50 back and forth tests in a row, then I'll call this fix done.

file.php



Note: for future pulley making, to avoid this issue entirely, I plan to make the bearings outer race be grooved before I even make the pulley. This way the string passing over the outer race circumference of the pulley will not end up wedging between the outer disc and the pulley in the crack and jamming. The groove on the outer race of the pulley will keep the string passing along its outer race centralized in that grooved channel so it doesn't walk out and get jammed anywhere. To achieve adding a groove to the bearing outer race, I'm planning to lay the bearing flat on a piece of wax paper and then carefully applying epoxy to the crack between the paper and the pulley outer race filling that crack. Picture caulking a bathtub crack between bathtub and wall. Same concept. Then once that is done I flip the pulley and do the same for the other side. You then end up with a v grooved channel in the outer race of the pulley. The rest of the pulley assembly will continue as usual. Attached is a drawing of a pulley on a piece of wax paper with an epoxy bead applied filling the crack and forming one half of the intended v grooved channel on the outer race of the pulley.

file.php



Note: hitting that dead end with trying to fix the jamming issues with the pulleys and frustration with the pulley fix caused me to procrastinate on the robot build and temporarily call off my commitment to work on the robot every day even if just one small accomplishment per day. I still love that commitment and am now getting back to that now that I have come up with my solution and am moving forward again. It really is a great commitment to make sure I keep the project alive and actively in development. It is so easy to just not work on the robot once it is no longer part of my daily routine and the last thing I want is for months or years to slip by without me working on the robot much as has happened to me in the past so many times.
 
file.php


Sorry for the long wait. Got busy with other stuff. Anyways, I completed the full pulley system and just got done testing it. It did not snag once anymore (rope binding between pulley and flanges) because each spot prone to that issue I fixed by putting some clear thin fishing line across that gap and gluing it down on either end. This closed every gap causing issues before and now everything seems to be going smoothly.

I just did a big testing session on the pulley system and it was working perfectly (actuating it by hand for now). However, I got very aggressive and tried to attach a 10 lb dumbbell to one end and test that way. Pretty quickly the bottom-most string of the bottom-most pulley snapped. At first I thought the string itself broke in half but it's 20 lb test so a 10 lb dumbbell statically hanging should have been fine. Turned out it was my knot that came undone! I should have tied it a triple knot at least and put super glue onto it too in order to really secure it. Turns out that particular string attachment point I wanted to upgrade to 70 lb test anyways so it wasn't such a big deal. That will be my next step.

Once I get that re-secured, I want to test it out with the 10 lb dumbbell and use a digital fish hanging scale to test the real world mechanical advantage. My intention is to find out how many pounds of pulling force I'm using to raise the 10lb dumbbell. It should be WAY less than 10lb obviously due to the mechanical advantage from all the pulleys. This will also tell us how much friction there is in the system which I'm sure is significant but I will know by this test EXACTLY how much is involved.

The fact it is all working in general is very promising. The tests went very well just using one hand pulling down as the weight to be lifted and one hand doing the lifting on the other end. The hand I tried to pull down with was EASILY being lifted up. It did like 10-15 trials with no binding, tangles, or issues of any sort. It just WORKED. Too bad I didn't take a short video of the testing before it broke!
 
file.php

file.php

file.php


With my existing snatch block and block and tackle style pulley systems tested and working decently at 16:1 downgearing ratio which feels pretty complex and capped out by space constraints, I am now turning my attention back to some prior concepts for rotating in place pulleys I had planned years back and not revisited till now.

The basic idea is you have a big pulley and a small pulley attached to eachother one on top of the other and so when the big one winds, the small one moves too and going from a small to a big to a small again (just like gears) gives you mechanical advantage. This is like gearless gears in a way works exact same way as gears except can't go continuously in one direction since its limited by amount of windings you can fit on it.

Having a setup like this mounted direct to the motor is a no brainer I think. It will give me a 2:1 or 3:1 downgear straight off the batt and should be fairly easy to make using a 1mm OD x 20mm length stainless steel dowel pin mounted to side of motor sewn into place tightly and then using a little copper tubing for a electrical connector as the rotating sleeve and onto this sleeve gluing down the flanges using the same plastic as what I used for the pulleys (clear sushi and produce containers plastic). That pre-downgearing at the location of the motor will bring our Archimedes pulley system from 16:1 down to 32:1 and possibly 48:1 roughly if we can get between 2:1 and 3:1 downgearing ratio on the motor.

I also am considering just doing ONLY these types of rotating in place pulleys instead of the Archimedes pulleys style of downgearing. It might be more space efficient perhaps. I don't know which will be more robust and which will be a maintenance nightmare. I just dont know which is easiest to work with. Also which is easier to make. I have to make both styles and compare. I think the turn in place style may be more space efficient by a long shot but not 100% sure on this.

When I do the turn in place style mounted flat onto the robot's bones, I plan to use a flat head thumb tack for this as the bone mounted base and then have the rotating pulleys turning in place over this. The flat head thumb tack can be sewn tightly onto the bone sleeve to secure it in place well. I'm not sure how well this approach will scale to higher forces of larger muscles though. Perhaps it will scale fine if I just make the pulleys bigger. So much to experiment with...
 
I finished fixing the fishing line on the bottom-most pulley with 5 knots this time to make sure it doesn't untie. I hung the 10lb dumbbell from the pulley system and to my horror, two fishing line points snapped almost immediately in two new spots. These fishing lines were rated 20lb test and 130lb test. How is a 10lb dumbbell snapping them when hung gently? I don't get this AT ALL. I am wondering if it is a quality control issue with the fishing line or false advertising or just a bad manufacturer or what. Any thoughts? This is VERY frustrating and baffling to me. They did not untie this time they literally snapped in half. This is truly baffling.

Update: some more clues: turns out both snap points were within a millimeter from where the fishing line entered into the bone fabric sleeve where it was stitched over and over to tie it well into the sleeve. Perhaps this area just sort of was weakened by the sleeve and tugging at that spot and abrasion somehow? I am thinking I should tie a small metal ring into the bone fabric sleeve and then tie the fishing line onto that ring with a figure eight knot so that the fishing line doesn't chafe on the nylon fabric as much and has that little separation point tying off on the smooth metal. Hopefully that will solve it.
 
Ok so my solution is to sew a fishing hook's eye into the bone sleeve snugly with upholstery thread as a anchor point. Then I will draw my braided PE fishing line through this eye and back down. Instead of tying it off with a fancy knot which acts as a weak point or concentrated stress point, I will use a fishing crimp sleeve to crimp the rope off on itself. Similar to crimping two pieces of wire to eachother with a electrical crimp tube. Supposedly fishing crimp sleeves are used to avoid knot tying and offer even more integrity than a knot can while maintaining fishing line integrity more than a knot can. No weakness is introduced to the line like knots do. A side benefit is this crimp also protects the line from abrasion and acts as a physical standoff so the line isn't rubbing the bone sleeve as much which can cause micro abrasions and weaken it over time. I bought #2 and #3 fishing crimp sleeves which were around $6/100pcs on amazon.
 
By popular demand, here is some math I did regarding the motor and pulleys for the finger actuation.

64:1 downgear ratio

24 inches total draw onto motor shaft 24 / 64 = 0.37" draw at finger joint

2430 motor 5900kv at 12v RPM = kV * V RPM = 5900 * 12 RPM = 69600
69600 / 60 = 1160 revs/second 1160/2 = 580 revs / half second
580/2 = 290 revs / quarter second

if motor reels around 1cm / rev then in quarter second it reels 290cm...
and 30cm = 1 foot so 290/30 = 9.6ft/quarter second maybe it only reels 3/4 of
that? even so... around 9.5ft/quarter second - and quarter second is the
speed of a human finger moving... we only want to reel 24 inches... and
it is reeling 9.5ft so if it only reeled 24 inches that would be human
speed... so if it only reeled 60cm that would be human speed... but it
reels 290cm... around 4.8x human speed!

now for strength at this 64:1... an online google search said a 2430 motor
can pull 60 g cm... 120 g at 1/2cm 240g at 1/4cm maybe we are around
between 1/4cm and 1/2 cm away from shaft of motor on average... so 190g at
that distance... 190g is 0.42lb... 0.42 lb * 64 = 27lb

so a single finger joint can do 27 lb dumbell curls ALONE - well wait since
it's lifting a lever at the joint, it is much lower than this maybe 1/5
of this so 5.4lb dumbel curl is more realistic...

now this is all for torque at efficient natural movement speed...

what about stall torque - IE how much can it just HOLD in place like rock
climbing dead weight it can't move but can hold steady?

it's stall torque is around 280 g.cm compare that to its normal torque
of 60 g.cm so 4x... so it can HOLD steady around 20lb! that is about what
my finger can hold steady for a single finger tip!
 
I came up with a design for a way to do all my downgearing 64:1 by way of pulleys that is so downscaled that it can fit onto the top of the 2430 motor and achieve the full 64:1 downgearing for BOTH directions of travel.

Here's a photo of the design drawing I made which roughly approximates what this will look like in theory:
file.php



Here's a closeup detail photo of one of the pulley downgearing stations pictured above:
file.php



Here is a photo of a thumb tack and #3 fishing crimp sleeve I bought on Amazon which will act as the basis for the downgearing pulley station:
file.php



Note: what an IMMACULATE FIT this was! I was looking through my junk bags for a sleeve for my thumb tack and nothing was a snug fit but when THIS came in the mail for the unrelated fix I mentioned earlier for the other pulley system, I knew it was perfect for the thumb tack when I saw it! It's the perfect plain bearing!


So the 64:1 downgearing system will start with two fishing lines (0.08mm in diameter 6lb test braided PE fishing line) wrapped onto the output shaft of the BLDC motor in reverse directions - one clockwise and the other counter clockwise. These strings will then travel to each of 6 downgearing stations that will each double the previous torque achieved. So downgearing station 1 will double both of the string's torque and downgearing station #2 will double that bringing the total torque to 4:1 torque. Station 3 - 8:1 torque, station 4 - 16:1 torque, station 5 32:1 torque, station 6 64:1 torque. Each station is made up of a stainless steel thumb tack with a #3 fishing crimp sleeve placed over the tack shaft forming a plain bearing pulley system. Little plastic discs will separate the various sections of this pulley system up. The discs plastic will be strawberry containers clear plastic from the grocery store (same as they use for lots of fruits, cakes, deserts, etc, the clear thin flexible plastic). The 2x torque is achieved by the string wrapping a 2x diameter pulley and a 1x diameter pulley. So every other section of the downgearing station will be 2x in diameter for this to work. Each downgearing station will be clockwise or counter clockwise rotating depending on which string it is downgearing. As the torque increases, the total wraps happening at each station decrease because the string travel is decreasing in distance by 1/2 the previous station's distance of string travel. At each station, as this phenomena occurs, a stronger fishing line can be used that is larger in diameter as needed. So only the first couple stations will use that 6lb fishing line but later stations will swap to stronger stuff since higher torques are getting involved at that point.

The thumb tacks I considered welding together or brazing together. I considered Oxy-Acetylene micro torch welding, large soldering iron brazing, micro tig welding, pulse welding with a jewelry welder, spot welding, etc. But all of these approaches I am not that experienced with. I think I'll try brazing first and if I struggle with that I'll move to fiberglass and superglue where I have the most experience.

My intention is to join each downgearing station thumb tack into its neighbor at the base and get them all to form a flat plane for stability and precise positioning. I intend to prepare the stations all together off the motor. Then when it is one solid structure with all of them glued to their neighbor and all pulley plastic discs added, at that point I can attach the whole assembly onto the 2430 BLDC motor top and suture it into place there. The teflon guidance hose attachment guide structure will also have to be part of this assembly for easy and secure attachment of the teflon hoses at the end.
 
TheRobotStudio on YouTube is doing an open source robot called "Hope-Light" and inviting his viewers to follow along with his progress . I have decided to follow along, although I will be modifying his designs as I go to customize it more to my liking. He expressed he wants this to be a open source community to advance humanoid robotics development in the DIY space and usher in the wider adoption of humanoid robots in more homes across the world. He's excited for what this can mean for global productivity and quality of life improvements it can bring if executed well. I like this vision.

My decision to follow along with his project is to pick up a extra head of steam in my own humanoid robot building projects by utilizing his experience and formal education in robotics engineering as a legit decorated world class humanoid roboticist. A world leader in the field. By following his open source project loosely, I can get a breath of fresh air by skipping past the bang my head against the wall dead-ends and regular difficult hurdles and just get results. Sort of like fast food drive thru. It will be a relief for me. And confidence booster. To see something really happen at a faster pace for a change.

Now none of this is to say I'm abandoning my existing projects. They will all go on as planned without interruption. This will be a parallel journey I will share. I will certainly learn a ton and can apply what I learn to my other projects.

I will have this Hope - Light robot adaptation be named Dinah. I'll use Eve's base mesh for the external appearance. The two females can look similar in build but have different faces.

This robot will use to some extent TheRobotStudio's design philosophy and approach for the Hope-Light project. This means it WILL use metal geared brushed DC servos and it WILL use non-human-like bone structure, but I will still give it human-like realistic silicone skin and it will use the exterior exoskeleton shell of the Eve robot I 3d modeled already. One downside to this Hope-Light parallel implementation is that because it uses metal gearing it will be loud in its operation. So it will never be able to pass for human in public. That's okay though. My other designs are reaching for that aim and my other designs are still the intention for Adam, Eve, and Abel. So that vision remains alive. And will continue. But this noisy robot will still be a great learning experience and capable of doing useful work including helping me build my other robots, chores, manufacturing products, cooking, etc. It will probably do most of the things the Adam, Eve, and Abel robot can do but not be as strong, fast, and articulated. So it will probably not play sports well or do rock climbing or various other serious physical strenuous types of work. But the long list of things it should be able to do is still enough for it to be awesome.

A great thing is that it won't be so experimental and outside the box like my previous solo approaches. This one will be designed to a small degree by a real professional so it will happen way faster and more surely than mine. Although I am finding I am changing his design so much it's not really his design at all anymore but my own. However, I still plan to retain a significant number of strategic decisions, placements, and organization following his lead. My other designs are more of a pipe dream shooting for the moon. Going more similar to this open source one designed by a real pro is more of a "sure thing". Not that I don't believe I can achieve my more ambitious designs, but just that they are admittedly a taller order and more crossing fingers about them is all. I really think building a top tier legit walking and talking full humanoid is going to legitimize my journey more in my own eyes and give me a better resume to bring MORE hope toward my own robot builds. Just seems like doing this is a no brainer.

Here's a early design progress image from TheRobotStudio who is currently designing Hope-Lite in Solidworks.
file.php


You'll note he fused the distal knuckle of 4 fingers so they are permanently partly bent. This was a decision to cut down on complexity but in my preference, I'd rather have that functionality. You'll also note that it cannot pronate or supinate the wrist. That takes away a TON of functionality which is not my preference. So my robot will add this function back. That said, as I was studying how to add pronation and supination without a ulna and radius bone, I stumbled across the simple and effective design of posable love dolls' skeletons. I realized they have pronation and supination in their stock skeletons, so I decided I will use that kind of skeleton for this project. They are simple, very strong, welded steel construction with heavy duty hinge systems. To be posable, the hinges are quite stiff, so I will need to loosen all hinges to reduce friction. They are a hollow lightweight tubing style. Actually not that heavy.
 
So today I went ahead and extracted this metal skeleton from a male love doll I had bought some months back to use as a base form from which to sculpt the appearance of another robot. Just to clarify upfront, this was never purchased for any sexual purposes—strictly for its materials. I bought it mainly wanting the already decent human appearance it offers in the TPE body and face that can act as a starting point for sculpting a robot. This is better than having to begin sculpting from scratch in clay and making a mold or w/e. Just a shortcut for me. I bought a decent used male love doll for a few hundred dollars which was a bargain to say the least. The shipping alone had to be close to $200+ so it was priced WAY below the cost of the raw materials if I were to try to buy 50lb of TPE rubber. I intended to melt down the massive amount of TPE rubber once done using it to assist in the sculpt of another robot and use that melted down rubber to create the skin for a robot. So those ideas were I had planned for this doll. However, now that I have decided to use the skeleton for a robot build - now I'm REALLY maximizing that little investment! So after 4-5 hours of carefully removing the skin from the frame, I have it all off. I made a few tears here and there in the doll from rough handling during the skinning process and the lack of experience at this, but it went well overall. It was a very physically demanding job to separate the skin from the frame since you had to pry at it, cut it, and peel it and the whole time it fights you wanting to snap back to its original shape. I am quite sore but glad I got it done in a single day.

Here's a photo of the skeleton I just extracted and will be modding and using for Dinah:
file.php


Now, having gotten the skeleton out and analyzed it carefully, I noticed it does not have the ability to shrug, so I'll have to add a hinge on both sides to enable that movement. Also, its bar where the tibia and fibia would be is not proportional in length to the bar that acts as the femur. I can see that they made the doll taller by just adding length to the tibia/fibia bar rather than proportionally adding height throughout the robot. So its proportions are off due to their laziness or oversight. In any case, I have to modify ALL the proportions some I think to match the proportions of my Eve base mesh sculpt. The neck is also quite hard to bend so I might have to add a couple hinges to it. All the nuts for every hinge on it are welded into place to prevent them backing out so I will have to grind off all these welds so I can loosen the nuts to disable posing and instead have all joints freely moving to reduce friction. I will have to add proper fingers and a palm. I will 3d print these bones for the fingers.



TheRobotStudio is using Feetech SC0009 servos for the fingers. I'm planning to substitute in three N20 66rpm motors in place of each Feettech SC0009 servo. By combining three of these N20 motors, I am able to surpass the total torque of the SC0009 servo but after factoring in the size of our respective output winches, mine will be about 13% slower than his. This is fine by me because his robot hand designs are always extremely fast in finger speed and I can get by 13% slower than this. The purpose of swapping in N20 66rpm motors for the Feetech SC0009 motors is to cut costs and I just have a ton of them already and have been itching to use them. The Feetech SC0009 servo is around $11 and my N20 66rpm motors are only around $0.80 so 3 of them is $2.40. So that's $8.60 saved ever time I do this part alternative strategy. Well the savings is a bit less since I then have to supply my own motor controller H-bridge chip and potentiometer to read joint angle. So maybe only $8 saved. However, from what I gather, the Feetech SC0009 requires a serial adapter board to run it and doesn't use PWM but uses serial. I do NOT like this AT ALL in terms of my preferences and the adapter boards were $13 each and only serve 4 servos. That will add up quickly. So I'm actually saving that cost too. I prefer my microcontrollers to pwm directly to the h-bridge with no middle man software whatsoever to maximize my control.

TheRobotStudio is using 3 different sizes of Feetech servos in his approach. You can see the wrist servo is much bigger in his CAD model. I am operating under the assumption I can cram TONS of these little N20 66rpm motors and use more than one of them per joint. So I can use as many as I need to get to the torque I require. I will use L298N motor driver h-bridge chips with these N20 66rpm motors to drive them. This chip can safely power 2 N20 motors per channel and has two channels. It's VERY cheap maybe like $0.15 per chip I think - don't remember. I'll use Arduino mega to send out the pwm. I'll use 10k ohm 3 pin wheeled potentiometers to read the joint angles and these will be coupled to the joints by fishing line which will translate the joint angles over to the potentiometers whose values will be read in by the Arduino Megas. So a lot of my own designs for control and sensory input I'm sticking with for this project but using various elements of Hope-Light for a hybrid approach and swapping in different actuators whenever I feel inclined.
 
Last edited:
I just came up with a cool alternative way to downgear a 2430 BLDC motor that might work.

Here's a illustration of the cheap downgearing idea:
file.php


So basically, I figured what if I could remove the N20 motor from its gearbox/"gear set" by cutting it free or w/e. But I keep its center axle in place cutting away only everything else. You'd then presumably have a metal shaft as a entrance to the gearbox and a metal shaft exiting the top of the gearbox. I then turn that metal input shaft and output shaft into pulleys. I feed my 2430 motor output shaft pulley/winch into the input shaft of each of 4 N20 motor gearboxes, evenly distributing the load. Each gearbox downgears my 2430 motor 150:1. Each gearbox chatgpt said could handle about 5-6lb load but this can't be sudden or fast direction change this is really pushing it. But it seems 4 gearboxes should handle most of what we'd want from a 2430 motor. And the fact we can fit them all within the height of the motor output shaft default length and within the width of the 2430 motor diameter for the most part seems it would be a pretty significant downgearing for very low space taken as the cost. You could even locate a few more gearboxes off the motor anywhere and have those fed further distributing to them the load if only 4 gearboxes was not enough to handle expected forces. The cool thing is supposing we did this, it would cost us four N20 motors which is $0.80x4 = $3.20. That is VERY cheap for a gearbox as I read that a planetary gearbox for it would be like $25-30! And the planetary gearbox would take up WAY WAY WAY WAY more space which is highly coveted in our application - space we can't afford to spare. And the great thing is these little gearboxes you can fit ANYWHERE into a nook or cranny since they are so tiny... and you can use as many as you want to get up to the total forces you need them to handle as a collective. Seems like this could be a cool technique. I want to give it a go. Any thoughts?

Note: this would be something I'd try on the Dinah robot where I'm using metal gears despite the noise these create since its a lower budget simpler robot I'm doing just to get something done faster for a change. My Adam, Eve, and Abel robots will be going pulleys to downgear to make them very quiet in operation as has been the plan forever.
 

Which type of robots will have the most significant impact on daily life by 2030?

  • Humanoid Robots

  • Industrial Robots

  • Mobile Robots

  • Medical Robots

  • Agricultural Robots

  • Telepresence Robots

  • Swarm Robots

  • Exoskeletons


Results are only viewable after voting.
Back
Top