My Advanced Realistic Humanoid Robots Project

[xrunner]

 

You can't even attribute correctly which person said what in an internet forum and you are going to build a robot?

[artbyrobot]

You can't even attribute correctly which person said what in an internet forum and you are going to build a robot?

Well I clicked the quote button and then going off the text it autopopulated into my response I assumed the topmost line of quote code pertained to the topmost quote and the second one pertained to the secondmost quote which is the most intuitive way of reading this.  It is not using brackets which makes it confusing - look at the code it produced:

quote author=xrunner link=topic=426607.msg5483182#msg5483182 date=1714776514
quote author=Smokey link=topic=426607.msg5483122#msg5483122 date=1714773791
jesus christ... this just raced to the top of the bizarre thread list...
where the hell did all that text come from?  Did an actual person come here and type all that?  LLM?
/quote

I'm trying to be nice (it's pretty hard for me  ), but I'm halfway thinking this is all a joke. Maybe this person really thinks this is the way to build a humanoid-looking robot, but it's ridiculously complicated. For starters, there is no reason - no reason at all - to try to duplicate the bone structure of a biological organism when much more efficient and st


----------------------------------------

so anyways, I did not claim to be infallible which it seems you think I must be in order to build a simple robot like this.  This is easy stuff really.  Wait till people create way more advanced robots with nuclear power, living skin, living blood, etc.  This is all childs play still.

[artbyrobot]

Also, as it pertains to robot maintenance, sure, we want it robust so we don't have to fix or repair daily of course, and some capability to create really robust stuff I imagine comes by experience and I don't have much on that end.  However, my intention is to build more than one humanoid robot and they can maintain eachother fully autonomously as well as maintain themselves without help to a great degree. So these factors will cut down on that concern IMO.

Also, this notion that pulleys would require alot of maintenance which I feel was inferred I don't agree with anyways.  Why should it? It is bearings.  Bearings last for a long time.  The fishing line is very strong stuff overspecced by a healthy margin.  I don't see why that should be a high maintenance item on it.  If you are imagining the rope tangling, don't.  It will not.  It will be held under tension by a spring tensioner system and will not tangle IMO.

[aliarifat794]

Which software is this? The first picture?

Maya

Thank you, I have no experience of using any robot design software. If I want to start, which one do you suggest for a beginner?

[artbyrobot]

Which software is this? The first picture?

Maya

Thank you, I have no experience of using any robot design software. If I want to start, which one do you suggest for a beginner?

I hear good things about Blender plus it's free so maybe that one.  Alot of engineers use fusion 360 or solidworks and seem to love those.  I never tried either and don't feel the need for them for myself.  I do just fine with Maya really.  I guess Blender is just like a free Maya.

[artbyrobot]

I just bought EMEET USB Speakerphone M0 4 AI Mics Speakerphone for Conference Calls 360° Voice Pickup Conference Speakerphone for Computer Plug and Plays Computer Speaker with Microphone for 4 People --- it was around $33 and includes a speaker too.  I'll position it centrally in the skull and it has leds indicating location of main speaker which we can tap into with analog input pins of a microcontroller to know direction of person speaking.  It has very high reviews.  I can remove its built in speaker and move it to near mouth so it outputs its audio output through the mouth as loud as possible and projects the robot's voice as far as possible.  People are really happy with its sound quality and speaker quality.

[artbyrobot]

My concern on implementing "emotions" in my AI is that I don't want to promote the idea that robots can ACTUALLY have emotions because I don't believe that is possible nor ever will be.  They don't have a spirit or soul and never will nor could they.  They are not eternal beings like humans.  They don't have a ghost that leaves their body and can operate after the body dies like humans.  The ghost is what has emotions.  A machine can't.  And yet people already believe even the most primitive AI has emotions and they are delusional on this point.  Or ill informed.  So I am campaigning against that belief that is becoming all too popular.  That said, I think robots are simply more interesting and fun to pretend to have emotions and act accordingly as more accurate simulations or emulations of human life.  This makes them all the more intriguing.  It's like a sociopath who just logically concludes what emotion they aught to be feeling at a given point in time and pretends to feel that emotion to fit in with society even though they feel nothing in that moment.  Now one could argue that allowing your robot to claim to feel anything is lying and therefore immoral.  I think it's not lying as long as the robot openly explains it is only pretending to have emotions as part of its emulating of humans in its behaviors and looks but does not feel anything ever nor can it nor can any robot ever feel a thing EVER.  Then it is admitting the truth of things while still opting to play act to be like a human in this regard.  It would not be a issue at all if everyone was sound minded and informed on this topic.  But the more people I come across that think AI (even pathetic clearly poorly implemented primitive AI) is sentient ALREADY and can feel real emotions and deserves human rights as a living being.... the more I see this delusion spreading, the more I want to just remove all mention of emotion in my robot so as to not spread this harmful deception going around which disgusts me.  However, that would make my robot dull and less relatable and interesting.  So I feel the compromise is for the robot to clearly confess it's just pretending out emotions and explain how that works and it's just a variable it sets based on circumstances that would make a human feel some emotion and it sets its emotion variable to match and acts accordingly altering its behavior some based on this emotion variable and that it feels nothing and this is all just logically set up as a emulator of humans.  As long as it gives that disclaimer early and often with people, then I'm not spreading the lie of robot emotions being real emotions and the robot can campaign actively against that delusion.

[aliarifat794]

Which software is this? The first picture?

Maya

Thank you, I have no experience of using any robot design software. If I want to start, which one do you suggest for a beginner?

Thank you so much. All the best to this robot. Maybe this is the first time I am seeing such a human-like robot's details in a forum.

I hear good things about Blender plus it's free so maybe that one.  Alot of engineers use fusion 360 or solidworks and seem to love those.  I never tried either and don't feel the need for them for myself.  I do just fine with Maya really.  I guess Blender is just like a free Maya.

[artbyrobot]

Here is a updated drawing design for the 64:1 downgearing pulley system for the index finger actuation of the distal 2 joints of the finger. On the bottom right is a zoomed in view on the lower set of pulleys and their routing. The bottom most 3 pulleys in the zoomed in portion I have now built and photos of them are as follows below:

[artbyrobot]

As I'm now 90% through making my first 64:1 downgearing Archimedes pulley system and testing and debugging it, I now have more precise measurements for the Archimedes pulley system's total size. I updated the size of it in my main CAD model for the robot and it was a good 18% increase compared to my initial estimates. I realized I need to figure out how to fit all my pulley systems for the hands properly for every muscle of the hands/wrist in my main CAD model - especially since the pulley systems are taking more space than planned. Turns out, I needed a bit over 40 pulley downgearing systems for the hands and wrists zone and due to their larger size, I could not fit these into the forearms along with the motors I had planned to place in the forearms. So instead of moving the pulley systems into the upper arm or torso, I realized the pulleys would be best placed in line with the motors and what the motors are actuating (the hands/wrist). So it was the motors in the forearms that had to go elsewhere. I placed all of them into the torso, mostly the lats area and some in upper back tenderloin area too. So some finger motors are in upper back and their cable routing has to go through the whole arm, be downgeared in the forearm, then makes its way to the fingers. That's a long trip but unavoidable IMO with my design constraints.

I don't think this long travel distance is a big issue since the pre-downgeared cable running from the motors into the arm is high speed low torque so won't have much friction while making turns in the TPE teflon tubing as it isn't pulling hard yet. So these turns as it travels through the shoulder and elbow tubing won't be too bad friction-wise. There's also some nice upsides to moving the motors from the forearms into the torso. One upside is the wire routing for powering the motors is now a shorter distance from the batteries in the mid section. That cuts down on wire resistance wasted as heat. This wire having high amp flow is ideally kept short as possible due to the resistance of the wire and heat that causes. Another upside is the thrown weight is decreased by a lot when the motors are not in the forearms which enables the hand/lower arm to move more effortlessly and move faster as a result. This also reduces moment of inertia (definition: the moment of inertia is a measure of how resistant an object is to changes in its rotational motion). This means it will be able to change directions faster - this will improve its reflexes for example. Now it is a bit scary for me to be moving more components into the torso taking away room for things I may want to add to the torso in the future, leading us ever closer to the dreaded running out of room for things. However, we still have room for future changes and we solved the need for space for gearing for the hands perfectly. And with the above mentioned upsides, this was a great change.

Here's the updated CAD for the forearms: Note: the teal boxes represent a Archimedes pulley system where 64:1 downgearing is to take place.

[artbyrobot]

Update: in testing, I found the string is wedging between the bearing and the plastic discs sandwiching in the bearing. So I need to now make the bearing have a grooved outer race that will keep the string centered on it and not wanting to drift into the crack on either side of the bearing. To make this groove, I plan to super glue two plastic washers onto the circumference of the bearing and have the string stay within these two plastic washers that form the groove. Commercial pulleys always have this kind of groove and now I've learned the hard way why it is necessary. So I am looking to replace all the pulleys I made so far unfortunately as they are not dependable.

[artbyrobot]

Took a little break on the pulleys work to rig up the cables into the index finger to test the grasping of the index finger. I ended up using 70lb test PE braided fishing line for this and 1mm ID x 2mm OD PTFE teflon tubing as the guide tube. I sewed the fishing line into the index bone fabric around 1/2 cm distally from the ball jointed hinge. In testing, it appears the total draw distance to fully bend the index finger is 0.75". My pulley system is set up to draw 24 inches. 24/32 is .75" so 32:1 downgearing seems fated to us after all (down from our previously intended 64:1 downgearing). Otherwise I would have to greatly overhaul the pulley system design again and I just don't feel like it anymore. So my copium then is 32:1 will make actuation faster. We lose strength but gain speed. 32:1 also saves us making a second plain bearing per downgearing system which cuts down on parts and labor. It also is that much less friction in the pulleys since plain bearings will be more friction than ball bearings.

Note: the friction in the pulleys, although not ideal, do have a hidden upside: once the joint is in position, it can hold that position without as much motor straining since the friction makes the pulley system want to stay in place so the pulley friction can pretty much hold a joint in a given spot without much help from the motor struggling to maintain the joint angle.

Also of note: I found the best way to sew down the teflon guide tubing is to wrap it in fabric tape consisting of compression shirt fabric and 3M 300LSE adhesive transfer tape. This very sticky tape wrapped snugly onto the teflon tubing I can then use as an attachment point for suturing the tubing into the bone fabric tape coating. I got it all very snug this way. The suturing I'm doing with a curved suturing needle and surgical pliers and nylon extra strong upholstery thread.

Also of note: I tied the string for the distal joint and the second to distal joint to one another and will tie the string coming off the pulley downgear system to these. I am actuating both the distal and second to distal joint with a single actuator since these two joints generally move at the same time and about the same amount on a human finger. No need to use one actuator for each joint since they always move in sync.

Note: I was surprised it took 0.75" of draw to fully actuate. I thought 0.375" would be plenty (which is what the 64:1 downgear would give me - 24"/64 = 0.375") but I was wrong. Oops. Another mistake. Proves how testing is so important. But assumptions are necessary stop gaps to move forward and can get you in the ballpark and testing adds the correction to any assumptions that were off. This is all so experimental and full of uncertainties but we press on.

Note: once we fully establish and test a thing and have no uncertainties about it anymore, confidence shoots up even higher and we gain momentum and move into just repeating the processes we established before that led to our successes and it becomes a bit more rote and mindless and relaxing work. But when everything is uncertain and requires such intense thought and concentration, things are very taxing. It is much harder to stay motivated when doing anything requires so much brainpower and planning and care. I very much look forward to dialing in my methods and not having to think so much to make any meaningful progress since I'll just be repeating things for the next joints, doing the same as this one and can shut my brain off while doing so a bit more. The first run through is by far the hardest. Which reminds me of a product I invented and the making of its first prototype took me 20 hours but after making hundreds of this product over the years, now it only takes me 3 hours to make. Things get so much faster once you know what you are doing and have jigs set up and a streamlined process. Everything is excruciatingly slow when you don't have a streamlined process or jigs set up or special custom tools made. So this is the hardest phase right now and I just have to stick it out and then I'll be home free.

[artag]

So this is the hardest phase right now and I just have to stick it out and then I'll be home free.

Well, good on you for trying. I'm sure you'll learn far more doing that than just thinking about it.
However, the skeleton is not the hardest part, I'm afraid. It's not even the actuators. It's the  senses and the actions associated with them, principally balance and the compensation for moving centre of gravity when limbs move. Power is pretty challenging too.

Marc Raibert of Boston Robotics has a good handle  on this. Read his research.

[artbyrobot]

@artag  My instinct is that those purely software challenges are not as "hard" for several reasons.  First of all, consider that in 2009 a Japanese institute of technology - mere students, solved all of those challenges with HRP-4C which would walk and dance and everything and this was just student coders doing this in their spare time while maintaining their entire class load as well.  In my view, the hardest part of the project is maintaining personal belief that I will succeed and not giving up like 99% of others have who set out on this bipedal android dream.  There is a massive up front money and time investment and EVERYONE tells you this cannot be done and you are delusional.  Pushing past the initial design challenges and hardware development to get a functioning prototype is then the hardest part by far.  Once you have a working design that overcomes cooling issues, noise issues (runs silently), space issues (can fit all the crap that has to fit) and all the parts and assembly is of high quality and successful, and you had to learn and half master about a dozen fields to get here mind you, ONLY THEN are we talking about advanced AI implementation to synchronize it all and bring it all to life properly in the ways you mentioned.  Well consider this:  by the time you are in that phase, you already have proven to the world you are not delusional, have a amazing piece of technology - bird in hand, and now have immense confidence and momentum going into the AI phase where balance and walking and whatnot challenges are faced off with.  This is SO MUCH EASIER since excitement and morale are at all time highs, you no longer have overwhelming apathy or nay-saying from all sides on your dream, and you have built a massive fan-base rooting for you.  So even if the complexity or time investment may be higher on the challenges you mentioned, the morale boost and momentum make that phase easier since it is not the implementation challenges that are hardest but the motivation and persistence and perseverance against all odds and emotionally bearing all the nay-saying and hating that is hardest.  Also the fear of the unknown and fear that you will just never make it or will die long before the project could take off fears etc.  Overcoming all of that is the real challenge of something like this.  Maintaining faith in the vision despite most everyone having faith against the vision is not easy and even your own mind whispering doubts at times that you have to shoe away.  You are just mentioning complexity and technical execution which to me is not all that hard.  Also note:  the other major battle in the hardware phase I'm in now is that a great deal of the approaches I'm taking are entirely novel and untested.  Almost everything I'm doing has no guide, no other successes to base off and glean confidence from, and at every turn what I'm doing could fail majorly and have done so.  This means you always wonder will I just hit a dead end and have to start over which has happened to me over and over which is very demoralizing especially when paired with naysayers and haters overwhelmingly apathetic and negging my whole dream.  Its a lethal combo.  Whereas the AI tech you described harmonizing all the sensory input and perfectly bringing the hardware to life in the real world is stuff that has already been achieved and would not be novel and would not be unproven and would have no risk of dead end or wondering if it is even possible since trend setters have already proven this works and there is already a great host of information on all aspects of that and you don't really have to blaze your own trail in those aspects.  There is most likely even documented successful strategies for nearly every single aspect of it - unlike the novel hardware and mechanical engineering phase I'm in.  So that part doesn't take as much blind faith and assumptions but rather is a surefire guaranteed part where failure is not possible given enough time and patience and perseverance which will be easy to muster with the whole world cheering by that point (whole world meaning just whoever stumbles across the project by that point of progression and leaves a positive note etc). 

So to sum, when you have to maintain faith that you will succeed at a dream that most say is impossible, improbable and is surely doomed to fail and they utter this with total confidence in mass numbers with near total unanimous accord, that is hard.  That is the hardest part IMO.  Maintaining faith against such opposition in viewpoint from so many puts one into the realm of delusion in the eyes of most.  How is that not delusional to believe a thing to be true - that you are capable of "the impossible" when most everyone else can plainly tell you are not capable of it and are too blind to see it.  That is the definition of delusional.  It is narcissistic grandiose delusionality disorder and it is also Dunning-Kruger effect in full force.  You have to walk in those titles and persevere as a madman.  But the funny thing is, IF you do push through that half wondering if you are crazy for long enough and you manage to succeed, suddenly, you aren't delusional, did not have Dunning-Kruger effect, and were totally sane the whole time and just everyone else was wrong all along and you were right the whole time.  The entire cards all flip and you are the vindicated one and everybody else has to hang their head down and admit they were wrong and apologize for hating.  It is a remarkable thing how the tables can turn. 

[artbyrobot]

As I edit the above post, I am realizing I missed another MASSIVE hard part of the project I never mentioned.  Perhaps even on the same level of hard of the things I already mentioned.  That is the managerial execution on your life to make such a big and time consuming and money sucking project possible over a long haul.  You have to convince your family to "put up with" the project and compromise with them on also maintaining acceptable progress on other initiatives they value higher than your android project.  You have to manage your finances expertly in order to be financially stable enough to put thousands of dollars into the android project over the years.  You have to manage your time in such a way that you are able to carve out enough time to make meaningful and consistent progress on your android project over the years despite so many other pressing time draws constantly barraging you over the years.  You have to manage your emotional and spiritual condition so that you are able to maintain high morale to even be productive over the bear minimum of just doing your absolute necessities day by day.  You have to manage your energy levels and health so that you have enough pep in your step to be able to not only take care of your family and friends but also your job and household responsibilities and on top of ALL OF THIS manage to STILL have the energy to pour COUNTLESS hours into your android sustainably over the decades.  You also have to maintain your vision and not let scope creep or distractions or self doubt erode at or take away your vision entirely.  So in other words, to sum, one of the hardest parts of such a massive project has NOTHING to do with the project itself AT ALL but has everything to do with managing everything else in life outside of the project with such excellence that you are able to execute the project and carve out the necessary time and resources for the project while also expertly managing your own life in all other areas.  If you don't do this, similar to the idea of technical debt in a project, you end up with life debt on account of your project which forces your project to fail.  So for example, lets say you racked up $20k in credit card debt while neglecting to work or pay your bills and buying parts for your android and working on it exclusively to the detriment of your financial situation and money earning capacity.  Yes, that made you able to make vast and fast progress on your android project, but at what expense?  Financial ruin?  That is not a sustainable approach.  You cannot just ignore these other key aspects of life and go all in tunnel visioned on such a big project.  That might work for short term projects but long term projects you can't just press the pause button on the rest of your life and expect it not to come crashing down eventually as you neglect everything but your android project.  This will come back to bite you.  So you MUST establish yourself with great stability in all areas of life FIRST before you can sustainably perform the android project without it harming other areas of life.  Or consider relationship with family and a significant other.  If you go all in on a massive long term project like the android project, but in the process you neglect family and friends or your significant other, you end up causing them to think you don't care about them and may lose people or ruin these relationships in your pursuit of your long term project goals.  That is not sustainable or responsible and is reckless and selfish to go that route.  Or how about your weight?  Are you going to spend so much time on your long term project and maintaining your income and relationships but throw your health out the window in the process and not make time for the gym or healthy eating?  That is not sustainable either.  So you MUST take time to be a great caretaker of your health.  So then to sum, you must master life in all areas and be stable across the board in order to execute a long term project without neglecting and ruining all manner of things in the peripherals.  So for that reason, I say the success in all these peripherals is one of the hardest parts of such a project and if you can master this, the project is a piece of cake by comparison.

[NightMoth]

That is the managerial execution on your life to make such a big and time consuming and money sucking project possible over a long haul. 

I see that you are very passionate about your project and have been busy with it for a while. Can you share how many hours per week on average and what percentage of the family budget you spend on this project?

[artbyrobot]

Well the average spent is probably $60/mth if you multiply that out by the 9 years I've been doing this.  Not that bad.  I set aside some money toward the robot budget every now and then and purchases sometimes happen in large amounts ($400-700) and usually in smaller orders over time that spreads it out. 

Hours per week on average when active on the project is 7-20 hrs.  Hours per week when on a break from the project is zero.  However whether active or on break I'm still researching and planning - in my youtube I'm subscribed to countless makers and whatnot where I keep learning relevant skills and info.  So even then that's  a form of progress on the educational side.  I also read forums and reddit subs relating to this to keep learning.  That's 8-15 hours a week whether project is on break or not.

One recent example of my ongoing dedication to keep learning is I found the Dallas Personal Robotics Group youtube channel which has 14 years of weekly meetings of their robotics group uploaded where they discuss robotics, show projects, and go into gory details on software and hardware discussion.  I plan to devour all of it.  I also found a podcast called the amp hour podcast and embedded podcast and devoured countless hours of those to learn more about hardware and software.  So all of this is like hours I don't even officially count but they are part of it.

[artbyrobot]

I bought a bunch of punches to make the pulley disc cutting out process way easier than scissors alone. You just place these over the plastic you want to cut and hammer them down with a cutting mat as a backing plate and just one or two hammer taps is all it takes to cut a disc out. Also, now that I plan to make custom plastic washers that I will glue onto the bearings to keep the string centered, these punches will be pretty necessary since that would be much harder to do with scissors than regular discs.




Also, here's an update on the cable routing work I've gotten done for the index finger. So the distal-most joint and 2nd joint in from that are both being actuated by a single motor since they both seem to always move together in unison on a human hand IRL. So I tied off one end of fishing line to one joint and the other end to the next joint forming a loop. Pulling on this loop curls both of these joints into a grasp. I then decided the string that pulls on this loop should itself not have a fixed attachment point but instead a sliding attachment point (I could be wrong on this not sure). So to do this I used the eye of a fishing hook on the loop and tied the next string to that which pulls the loop by way of the fishing hook eye. Next I used a piece of tig welding rod and secured that to the loop tubing and to the tube that pulls on the loop. This gave space for the drawing of the loop to actuate the two joints. Seems to work well so far in manual testing.

Note: take note that the entire section the tig welding rod is attached to is all free floating and has slack so that when the wrist bends back and forth it can adjust freely and not constrict wrist range of motion nor affect finger position when wrist moves.






And here's a range of motion test on the cable grasping mechanism for the index finger. It is a decent range so I consider this design successful as of right now in early testing. A more extreme grasp range would be ideal though IMO but this is as far as it is wanting to go.

[artbyrobot]

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.

[artbyrobot]

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:

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.



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.



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.





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.

[artbyrobot]

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. 

[quince]

https://passarellaclasswebsite.weebly.com/uploads/8/4/3/0/8430716/pygmalion_and_galatea.pdf